[flagged]
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
41–50 of 247 posts
[flagged]
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
> 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".
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…
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?
> 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".
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.
Earlier quoted context omitted.
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 did…
So you would still be asked for a passphrase, even though it's already available?
> 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".
Earlier quoted context omitted.
It absolutely is and they have most the enterprise market.
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/micro...
I don't have to re-enter my boot password after Sleep, so obviously the encryption key is still in memory.
Obviously your distro isn’t using cryptsetup-luksSuspend.
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.
Earlier quoted context omitted.
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…
> 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?
the term to look up is "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
Earlier quoted context omitted.
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/micro...
for enterprises, where this doesn't really matter, bitlocker is great.
It's still brittle, awkward and puzzlingly awful UX despite being the literal standard for the platform.
Compare it to any of the actively maintained alternatives, Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else) or LUKS on Linux.. heck, even Veracrypt is actually easier to understand and more robust.