9 ms·

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

panny 3mo ago
[flagged]
- bwat49 3mo ago
  I shutdown mine too but only because suspend is still a crapshoot on linux
  - jchw 3mo ago
    There will always be more suspend/resume bugs to work through. It varies a lot per device. I feel it's necessary to paint the picture for people who are curious what it means for it to be a crapshoot, so indulge me while I share my experiences. For work I have a ThinkPad T16 Gen 4 with the newer AMD gfx1151 iGPU. Works great. I have yet to witness any issues with suspend/resume. I suspect this is the case because it is running Ubuntu with Lenovo's own support package. Theoretically, from firmware to kernel, this is all tested and validated by Lenovo, like what certainly happens with every Windows laptop and all of the components that go into them. I also have a gen 1 Framework 16. I have seen it crash on suspend, but it is pretty rare, so I've just shrugged it off for now. It would be hard to debug, I don't see it every month despite using the thing every day. All of my desktops currently have perfectly reliable suspend resume, you can slam it all day and all night. The last time I ran into issues was a use-after-free issue in AMDGPU. Pretty alarming, although to be clear it never hit any LTS or vendor kernels that I am aware of. I hit it because I prefer to run the latest kernel on my personal machines. I have certainly owned laptops where suspend basically didn't work, or it would not stay suspended. I think this mainly went away when I started specifically picking laptops for Linux support. For Intel iGPUs and dGPUs, the track record has been flawless for me. I have a few of the new Battlemage cards that default to the xe kernel driver and those have been working very well as expected. So that's nice. I don't think this situation will be fixed until more hardware vendors are taking part in validating their stuff on desktop Linux and keeping track of the kernels. The current Linux model seems to be just dealing with whatever the vendors crap out for Windows, often full of weird ACPI behaviors and buggy firmware. It's not to say that the fault of the problems don't often lie with code in the Linux kernel, but they do not seem to wish to be bug-compatible with Windows and I think that is perfectly reasonable, so for problems that come from essentially broken firmware, it simply is going to need vendors to actually fix their shit. (And that includes AMD. The drivers are good in some regards, but it's hard to ignore AMD's stability issues even still. At this rate, more of the long outstanding AMD driver issues will get resolved by Claude than AMD engineers... Like with Panel Self Refresh on 7040 iGPU, apparently.)
- deleted 3mo ago
  [deleted]
- palata 3mo ago
  And I don't use GUIs, but it doesn't mean I have to be a jerk to people who are happy when their GUI gets better :-).
  - panny 3mo ago
    Suggesting I'm an exotic animal for being budget and environmentally friendly is being a jerk too.
    - deleted 3mo ago
      [deleted]
- ekunazanu 3mo ago
  > That's a you problem. I shutdown my machine when I'm not using it. "We designed the antennas correctly, you're holding the phone the wrong way."
  - adontz 3mo ago
    It's not a good analogy. Something is still on in suspend. Good you can control Linux kernel, but what about all other chips which may be an attack vector?
  - 1718627440 3mo ago
    Except shutting down and hibernate are two actions the user can literally select from the same menu.
- codedokode 3mo ago
  I am too lazy for that, and I hate that after boot you need to launch everything again.
  - 1718627440 3mo ago
    You can usually change that in the settings of the Desktop environment.
    - codedokode 3mo ago
      There is no universal support for restoring state between the apps. For example, Terminal won't run the scripts that were running, the browser will not automatically restore the pages etc, some apps might not launch or launch with wrong state. Gnome desktop environment cannot even remember the position and size of console windows, you are expecting too much.
  - IngoBlechschmid 3mo ago
    Suspend to (encrypted) swap might be a good middle ground between you and grandparent. Suspend to memory will (at best) protect your LUKS volume key, but other sensitive data remains. A couple of years ago, three security researchers from the TU Munich implemented a prototype for also encrypting (most) parts of the memory just before suspend, to address this limitation; but as far as I know, it was not upstreamed or developed further: https://www.sec.in.tum.de/i20/publications/fridgelock-preventing-data-theft-on-suspended-linux-with-usable-memory-encryption https://www.sec.in.tum.de/i20/publications/fridgelock-preven...
