I don't see any other way? When you sleep (suspend to RAM), everything is stored in RAM and is encrypted but the master key is present in kernel memory (if I recall correctly).
However, if you hibernate (suspend to disk) the entire contents of RAM (including the master key) is written/encrypted to disk and the RAM is cleared.
When you wake the machine up you have to re-enter the passphrase to decrypt the master key to re-load disk contents back to memory.
> Except that, for more than two years, the encryption key remained resident in memory across suspend, leaving it there for the taking by anyone who seized the still-powered laptop.
I don't get it. Obviously, the laptop is locked when it resumes, how is that key "for the taking by anyone"? I'm not saying it is impossible to read out RAM from a locked laptop, but surely not by "anyone".
While it is certainly an interesting bug, I kinda feel that the title is click bait? Because this `cryptsetup luksSuspend` from what I understood is not really officially supported but an extension done in Debian, so if anything this regression only affected Debian? I am not sure if you can blame the kernel for something that is not supported or even widely tested.
I still find this impressive, and it is nice that we now have a test (NixOSTests BTW are awesome, I agree with OP) to avoid this regression from coming back. But from the title it seems to be a widespread issue, not something that affects only one Distro.
I've used this feature on arch its available on bog standard luks but as far as I know it's not used by default when you suspend.
You are thinking of the machinery to actually actuate suspend to ram after a luks suspend in a way that is actually useful which was first a Debian targeted thing then arch and used by default by neither.
I'm confused why you're saying this is a Debian-specific thing -- luksSuspend is upstream and was added back in 2009[1] in release v1.1.0[2]. I've used it (though somewhat sparingly) on Arch and openSUSE in the past and it definitely exists on non-Debian distributions. Maybe you're thinking of the automatic integration with system suspend? If so, that's kind of besides the point -- luksSuspend documents itself as clearing the keys from system memory, which stopped happening in Linux 6.9 due to the referenced refactor patch.
Though it should be noted that it seems that this is actually a bug in cryptsetup in that it was depending on very specific lifetime behaviour of kernel keyring keys, when it arguably should've been more explicitly cleared by userspace[3].
On my laptop with Fedora I just configured Linux to hibernate to disk after 15 minutes of suspend. Powering memory off ensures that bugs like this Debian-specific would not matter.
Plus what Debian extension to Linux tooling does although nice in theory, but in practice if one really worries about cold-boot attacks, then all keys and important documents has to be wiped out from memory, not only LUKS keys.
So hibernating is really the only proper way to protect against cold boot.
on the subject of encryption keys and memory there is something you can do:
- if your CPU supports it, enable memory encryption.
- if your TPM module supports this look for MemoryOverwriteRequestControl & MemoryOverwriteRequestControlLock (/sys/firmware/efi/efivars/) and toggle them. make sure that your computer always reboots and never powers off. memory will always be wiped on boot.
I am far from a security expert, but from the number of "we missed a single line C check across files during refactoring" critical security bugs discovered on a regular basis these days, the whole premise of a "giant secure open source C codebase" seems questionable. It is not specific to C of course, but invariants are arguably even harder to enforce and track consistently (esp under changes to code) in C. Unsure if FP with invariants encoded in types is a practically feasible scalable solution either. Model checking? [LLM] fuzzing? Fewer primitives with clear boundaries? Is that how seLinux was "checked"?
The only reason that I do the disk encryption is so that I don't have to worry about people going through my laptop to steal tax documents and/or credit card stuff when I sell the laptop. I of course also wipe the laptop too, but I figure that if the data is encrypted at the drive level then there's very little risk of anyone being able to use some kind of forensics tool and recover data.
It's because of vulnerabilities like this that I enable Intel's "total memory encryption" feature. No plaintext leaves the CPU package. DIMM swap attacks become useless. Moreover, it's basically free: the cryptography happens directly in the memory controller, in hardware, inline with the bus transactions the CPU is doing anyway.
Did the Feds desperately need a way of getting the key? is this a bugdoor? Has the commits been traced?
Recently I’ve been seeing this pattern a lot and I’m starting to be a little bit suspicious. Maybe it’s because people are more sensible to this and post more on it?
To me the bigger problem is that the linux kernel does not seem to have
a thorough test suite. Such things should be easily testable and
verifiable. Apparently since 2024 nobody had that; humans are only so
good for some tasks. Automatism should be done programmatically by
machines serving humans.
Edit: Wait, so this was a debian patch? Now, this does not nullify my prior statements, but they should have said so clearly that debian screwed up here rather than the linux kernel devs.
No, it is indeed a kernel bug in the code path responsible for luksOpen.
Debian (and the distributions which ported cryptsetup-suspend) relied on cryptsetup luksSuspend doing its thing correctly, and cryptsetup luksSuspend relied on cryptsetup luksOpen doing its thing correctly, and cryptsetup luksOpen relied on the thread keyring being purged from memory on process exit, which is promised in the tread-keyring(7) manpage.
Imagine how this HN thread would have looked like if this vulnerability existed in a proprietary OS.
The top-level comment would surely have been about how Applosoft doesn't care about software quality any more and "that's what you get if you allow vibe-coded slop into your OS". The one below it would have been a crazy (everywhere else, not crazy for HN) conspiracy theory about the surveillance industrial complex and the NSA.
28 comments
[ 2.9 ms ] story [ 55.0 ms ] threadHowever, if you hibernate (suspend to disk) the entire contents of RAM (including the master key) is written/encrypted to disk and the RAM is cleared.
When you wake the machine up you have to re-enter the passphrase to decrypt the master key to re-load disk contents back to memory.
I don't get it. Obviously, the laptop is locked when it resumes, how is that key "for the taking by anyone"? I'm not saying it is impossible to read out RAM from a locked laptop, but surely not by "anyone".
I still find this impressive, and it is nice that we now have a test (NixOSTests BTW are awesome, I agree with OP) to avoid this regression from coming back. But from the title it seems to be a widespread issue, not something that affects only one Distro.
You are thinking of the machinery to actually actuate suspend to ram after a luks suspend in a way that is actually useful which was first a Debian targeted thing then arch and used by default by neither.
Though it should be noted that it seems that this is actually a bug in cryptsetup in that it was depending on very specific lifetime behaviour of kernel keyring keys, when it arguably should've been more explicitly cleared by userspace[3].
[1]: https://gitlab.com/cryptsetup/cryptsetup/-/commit/3cea5dcc7b... [2]: https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/v1... [3]: https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/93...
Plus what Debian extension to Linux tooling does although nice in theory, but in practice if one really worries about cold-boot attacks, then all keys and important documents has to be wiped out from memory, not only LUKS keys.
So hibernating is really the only proper way to protect against cold boot.
- if your CPU supports it, enable memory encryption.
- if your TPM module supports this look for MemoryOverwriteRequestControl & MemoryOverwriteRequestControlLock (/sys/firmware/efi/efivars/) and toggle them. make sure that your computer always reboots and never powers off. memory will always be wiped on boot.
The only reason that I do the disk encryption is so that I don't have to worry about people going through my laptop to steal tax documents and/or credit card stuff when I sell the laptop. I of course also wipe the laptop too, but I figure that if the data is encrypted at the drive level then there's very little risk of anyone being able to use some kind of forensics tool and recover data.
(No, no, I take this stuff seriously too, but it had to be said)
Edit: Wait, so this was a debian patch? Now, this does not nullify my prior statements, but they should have said so clearly that debian screwed up here rather than the linux kernel devs.
Debian (and the distributions which ported cryptsetup-suspend) relied on cryptsetup luksSuspend doing its thing correctly, and cryptsetup luksSuspend relied on cryptsetup luksOpen doing its thing correctly, and cryptsetup luksOpen relied on the thread keyring being purged from memory on process exit, which is promised in the tread-keyring(7) manpage.
The top-level comment would surely have been about how Applosoft doesn't care about software quality any more and "that's what you get if you allow vibe-coded slop into your OS". The one below it would have been a crazy (everywhere else, not crazy for HN) conspiracy theory about the surveillance industrial complex and the NSA.