On 2/15/24 08:57, Jan Kara wrote:
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?
Yes you are right. Just marking pages as free isn't enough.
I'm sure it's reasonable enough to zero out the pages that are getting
free'd at our request. But the difficulty here is to try and clear pages
that were freed previously for other reasons, unless we're zeroing out
all pages on free. So I suppose that leaves me with a couple questions:
- As far as I know, the kernel only naturally frees pages from the page
cache when they're about to be given to some program for imminent use.
But then in the case the page isn't only free'd, but also zero'd out
before it's handed over to the program (because giving a program access
to a page filled with potentially sensitive data is a bad idea!). Is
this correct?
- Are there other situations (aside from drop_caches) where the kernel
frees pages from the page cache? Especially without having to zero them
anyway? In other words, what situations would turning on some
zero-pages-on-free setting actually hurt performance?
- Does dismounting a filesystem completely zero out the removed fs's
pages from the page cache?
- I remember hearing somewhere of some Linux support for zeroing out all
pages in memory if they're free'd from the page cache. However, I spent
a while trying to find this (how to turn it on, benchmarks) and I
couldn't find it. Do you know if such a thing exists, and if so how to
turn it on? I'm curious of the actual performance impact of it.
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
Best,
Adrian
