On Wed, Jan 17, 2024 at 07:56:01AM +1100, Dave Chinner wrote: > > The wiping of secrets is completely orthogonal to the freezing of > the device and filesystem - the freeze does not need to occur to > allow the encryption keys and decrypted data to be purged. They > should not be conflated; purging needs to be a completely separate > operation that can be run regardless of device/fs freeze status. > > FWIW, focussing on purging the page cache omits the fact that > having access to the directory structure is a problem - one can > still retrieve other user information that is stored in metadata > (e.g. xattrs) that isn't part of the page cache. Even the directory > structure that is cached in dentries could reveal secrets someone > wants to keep hidden (e.g code names for operations/products). Yeah, I think we need to really revisit the implicit requirements which were made upfront about wanting to protect against the page cache being exposed. What is the threat model that you are trying to protect against? If the attacker has access to the memory of the suspended processor, then number of things you need to protect against becomes *vast*. For one thing, if you're going to blow away the LUKS encryption on suspend, then during the resume process, *before* you allow general user processes to start running again (when they might try to read from the file system whose encryption key is no longer available, and thus will be treated to EIO errors), you're going to have to request that user to provide the encryption key, either directly or indirectly. And if the attacker has access to the suspended memory, is it read-only access, or can the attacker modify the memory image to include a trojan that records the encryption once it is demanded of the user, and then mails it off to Moscow or Beijing or Fort Meade? To address the whole set of problems, it might be that the answer might lie in something like confidential compute, where the all of the memory encrypted. Now you don't need to worry about wiping the page cache, since it's all encrypted. Of course, you still need to solve the problem of how to restablish the confidential compute keys after it has been wiped as part of the suspend, but you needed to solve that with the LUKS key anyway. This also addresses Dave's concern of it might not being practical to drop all of the caches if their are millions of cached inodes and cached pages that all need to be dropped at suspend time. Anoter potential approach is a bit more targetted, which is to mark certain files as containing keying information, so the system can focus on making sure those pages are wiped at suspend time. It still has issues, such as how the desire to wipe them from the memory at suspend time interacts with mlock(), which is often done by programs to prevent them from getting written to swap. And of course, we still need to worry about what to do if the file is pinned because it's being accessed by RDMA or by sendfile(2) --- but perhaps a keyfile has no business of being accessed via RDMA or blasted out (unencrypted!) at high speed to a network connection via sendfile(2) --- and so perhaps those sorts of things should be disallowed if the file is marked as "this file contains secret keys --- treat it specially". - Ted
