Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

Join the discussion

• Hacker News
• Why is something this important not tested with every build?
  by snmx999
• 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.

  by miki123211
• https://xkcd.com/538/

  (No, no, I take this stuff seriously too, but it had to be said)

  by boutell
• But if you do this, don't you have to enter two passwords each time you wake? One for LUKS, one for the system login?
  by chazeon
• Well yes and I don't see how this can be avoided.
  by polotics
• The other big problem is that all your processes continue running, but your disk is unmounted. I can't imagine how you'd avoid everything crashing horribly.

  I mean, I can imagine an implementation where the system pauses all processes related to the user session _except_ the screenlocker, and have a custom screen-locker which can supply the credentials to luks…

  But that the screen locker is a desktop application, so the compositor itself needs to stay alive too, but then compositor might try to talk to other applications, and those are frozen. So wouldn't it consider them crashed and disconnect them? Now your compositor needs to understand that the system is in a "disk unmounted and processes frozen" state too.

  Not even sure how you'd deal with logs from its stdout, since the file descriptor to the log files is invalidated too.

  If anyone is actually using such a setup, I have so many questions. I know that theoretically all this is feasible, but all the existing components don't seem to be ready for just unmounting the encrypted disk at runtime like that.

  by WhyNotHugo
• LUKS still keeps unencrypted header on the harddrive; real men use plain dm-crypt instead! Plausible deniability compatible.
  by storus
• Ah yes, it is very plausible you just keep a partition of hundreds of gb of perfectly random data for no reason at all.
  by bawolff
• 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.

  by teravor
• Proper capitalization makes English easier to read.
  by bluebarbet
• https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-...
  by someothherguyy
• > 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".

  by deng
• you dump the physical memory, then decrypt the disk offline
  by saidnooneever
• Anyone with physical access. I think it is understandable from the phrase.

  There is a common misconception about how lock-screens in general work - they usually just prevents using the current hardware and software as it is to access the current OS. But the disk encryption is the main thing that prevents modification and other kind of access to actual data. And if the disk encryption key is lying in the memory, then effectively, the disk encryption is bypassed if someone can access the machine physically and assuming that there are no sufficient tampering protections in place for that machine.

  by nicce
• There are attacks that allow dumping RAM if the device is powered on though and you have physical access. Depending on config it may be very easy (just plug in a dumper over Thunderbolt on USB C and do direct memory access) or hard (freeze and swap physical RAM to an unlocked machine).. but the idea was defense-in-depth here; a well configured device should both be hard to dump RAM on and it should not give encryption keys if an attacker succeeds.
  by jakewins
• 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.
  by quotemstr
• I don't see how that solves this problem. there is a string in memory that gets saved on suspend. that string when read by the CPU has the same properties it had before. if the CPU is using rot-13, the string is still rot-13 and the attacker doesn't need to spend the compute needed to crack rot-13, the CPU will simply do that as normal.
  by fsckboy
• 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.

  by shevy-java
• 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.

  by IngoBlechschmid
• 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.

  by fpoling
• Hmm, where does it get a key to decrypt memory on resume?

  AFAIK it's practical only if you make use of TPM. And if you do, you're basically at mercy of TPM.

  by killerstorm
• > So hibernating is really the only proper way to protect against cold boot.

  I agree; or resurrecting FridgeLock: https://www.sec.in.tum.de/i20/publications/fridgelock-preven...

  by IngoBlechschmid
• 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?
  by moktonar
• it is a regression. the user space application also would silently fail, it is a chain of oversights. also having the encryption keys in memory does not mean you can extract them, it is more of unnecessarily letting it there indefinitely, not having it where it shouldn't be.
  by aniceperson
• 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"?
  by bbminner
• "Million eyeballs" argument was always kinda meh.
  by deepsun
• The whole premise of a "giant secure open source C codebase" seems questionable

  Because code review is sometimes not much different from an idealized version of the halting problem, where you would have access to a formalized version of a specification.

  In other words, there is no strict definition of what is a security issue.

  by moritzwarhier
• In open source, someone (many, many) someone’s can at least check.

  Closed source…..

  by lazide
• The lesson here is that if a feature (at a minimum) does not have a associated test case, it is not actually a feature.
  by russdill
• To translate to Rust, it would have been "we missed a single line Rust check"...

  This is a bug involving intersecting concerns and a deficit of cross-domain knowledge. It probably would have been the same in Lisp or assembly language.

  by pjdesno