bitbasher 3mo ago
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.
- IngoBlechschmid 3mo ago
  Yes, if you simply suspend your laptop on most stock Linux distributions, then everything including the master key is still kept in memory. But Debian pioneered the (optional) cryptsetup-suspend addon. This issues a luksSuspend command which is supposed to wipe the key from memory, and on resume asks you to resupply your passphrase. Up to kernel 6.8, this worked as described; starting with kernel 6.9, it silently didn't.
  - naturalmovement 3mo ago
    FYI: VeraCrypt is not the defacto encryption software for Windows.
    - IngoBlechschmid 3mo ago
      Oh, which one is it? (You don't mean BitLocker, right?)
      - naturalmovement 3mo ago
        It absolutely is and they have most the enterprise market.
        nacs 3mo ago
        Reminder that by using Bitlocker, you're using a closed source encryption for which Microsoft will happily hand out your recovery key on request. https://www.forbes.com/sites/thomasbrewster/2026/01/22/microsoft-gave-fbi-keys-to-unlock-bitlocker-encrypted-data/ https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...
CodesInChaos 3mo ago
I don't have to re-enter my boot password after Sleep, so obviously the encryption key is still in memory.
- wrs 3mo ago
  Obviously your distro isn’t using cryptsetup-luksSuspend.
  - unethical_ban 3mo ago
    Correct. The point being made is: If one isn't re-entering their passphrase after suspend, how are they surprised that the encryption keys are somewhere in memory during suspend? edit: I see now that the prompt was being given and the keys still resided in memory.
    - ksbd-pls-finish 3mo ago
      Because debian users with luks-suspend have to re-enter their boot password after sleep.
    - weaksauce 3mo ago
      > The point being made is: If one isn't re-entering their passphrase after suspend, how are they surprised that the encryption keys are somewhere in memory during suspend? If that was the case for the people using the debian extra secure extension that should have wiped the memory clean then someone would have found this bug much earlier than two years. Their password was required to be re-entered even though the key was still in memory somewhere.
    - akerl_ 3mo ago
      The reason this bug is unexpected is that the user is expecting to have to enter their password (because they expect the key to be wiped on suspend), and then _they are_ asked for their password. But there was a copy of the key elsewhere in kernel memory that was never cleared.
naturalmovement 3mo ago
[flagged]
- stackghost 3mo ago
  Of course it's (indirectly) a symptom of that. What's the alternative? Proprietary closed-source operating systems owned by corps who can be compelled to insert covert backdoors? If BSD was as popular as Linux it would have the exact same problems.
- steve918 3mo ago
  I wonder if you think other OSes are any different? TempleOS is the only thing that comes to mind that doesn't fit your description and it's not practically useful. Any sufficiently large codebase is a mix of ideas and concepts implemented by different people with different priorities over a large timespan and if you can fit the entire thing in your head it's not very interesting or complex.
  - naturalmovement 3mo ago
    The *BSDs, Mac, and Windows all keep critical code in the same tree as the OS. Something like disk encryption would be immediately visible. So you don't have this mess of 80 different distros with 60 different versions of systemd, 20 that don't use it, a million kernel versions and it's all thrown together in a Costco-sized trash bag and we call the output "Linux".
    - yaris 3mo ago
      In my experience any software system (not just operating system) after crossing a certain limit on complexity and age looks exactly as hodgepodge of code pieces thrown together, sometimes from different sources even if developed by one org. All major OSs have long crossed those limits, I believe.
    - brainwad 3mo ago
      Windows for ages did not really keep all the code in one repo. There were like a dozen parallel repos for e.g. the shell, kernel, IE, etc. Also every feature was developed on team-level branches; integrating all those branches often caused unexpected bugs.
johnathan101 3mo ago
[flagged]
- IngoBlechschmid 3mo ago
  Right! Which is why integration tests for these kinds of features are all the more important. It was also fun to write, and enabled git-bisecting to isolate the specific kernel refactoring which introduced this bug: https://github.com/NixOS/nixpkgs/pull/532499 https://github.com/NixOS/nixpkgs/pull/532499
- whimsicalism 3mo ago
  AI reply, triggered my spidey senses
  - foltik 3mo ago
    Yup look at the rest of their comments
    - mrob 3mo ago
      We should just automatically ban every new account with "AI" in the about field. I don't think we'd lose much.
deng 3mo ago
> 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".
- nicce 3mo ago
  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.
  - deng 3mo ago
    > Anyone with physical access. I think it is understandable from the phrase. Sorry, I'm probably dense, I still don't get it. You steal a laptop, you open it, the screen is locked with a password/fingerprint whatever. How do you read out the RAM from that laptop?
    - john_strinlai 3mo ago
      >How do you read out the RAM from that laptop? the term to look up is "cold boot attack" (https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack). tons of cool live demonstrations of how it works on youtube if you've got the 20-40 minutes to spare
      - deng 3mo ago
        Still, this is a pretty crazy definition of "anyone".
kokada 3mo ago
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.
- IngoBlechschmid 3mo ago
  Sorry, aimed for a technically precise title and didn't want to bait clicks. Yes, this does not affect people on stock configurations for the plain reason that they wouldn't expect the volume key to be safe during suspend anyway. Debian's solution was ported to several (most?) other distributions and I guess quite a few people maintained private ports. The thread-keyring(7) manpage promises: "A thread keyring is destroyed when the thread that refers to it terminates." For their key upload (from userspace to kernelspace) mechanism, the cryptsetup project relied on this property; but kernel 6.9 introduced a regression invalidating this property.
  - kokada 3mo ago
    Thanks for the explanation, I am really not that familiar with `cryptsetup luksSuspend` and it is the first time I ever heard it exists. Like other people in this thread I first got confused "wait, how would this work since if you cleanup the keys from the disk during suspend you couldn't access the disk anymore after resuming", but after reading your thread in Mastodon plus other comments here it eventually became clear that this is a special case that you need both the correct patches plus the correct setup to use `cryptsetup luksSuspend` in place of the normal suspend. Can I ask one question? Why not use hibernation at that point? The reason I generally suspend to RAM is exactly because my password is long and annoying to type enough that if I know I am going to use the device soon I prefer to suspend instead of hibernation. Yes, technically resuming from suspend is faster, but it is also less secure (there are other interesting things in memory besides the LUKS keys) and also it uses more power.
fpoling 3mo ago
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.
- killerstorm 3mo ago
  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.
  - teravor 3mo ago
    > where does it get a key to decrypt memory on resume? you enter it...
- IngoBlechschmid 3mo ago
  > 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-preventing-data-theft-on-suspended-linux-with-usable-memory-encryption https://www.sec.in.tum.de/i20/publications/fridgelock-preven...
  - fpoling 3mo ago
    Interesting idea. On the other hand on the latest SSD with hardware encryption the raw disk speed under Linux can be over 5 GB/s so on my laptop with 64 GB of RAM the full restoration from disk takes like 45 seconds. With LUKS it is like 2 times slower. Which is not a problem at all. So I do not see much value in memory encryption in suspend.
teravor 3mo ago
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.
- someothherguyy 3mo ago
  https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Reset-Attack-Mitigation-Specification-Version-1.2-Revision-10_1April24.pdf https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-...
- bluebarbet 3mo ago
  Proper capitalization makes English easier to read.
bbminner 3mo ago
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"?
- moritzwarhier 3mo ago
  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.
  - bbminner 3mo ago
    On the other hand, it is (both halting and spec adherence) are checkable under compute and space constraints though? :) I'd say the biggest hurdle are means to describe the spec in way that is easy enough for a human to produce to make it feasible. Not a DB person either, but things like TLA+ seem very hard to write even with LLMs. Behavioral tests with an enumerable number of random paths to take (aka model checking - eg jepsen) seem more feasible. Although you can't check internal properties of the system (string `pass` or any of it's copies or parts are not held anywhere in memory at any point between lines A and B) unless we can check that two memory dumps are indistinguishable with different pass strings (assuming we abstracted away storage devices in a test environment).. Also not sure if it's "easy enough" to write such tests either. Maybe the reason is that OS domain objects / primitives are too complex and not "isolatable" enough / lack a clear contract at all? (Hence multi file refactorings that break invariants.)
- lazide 3mo ago
  In open source, someone (many, many) someone’s can at least check. Closed source…..
tombert 3mo ago
I don't think this bothers me. 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.
- bluebarbet 3mo ago
  Assuming the encryption key is strong, the wiping is theoretically redundant.
  - tombert 3mo ago
    Agreed. It's also very low effort and as such I'm ok with the redundancy.
    - bluebarbet 3mo ago
      Indeed. Truth be told, I do it too.
  - adrianmonk 3mo ago
    And assuming the crypto algorithm has no fundamental flaws, it's applied correctly, and the software implementation has no bugs. All of which are things people have on occasion believed to be true and found out later they were wrong about.
    - tombert 3mo ago
      I mean I don't think it's unfair to say that most of the battle-tested encryption is "uncrackable enough" for the consumer. If you're working for the NSA you need to worry about these things being cracked, obviously, but for the "I don't want a scammer to buy my laptop and get my social security number" situation, I think that you really can just assume that LUKS is uncrackable. That said, it takes like five minutes to boot a live Linux flash drive and run fdisk to delete the partitions and/or install Mint or something over the existing data, so I don't really see any reason not to do it, even if it's not strictly necessary.
quotemstr 3mo ago
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.
- fsckboy 3mo ago
  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.
  - deleted 3mo ago
    [deleted]
  - ltbarcly3 3mo ago
    This is correct, the memory encryption stuff is to prevent side channel attacks, not secure data.
    - quotemstr 3mo ago
      Memory encryption is secure under a certain threat model. It makes cold boot attacks, DIMM transfer attacks, and rowhammer much harder to pull off. It doesn't protect against everything and doesn't pretend to do so, but IMHO it's valuable anyway.
chazeon 3mo ago
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?
- polotics 3mo ago
  Well yes and I don't see how this can be avoided.
  - deleted 3mo ago
    [deleted]
  - Dylan16807 3mo ago
    Do you mean with with current software? How to avoid it in general is straightforward. If you're the only one with the disk password then the simple answer is make both passwords the same and make the different parts of the system communicate better. If you want multiple users, give them each a different boot password and encrypt a separate copy of the disk key with each one. That password can be their login password too, or it can encrypt their login.
  - chazeon 3mo ago
    I have always been thinking LUKS was supposed to be enrolled in TPM, so you should not have to enter this key manually; this is just to prevent someone from unplugging the hard drive and reading on another machine. Of course, this depends on one's threat model.
- WhyNotHugo 3mo ago
  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.
boutell 3mo ago
https://xkcd.com/538/ https://xkcd.com/538/ (No, no, I take this stuff seriously too, but it had to be said)
rmac 3mo ago
[dead]
moktonar 3mo ago
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?
- aniceperson 3mo ago
  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.
  - procaryote 3mo ago
    The whole point of luksSuspend is to not have the encryption keys in memory, as that actually does mean they could be extracted by an attacker who has taken the hardware.
shevy-java 3mo ago
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.
- IngoBlechschmid 3mo ago
  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.
storus 3mo ago
LUKS still keeps unencrypted header on the harddrive; real men use plain dm-crypt instead! Plausible deniability compatible.
- bawolff 3mo ago
  Ah yes, it is very plausible you just keep a partition of hundreds of gb of perfectly random data for no reason at all.
miki123211 3mo ago
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.
snmx999 3mo ago
Why is something this important not tested with every build?
liquid64 3mo ago
[flagged]
pullrun 3mo ago
[flagged]
NoXPgamedev1 3mo ago
[dead]

panny 3mo ago

[flagged]

bwat49 3mo ago
I shutdown mine too but only because suspend is still a crapshoot on linux
- jchw 3mo ago
  There will always be more suspend/resume bugs to work through. It varies a lot per device. I feel it's necessary to paint the picture for people who are curious what it means for it to be a crapshoot, so indulge me while I share my experiences. For work I have a ThinkPad T16 Gen 4 with the newer AMD gfx1151 iGPU. Works great. I have yet to witness any issues with suspend/resume. I suspect this is the case because it is running Ubuntu with Lenovo's own support package. Theoretically, from firmware to kernel, this is all tested and validated by Lenovo, like what certainly happens with every Windows laptop and all of the components that go into them. I also have a gen 1 Framework 16. I have seen it crash on suspend, but it is pretty rare, so I've just shrugged it off for now. It would be hard to debug, I don't see it every month despite using the thing every day. All of my desktops currently have perfectly reliable suspend resume, you can slam it all day and all night. The last time I ran into issues was a use-after-free issue in AMDGPU. Pretty alarming, although to be clear it never hit any LTS or vendor kernels that I am aware of. I hit it because I prefer to run the latest kernel on my personal machines. I have certainly owned laptops where suspend basically didn't work, or it would not stay suspended. I think this mainly went away when I started specifically picking laptops for Linux support. For Intel iGPUs and dGPUs, the track record has been flawless for me. I have a few of the new Battlemage cards that default to the xe kernel driver and those have been working very well as expected. So that's nice. I don't think this situation will be fixed until more hardware vendors are taking part in validating their stuff on desktop Linux and keeping track of the kernels. The current Linux model seems to be just dealing with whatever the vendors crap out for Windows, often full of weird ACPI behaviors and buggy firmware. It's not to say that the fault of the problems don't often lie with code in the Linux kernel, but they do not seem to wish to be bug-compatible with Windows and I think that is perfectly reasonable, so for problems that come from essentially broken firmware, it simply is going to need vendors to actually fix their shit. (And that includes AMD. The drivers are good in some regards, but it's hard to ignore AMD's stability issues even still. At this rate, more of the long outstanding AMD driver issues will get resolved by Claude than AMD engineers... Like with Panel Self Refresh on 7040 iGPU, apparently.)
deleted 3mo ago
[deleted]
palata 3mo ago
And I don't use GUIs, but it doesn't mean I have to be a jerk to people who are happy when their GUI gets better :-).
- panny 3mo ago
  Suggesting I'm an exotic animal for being budget and environmentally friendly is being a jerk too.
  - deleted 3mo ago
    [deleted]
