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?
Well yes and I don't see how this can be avoided.
Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
121–130 of 247 posts
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#122I 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 t…
Both Intel/AMD CPUs produced in the last 5 years or so support full transparent (to the OS) memory encryption. So cold boot attacks are a thing of the past if you enable this feature (it's typically disabled because it reduces RAM speed by about 0.5%).
The impact on performance is more along the lines of 1-2% on AMD (though it likely varies by generation (I did extensive benchmarking on Renoir wrt throughput/latency/gpu). But yes small enough to be insignificant unless you run LLMs or game on the iGPU. I imagine that it also uses marginally more power.
AMD also has a second encryption mode where the OS decides what gets transparently encrypted, it doesn't have to be everything. But that mode is poorly documented (or at least the documentation isn't accessible to peasants like me)
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#123It'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 .
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]
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#124I 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 t…
Both Intel/AMD CPUs produced in the last 5 years or so support full transparent (to the OS) memory encryption. So cold boot attacks are a thing of the past if you enable this feature (it's typically disabled because it reduces RAM speed by about 0.5%).
Recent news is that this isn't shipping on some consumer-grade CPUs from AMD. There, made it explicit enough there's no room for conversation. Here's the link:
https://arstechnica.com/security/2026/06/users-cry-foul-afte...
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#125https://xkcd.com/538/
(No, no, I take this stuff seriously too, but it had to be said)
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#126Earlier quoted context omitted.
The lesson here is that if a feature (at a minimum) does not have a associated test case, it is not actually a feature.
Yes, I agree. I find the addition of the regression test the true long-term fix. The code is just an opaque incantation that may or may not preserve some property we find worth preserving and we have no way of knowing it keeps preserving it over time as other parts of the system change. The test actually proves it and while it too can change it has more staying power because it's expressed at a higher level of abstra…
I have not looked into this specific issue, but are we sure that a regression here could have been avoided via a localized test? Maybe issues seem to arise from A implementing a feature with tests. B seeing that A lacks some functionality and adding it (potentially with tests), C seeing this (extra) functionality in A, and using in unintended ways not covered by tests (or in an unintended environment) + multiply by many layers of this A-B-C story up and down the stack.
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#127Earlier quoted context omitted.
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.
We have more issues with FileVault than we do with BitLocker, the latter being a fleet 5 times larger than the former. I find both “fine” for enterprise.
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#128Earlier quoted context omitted.
Okay, yes, sure. It definitely is the most-used encryption software for Windows. But I would never trust it a second, being proprietary and known for issues. You likely know that, but for the benefit of others: 38C3 - Windows BitLocker: Screwed without a Screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM
If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.
It's probably all security theater. There's only so much trust you can put into some shitty vendor's TPM implementation
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#129Earlier quoted context omitted.
Okay, yes, sure. It definitely is the most-used encryption software for Windows. But I would never trust it a second, being proprietary and known for issues. You likely know that, but for the benefit of others: 38C3 - Windows BitLocker: Screwed without a Screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM
If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.
If you are at all serious about security you don't consider Windows.
Depending on how serious you are you also don't consider MacOS.
And then you kinda have a couple of things to chose from but ultimately you need to build your own security depending on your attack/threat model
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#130I 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…
"Million eyeballs" argument was always kinda meh.
Maybe but still a little better than closed source like Windows. Everytime whem someone asked me if I could hack my way into his Windows PC I always told "After all it's Windows, how bad can it be?" Doing that since 25 years still waiting for a Windows machine that doesn't open... On the other hand I failed to open about 50% of Apple Devices I was asked to open and about 10% of Linux machines. (Not because Linux is insecure by itself but because most Linux distros install with insecure defaults and users don't care.)