Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs

[Jan Kara <jack@suse.cz>]

On Mon 29-01-24 19:13:17, Adrian Vovk wrote:
> Hello! I'm the "GNOME people" who Christian is referring to

Got back to thinking about this after a while...

> On 1/17/24 09:52, Matthew Wilcox wrote:
> > I feel like we're in an XY trap [1].  What Christian actually wants is
> > to not be able to access the contents of a file while the device it's
> > on is suspended, and we've gone from there to "must drop the page cache".
> 
> What we really want is for the plaintext contents of the files to be gone
> from memory while the dm-crypt device backing them is suspended.
> 
> Ultimately my goal is to limit the chance that an attacker with access to a
> user's suspended laptop will be able to access the user's encrypted data. I
> need to achieve this without forcing the user to completely log out/power
> off/etc their system; it must be invisible to the user. The key word here is
> limit; if we can remove _most_ files from memory _most_ of the time Ithink
> luksSuspend would be a lot more useful against cold boot than it is today.

Well, but if your attack vector are cold-boot attacks, then how does
freeing pages from the page cache help you? I mean sure the page allocator
will start tracking those pages with potentially sensitive content as free
but unless you also zero all of them, this doesn't help anything against
cold-boot attacks? The sensitive memory content is still there...

So you would also have to enable something like zero-on-page-free and
generally the cost of this is going to be pretty big?

> I understand that perfectly wiping all the files out of memory without
> completely unmounting the filesystem isn't feasible, and that's probably OK
> for our use-case. As long as most files can be removed from memory most of
> the time, anyway...

OK, understood. I guess in that case something like BLKFLSBUF ioctl on
steroids (to also evict filesystem caches, not only the block device) could
be useful for you.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR