Live data from Hacker News

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

mathstodon.xyz

41–50 of 247 posts

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

#41

[flagged]

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

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

#42
post #40
post #30

> 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…

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

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

#43
post #30

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

[deleted]

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

#44
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.

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

#45

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?

Exactly. Cryptsetup wouldn't know about the extra copy of the volume key in kernel memory. Which is why, dramatically, it appeared secure ("surely I wouldn't be asked to resupply the passphrase if the volume key is still in memory, right?").

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

#46
post #30

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

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.

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

#47
post #32

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

So exactly like FileVault?

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

#48
post #16

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.

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.

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

#49
post #42
post #40

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?

>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

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

#50
post #32

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.

if by "great" you really mean "fine".

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.

Post reply on HN