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@xxxxxxxx> SUSE Labs, CR