ekunazanu 3mo ago
> That's a you problem. I shutdown my machine when I'm not using it. "We designed the antennas correctly, you're holding the phone the wrong way."
- adontz 3mo ago
  It's not a good analogy. Something is still on in suspend. Good you can control Linux kernel, but what about all other chips which may be an attack vector?
- 1718627440 3mo ago
  Except shutting down and hibernate are two actions the user can literally select from the same menu.
codedokode 3mo ago
I am too lazy for that, and I hate that after boot you need to launch everything again.
- 1718627440 3mo ago
  You can usually change that in the settings of the Desktop environment.
  - codedokode 3mo ago
    There is no universal support for restoring state between the apps. For example, Terminal won't run the scripts that were running, the browser will not automatically restore the pages etc, some apps might not launch or launch with wrong state. Gnome desktop environment cannot even remember the position and size of console windows, you are expecting too much.
- IngoBlechschmid 3mo ago
  Suspend to (encrypted) swap might be a good middle ground between you and grandparent. Suspend to memory will (at best) protect your LUKS volume key, but other sensitive data remains. A couple of years ago, three security researchers from the TU Munich implemented a prototype for also encrypting (most) parts of the memory just before suspend, to address this limitation; but as far as I know, it was not upstreamed or developed further: https://www.sec.in.tum.de/i20/publications/fridgelock-preventing-data-theft-on-suspended-linux-with-usable-memory-encryption https://www.sec.in.tum.de/i20/publications/fridgelock-preven...

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.

