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:

quoted

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 [off-list ref]
SUSE Labs, CR