On Tue, 2024-01-16 at 15:40 +0000, Matthew Wilcox wrote: > On Tue, Jan 16, 2024 at 10:25:20AM -0500, James Bottomley wrote: > > 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 ... > > I think you've misunderstood the problem. Let's try it again. > > add-password-to-kernel-keyring > create-encrypted-volume-using-password > write-detailed-confession-to-encrypted-volume > suspend-volume > delete-password-from-kernel-keyring > cat-volume reveals the detailed confession > > ie the page cache contains the decrypted data, even though what's on > disc is encrypted. Nothing to do with key management. No I didn't; you cut the bit where I referred to that in the second half of my email you don't quote. But my point is that caching key material is by far the biggest security problem because if that happens and it can be recovered, every secret on the disk is toast. Caching clear pages from the disk is a problem, but it's way less severe than caching key material, so making sure the former is solved should be priority number one (because in security you start with the biggest exposure first). I then went on to say that for the second problem, I think making drop all caches actually do that has the best security properties rather than segmented cache dropping. James