IngoBlechschmid 3mo ago
Yes, if you simply suspend your laptop on most stock Linux distributions, then everything including the master key is still kept in memory. But Debian pioneered the (optional) cryptsetup-suspend addon. This issues a luksSuspend command which is supposed to wipe the key from memory, and on resume asks you to resupply your passphrase. Up to kernel 6.8, this worked as described; starting with kernel 6.9, it silently didn't.
- naturalmovement 3mo ago
  FYI: VeraCrypt is not the defacto encryption software for Windows.
  - IngoBlechschmid 3mo ago
    Oh, which one is it? (You don't mean BitLocker, right?)
    - naturalmovement 3mo ago
      It absolutely is and they have most the enterprise market.
      - nacs 3mo ago
        Reminder that by using Bitlocker, you're using a closed source encryption for which Microsoft will happily hand out your recovery key on request. https://www.forbes.com/sites/thomasbrewster/2026/01/22/microsoft-gave-fbi-keys-to-unlock-bitlocker-encrypted-data/ https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...

CodesInChaos 3mo ago

I don't have to re-enter my boot password after Sleep, so obviously the encryption key is still in memory.

wrs 3mo ago
Obviously your distro isn’t using cryptsetup-luksSuspend.
- unethical_ban 3mo ago
  Correct. The point being made is: If one isn't re-entering their passphrase after suspend, how are they surprised that the encryption keys are somewhere in memory during suspend? edit: I see now that the prompt was being given and the keys still resided in memory.
  - ksbd-pls-finish 3mo ago
    Because debian users with luks-suspend have to re-enter their boot password after sleep.
  - weaksauce 3mo ago
    > The point being made is: If one isn't re-entering their passphrase after suspend, how are they surprised that the encryption keys are somewhere in memory during suspend? If that was the case for the people using the debian extra secure extension that should have wiped the memory clean then someone would have found this bug much earlier than two years. Their password was required to be re-entered even though the key was still in memory somewhere.
  - akerl_ 3mo ago
    The reason this bug is unexpected is that the user is expecting to have to enter their password (because they expect the key to be wiped on suspend), and then _they are_ asked for their password. But there was a copy of the key elsewhere in kernel memory that was never cleared.

naturalmovement 3mo ago

[flagged]

stackghost 3mo ago
Of course it's (indirectly) a symptom of that. What's the alternative? Proprietary closed-source operating systems owned by corps who can be compelled to insert covert backdoors? If BSD was as popular as Linux it would have the exact same problems.
steve918 3mo ago
I wonder if you think other OSes are any different? TempleOS is the only thing that comes to mind that doesn't fit your description and it's not practically useful. Any sufficiently large codebase is a mix of ideas and concepts implemented by different people with different priorities over a large timespan and if you can fit the entire thing in your head it's not very interesting or complex.
- naturalmovement 3mo ago
  The *BSDs, Mac, and Windows all keep critical code in the same tree as the OS. Something like disk encryption would be immediately visible. So you don't have this mess of 80 different distros with 60 different versions of systemd, 20 that don't use it, a million kernel versions and it's all thrown together in a Costco-sized trash bag and we call the output "Linux".
  - yaris 3mo ago
    In my experience any software system (not just operating system) after crossing a certain limit on complexity and age looks exactly as hodgepodge of code pieces thrown together, sometimes from different sources even if developed by one org. All major OSs have long crossed those limits, I believe.
  - brainwad 3mo ago
    Windows for ages did not really keep all the code in one repo. There were like a dozen parallel repos for e.g. the shell, kernel, IE, etc. Also every feature was developed on team-level branches; integrating all those branches often caused unexpected bugs.

johnathan101 3mo ago

[flagged]

IngoBlechschmid 3mo ago
Right! Which is why integration tests for these kinds of features are all the more important. It was also fun to write, and enabled git-bisecting to isolate the specific kernel refactoring which introduced this bug: https://github.com/NixOS/nixpkgs/pull/532499 https://github.com/NixOS/nixpkgs/pull/532499
whimsicalism 3mo ago
AI reply, triggered my spidey senses
- foltik 3mo ago
  Yup look at the rest of their comments
  - mrob 3mo ago
    We should just automatically ban every new account with "AI" in the about field. I don't think we'd lose much.

deng 3mo ago

> 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".

nicce 3mo ago
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.
- deng 3mo ago
  > Anyone with physical access. I think it is understandable from the phrase. Sorry, I'm probably dense, I still don't get it. You steal a laptop, you open it, the screen is locked with a password/fingerprint whatever. How do you read out the RAM from that laptop?
  - john_strinlai 3mo ago
    >How do you read out the RAM from that laptop? the term to look up is "cold boot attack" (https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack). tons of cool live demonstrations of how it works on youtube if you've got the 20-40 minutes to spare
    - deng 3mo ago
      Still, this is a pretty crazy definition of "anyone".

kokada 3mo ago

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.

IngoBlechschmid 3mo ago
Sorry, aimed for a technically precise title and didn't want to bait clicks. Yes, this does not affect people on stock configurations for the plain reason that they wouldn't expect the volume key to be safe during suspend anyway. Debian's solution was ported to several (most?) other distributions and I guess quite a few people maintained private ports. The thread-keyring(7) manpage promises: "A thread keyring is destroyed when the thread that refers to it terminates." For their key upload (from userspace to kernelspace) mechanism, the cryptsetup project relied on this property; but kernel 6.9 introduced a regression invalidating this property.
- kokada 3mo ago
  Thanks for the explanation, I am really not that familiar with `cryptsetup luksSuspend` and it is the first time I ever heard it exists. Like other people in this thread I first got confused "wait, how would this work since if you cleanup the keys from the disk during suspend you couldn't access the disk anymore after resuming", but after reading your thread in Mastodon plus other comments here it eventually became clear that this is a special case that you need both the correct patches plus the correct setup to use `cryptsetup luksSuspend` in place of the normal suspend. Can I ask one question? Why not use hibernation at that point? The reason I generally suspend to RAM is exactly because my password is long and annoying to type enough that if I know I am going to use the device soon I prefer to suspend instead of hibernation. Yes, technically resuming from suspend is faster, but it is also less secure (there are other interesting things in memory besides the LUKS keys) and also it uses more power.

fpoling 3mo ago

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.

killerstorm 3mo ago
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.
- teravor 3mo ago
  > where does it get a key to decrypt memory on resume? you enter it...
IngoBlechschmid 3mo ago
> 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-preventing-data-theft-on-suspended-linux-with-usable-memory-encryption https://www.sec.in.tum.de/i20/publications/fridgelock-preven...
- fpoling 3mo ago
  Interesting idea. On the other hand on the latest SSD with hardware encryption the raw disk speed under Linux can be over 5 GB/s so on my laptop with 64 GB of RAM the full restoration from disk takes like 45 seconds. With LUKS it is like 2 times slower. Which is not a problem at all. So I do not see much value in memory encryption in suspend.

teravor 3mo ago

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.

someothherguyy 3mo ago
https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Reset-Attack-Mitigation-Specification-Version-1.2-Revision-10_1April24.pdf https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-...
bluebarbet 3mo ago
Proper capitalization makes English easier to read.

bbminner 3mo ago

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"?

moritzwarhier 3mo ago
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.
- bbminner 3mo ago
  On the other hand, it is (both halting and spec adherence) are checkable under compute and space constraints though? :) I'd say the biggest hurdle are means to describe the spec in way that is easy enough for a human to produce to make it feasible. Not a DB person either, but things like TLA+ seem very hard to write even with LLMs. Behavioral tests with an enumerable number of random paths to take (aka model checking - eg jepsen) seem more feasible. Although you can't check internal properties of the system (string `pass` or any of it's copies or parts are not held anywhere in memory at any point between lines A and B) unless we can check that two memory dumps are indistinguishable with different pass strings (assuming we abstracted away storage devices in a test environment).. Also not sure if it's "easy enough" to write such tests either. Maybe the reason is that OS domain objects / primitives are too complex and not "isolatable" enough / lack a clear contract at all? (Hence multi file refactorings that break invariants.)
lazide 3mo ago
In open source, someone (many, many) someone’s can at least check. Closed source…..

tombert 3mo ago

I don't think this bothers me. 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.

bluebarbet 3mo ago
Assuming the encryption key is strong, the wiping is theoretically redundant.
- tombert 3mo ago
  Agreed. It's also very low effort and as such I'm ok with the redundancy.
  - bluebarbet 3mo ago
    Indeed. Truth be told, I do it too.
- adrianmonk 3mo ago
  And assuming the crypto algorithm has no fundamental flaws, it's applied correctly, and the software implementation has no bugs. All of which are things people have on occasion believed to be true and found out later they were wrong about.
  - tombert 3mo ago
    I mean I don't think it's unfair to say that most of the battle-tested encryption is "uncrackable enough" for the consumer. If you're working for the NSA you need to worry about these things being cracked, obviously, but for the "I don't want a scammer to buy my laptop and get my social security number" situation, I think that you really can just assume that LUKS is uncrackable. That said, it takes like five minutes to boot a live Linux flash drive and run fdisk to delete the partitions and/or install Mint or something over the existing data, so I don't really see any reason not to do it, even if it's not strictly necessary.

quotemstr 3mo ago

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.

fsckboy 3mo ago
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.
- deleted 3mo ago
  [deleted]
- ltbarcly3 3mo ago
  This is correct, the memory encryption stuff is to prevent side channel attacks, not secure data.
  - quotemstr 3mo ago
    Memory encryption is secure under a certain threat model. It makes cold boot attacks, DIMM transfer attacks, and rowhammer much harder to pull off. It doesn't protect against everything and doesn't pretend to do so, but IMHO it's valuable anyway.

chazeon 3mo ago

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?

polotics 3mo ago
Well yes and I don't see how this can be avoided.
- deleted 3mo ago
  [deleted]
- Dylan16807 3mo ago
  Do you mean with with current software? How to avoid it in general is straightforward. If you're the only one with the disk password then the simple answer is make both passwords the same and make the different parts of the system communicate better. If you want multiple users, give them each a different boot password and encrypt a separate copy of the disk key with each one. That password can be their login password too, or it can encrypt their login.
- chazeon 3mo ago
  I have always been thinking LUKS was supposed to be enrolled in TPM, so you should not have to enter this key manually; this is just to prevent someone from unplugging the hard drive and reading on another machine. Of course, this depends on one's threat model.
WhyNotHugo 3mo ago
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.

boutell 3mo ago

https://xkcd.com/538/ https://xkcd.com/538/ (No, no, I take this stuff seriously too, but it had to be said)

rmac 3mo ago

[dead]

moktonar 3mo ago

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?

aniceperson 3mo ago
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.
- procaryote 3mo ago
  The whole point of luksSuspend is to not have the encryption keys in memory, as that actually does mean they could be extracted by an attacker who has taken the hardware.

shevy-java 3mo ago

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.

IngoBlechschmid 3mo ago
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.

storus 3mo ago

LUKS still keeps unencrypted header on the harddrive; real men use plain dm-crypt instead! Plausible deniability compatible.

bawolff 3mo ago
Ah yes, it is very plausible you just keep a partition of hundreds of gb of perfectly random data for no reason at all.

miki123211 3mo ago

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.

snmx999 3mo ago

Why is something this important not tested with every build?

liquid64 3mo ago

[flagged]

pullrun 3mo ago

[flagged]

NoXPgamedev1 3mo ago

[dead]