On Tue, 2024-01-16 at 11:50 +0100, Christian Brauner wrote: > So when we say luksSuspend we really mean block layer initiated > freeze. The overall goal or expectation of userspace is that after a > luksSuspend call all sensitive material has been evicted from > relevant caches to harden against various attacks. And luksSuspend > does wipe the encryption key and suspend the block device. However, > the encryption key can still be available clear-text in the page > cache. To illustrate this problem more simply: > > truncate -s 500M /tmp/img > echo password | cryptsetup luksFormat /tmp/img --force-password > echo password | cryptsetup open /tmp/img test > mkfs.xfs /dev/mapper/test > mount /dev/mapper/test /mnt > echo "secrets" > /mnt/data > cryptsetup luksSuspend test > cat /mnt/data Not really anything to do with the drop caches problem, but luks can use the kernel keyring API for this. That should ensure the key itself can be shredded on suspend without replication anywhere in memory. Of course the real problem is likely that the key has or is derived from a password and that password is in the user space gnome-keyring, which will be much harder to purge ... although if the keyring were using secret memory it would be way easier ... So perhaps before we start bending the kernel out of shape in the name of security, we should also ensure that the various user space components are secured first. The most important thing to get right first is key management (lose the key and someone who can steal the encrypted data can access it). Then you can worry about data leaks due to the cache, which are somewhat harder to exploit easily (to exploit this you have to get into the cache in the first place, which is harder). > This will still happily print the contents of /mnt/data even though > the block device and the owning filesystem are frozen because the > data is still in the page cache. > > To my knowledge, the only current way to get the contents of > /mnt/data or the encryption key out of the page cache is via > /proc/sys/vm/drop_caches which is a big hammer. To be honest, why is this too big a hammer? Secret data could be sprayed all over the cache, so killing all of it (assuming we can as Jan points out) would be a security benefit. I'm sure people would be willing to pay the additional start up time of an entirely empty cache on resume in exchange for the nicely evaluateable security guarantee it gives. In other words, dropping caches by device is harder to analyse from security terms (because now you have to figure out where secret data is and which caches you need to drop) and it's not clear it really has much advantage in terms of faster resume for the complexity it would introduce. James
