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.
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.
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.
> Can I ask one question? Why not use hibernation at that point?
Not GP but hibernation is completely disabled for lockdown kernels[1], which is always enabled when booting under secure boot for kernels trusted by the Microsoft secure boot keys (it is considered a requirement to get you shim signed by rhboot[2] as it is believed that Microsoft considers it a hard requirement, as otherwise you could chain-load a patched version of Windows under secure boot).
This doesn't matter for custom kernels but most official distro kernels are built this way to be signed, as otherwise they won't Just Work (TM) on modern laptops. If you disable secure boot then hibernation works again, though I must admit I'm a little surprised how many people seem to disable secure boot.
To be fair the security argument for secure boot is weakened by the fact that everything is signed by the same set of trusted keys when using the default Microsoft trust root, but on paper it does protect against certain kinds of attacks. (In theory, distros could use UEFI setup mode to only trust their own keys but this causes issues with signed firmware and there have been cases of bricked devices.)
Even if you use full disk encryption, without secure boot someone can replace your kernel (or bootloader to inject a bad kernel) with one that is backdoored without you noticing. So someone only needs temporary access to your powered off laptop to gain access to your data once you use it again. I've had my devices taken away from me at airports and I know people who have had their laptops mysteriously missing screws when travelling overseas, so this is not an entirely hypothetical problem.
Of course, the fact that hibernation doesn't work on Linux is a negative from a practical security perspective, and so stuff like luksSuspend on suspend end up being quite important. And trusting the Microsoft keys is a little concerning if you're worried about state actors.
If you use TPM-backed keys with tools like systemd-pcrlock you can get some similar (and arguably nicer) protections but in practice nobody locks to enough PCRs to provide more protection than you would get if you also enabled secure boot.
The man page does say that but there is no mechanism to actually make use of that at the moment.
It's not enough for it to be encrypted, it needs to be encrypted with a single-purpose key that is not known by the user. Otherwise the user could replace the hibernation image with a malicious one and chain-load a backdoored version of Windows in secure boot mode, which violates the security model that Windows has and Linux needs to uphold to continue to get signed by Microsoft.
It is my understanding that there is work on generating a non-exportable single-purpose key using the TPM to make this work, but that's still a WIP.
> Can I ask one question? Why not use hibernation at that point?
The sibling post by cyphar gives a good reason; while UEFI Secure Boot has its own share of issues, it can be a valuable ingredient in defending against evil maid attacks.
But another reason is... convenience. Resuming from RAM is faster than resuming from disk, especially so if your "disk" is actually just a USB flash drive. I know that it might be a bit weird to ask for convenience when the motivation is security. But I argue that there are use cases where the tradeoff is sound.
With hibernation, all your data is safe but the inconvenience might seduce you not to use it.
With suspend to RAM and your distro's version of cryptsetup-suspend (and the kernel patch or alternatively the cryptsetup workaround), only your volume key (and hence the bulk of your data, potentially terabytes worth of sensitive information) is safe, but sensitive data in memory (recent files, recent chat messages, session cookies, ...) is not. But on the other hand it's quick.
Some people use a combination: suspend to RAM for short breaks, where they expect to remain physically able to fully switch off the laptop when something happens; and suspend to disk for longer breaks.
I'm confused why you're saying this is a Debian-specific thing -- luksSuspend is upstream and was added back in 2009[1] in release v1.1.0[2]. I've used it (though somewhat sparingly) on Arch and openSUSE in the past and it definitely exists on non-Debian distributions. Maybe you're thinking of the automatic integration with system suspend? If so, that's kind of besides the point -- luksSuspend documents itself as clearing the keys from system memory, which stopped happening in Linux 6.9 due to the referenced refactor patch.
Though it should be noted that it seems that this is actually a bug in cryptsetup in that it was depending on very specific lifetime behaviour of kernel keyring keys, when it arguably should've been more explicitly cleared by userspace[3].
I've used this feature on arch its available on bog standard luks but as far as I know it's not used by default when you suspend.
You are thinking of the machinery to actually actuate suspend to ram after a luks suspend in a way that is actually useful which was first a Debian targeted thing then arch and used by default by neither.
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.
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.
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?").
It was still more secure than the default if I understand this correctly. On resume from suspend the laptop would still be locked by the encryption key and without access to the disk even if you can somehow circumvent the lock. The only insecurity was that somewhere in the kernel memory the key still exists so if you can somehow extract that from the live system you can unlock it.
Yes, you are right: LUKS encryption protests your data at rest. An attacker which steals your disk can only gain little, like the information that you have used LUKS (unless you put your LUKS headers elsewhere, separated from the disk) and perhaps disk and disk sector usage statistics.
You need to get quite specific on actual attacks to call this insecure to be clear.
Having access to the raw RAM of a machine suspended but demanding the key to resume is certainly possible but the number of attacks where you don't need this bug is "almost all of them" given at that point if the machine ever unlocks you won in this hypothetical attack even with a bug fix.
If the key has been purged but you can read RAM, then you can do two things:
1. You can extract whatever user data happens to be in RAM.
2. If you can either write RAM or reboot into your own OS, and then return the device to the unsuspecting user who will put in their password, then you can run a fake password dialog and get everything.
1 is bad, since there may be quite a lot of user data in RAM. But it’s not quite as bad as having the disk key, which gives the attacker all the data plus the future ability to decrypt or modify user data given only the physical disk. (Still, a better solution would be encrypting the hibernation image, preventing this attack entirely.)
2 is fully bad, but in many plausible scenarios (e.g. seized device) the attacker cannot just return the device to the user without them knowing something happened. Or even if they can, the method of RAM access may be one where reads are much more practical than writes, such as cold boot attacks involving physically swapping out the RAM.
The seized device scenario is starting to get very specific though: in the actual cases it's relevant like the Silk Road take down the device was intercepted while open.
It's of some frustration to me that more security devices don't have a "pull pin to destroy" function available in them for this reason if you have any type of threat model where this applies: e.g. when I thought about using a Yubikey to secure remote access, a core problem is you can't quickly wipe a Yubikey in your possession - and while they're fragile in daily use, they're also surprisingly hard to intentionally destroy quickly.
You need to only have the ability to execute code after the hibernation not before and the machine needs to be permanently unavailable to the user after.
As I said quite rare situations.
If you can read this kind of data you have the ability to run code which means you already owned the entire operating system making capturing the key next entry beyond trivial.
You don't need to spoof anything, we assume here you can read the key from RAM remember.
If you could execute code before hibernation you similarly already had the key.
It also prevents the addition of content onto the disk, providing tamper-protection in addition to secrecy.
For example, spyware/remote-control software would open new routes to penetrate your employer's systems, or steal money from your bank account, bypassing other security measures like an additional layer of encryption on your password mode, or 2FA.
Even a relatively unsophisticated foe could connect your hard drive, dump incriminating data on it to frame you, put it back, and then call the authorities with a tip.
You are generally guarding against the device being shutdown.
Anything assuming the OS is running is already into "well that is easy" territory since if the OS is running those keys are in the same place as this attack leverages.
I've been wondering why hibernate didn't work with encryption, because this seems like the extremely obvious way to handle it, but I have struggled to find anything about it for years - glad to hear it does exist!
But yeah, also rather obviously it's inherently a bit leak-prone. Though it seems probably pretty simple to test, just hibernate and scan all stored data. They could probably even do it on shutdown, as a hash of the key data would be sufficient to detect the key.
The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed).
BitLocker with a password (the equivalent of the LUKS configuration in question) does not share these issues.
Bitlocker with a password has always felt like a second class citizen to me. You have to dig into a bunch of group policies to use it. Maybe most people don't even realize it exists.
Yah, it seems blatantly hostile how much they hide it.
I can understand the default being TPM-only + online key backup, huge amounts of the population forget their login passwords (which can be involuntary, e.g. head injury) and huge amounts of them still want some backup way to access their data rather than losing it forever.
But for anyone who cares just a little more, or would prefer to lose data in those situations, it's such an abnormal and hidden path that it's clearly blocking tons of people from choosing it.
For the system drive they seem to really strongly prefer PIN, which also doesn't have the problems linked above. I was going to use PIN as my example but didn't want to explain another set of recent BitLocker conspiracy theories yet again; maybe I should have.
It is annoying that they hate password for system drive _so_ much; the reason is actually pretty obvious when you think about how their "happy path" AD-driven enterprise deployment with stupid password rotation requirements works (and FileVault is a nightmare in this scenario), but I wish they'd make it easier for individual power users.
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.
Just a PIN? For most people that's a 4-digit number, which has a worst-case scenario of 10,000 attempts and a median of only a few hundred. Why not use a full 8-digit password?
> For example, when BitLocker is used with a TPM + PIN configuration, the number of PIN guesses is limited over time. A TPM 2.0 in this example could be configured to allow only 32 PIN guesses immediately, and then only one more guess every two hours. This totals a maximum of about 4,415 guesses per year. If the PIN is four digits, all 9999 possible PIN combinations could be attempted in a little over two years.
In that case, the median would still be just over a month, if the PINs were entered in order of how commonly they are used. Even the worst case of two years is still soon enough for a lot of data still be useful.
Also, how is the time limit enforced? With hardware access, it would be easy to change time or increase the clock rate, as well as many other side-channel attacks that could eliminate the wait altogether.
I found some pictures of TPM modules with crystal oscillators, so those could keep time while powered on, but wouldn't be able to keep time while off. It would be possible to only count time while on, but that would be really annoying to a legitimate user that kept turning off the computer, waiting for the time limit to expire, especially if it doesn't tell the user how much time is left.
Anyway, crystal oscillators connect to one input pin and one output pin, with an internal feedback circuit that causes the crystal to resonate. It's possible to change out the crystal for a higher frequency, or even directly drive the input pin for a much higher frequency. Semiconductor manufacturers often only characterize the limit of the feedback circuit, but not the limit of the internal clock circuitry when directly driven. Considering that the logic design supports an SPI bus running up to tens of megahertz, it's totally possible that the crystal input could be driven at a similar speed, possible a thousand times faster than a normal real-time clock oscillator.
There would be several ways to mitigate such an attack, but a quick search for TPM side-channel attacks brings up multiple much simpler vulnerabilities, so it's not likely that TPM manufacturers are putting any real effort into mitigation.
Most enterprises require a 12 digit code, to meet a specific security standard. Bruteforcing that, with hardware access restricted by TPM, would take a very, very long time.
A quick search for "TPM side-channel attack" substantiates that claim.
Looking at the manufacturers of TPM ICs, it makes sense. Most of them make microcontrollers that have code-protect bits in them that are notorious for being susceptible to simple side channel attacks, but also for not being a target simply because no one cares about the object code on any random product's microcontroller.
I worked at a company that sold a microcontroller that executed from external memory, so there was no possible way to have built-in code protect bits, and some potential customers complained until we included a library to encrypt the external memory, run a small unencrypted bootloader which included the a plain-text decryption key, then run the encrypted program. That checked their box, despite doing nothing useful.
And then depending on how "serious" you are you also don't consider Linux.
But also, threat models and the best way to mitigate them aren't really a linear scale of being <unserious> to <serious>, but a complex consideration of a particular situation.
People just plain suck at opsec. Like Che Guevara might have had a longer career as a revolutionary if he'd used his one time pads only once.
Back in the late 1980s it was clear that it would be no problem at all to hook up a hard drive to a digital phone exchange and record all the calls! I had a strict policy of "don't talk about anything illegal using electronic communication" even when it was rather banal stuff like selling weed.
The carelessness of people at Facebook documenting policies that nobody in their right mind would document boggles my mind: you might as well leave it mysterious why you didn't crack down on scam ads, for instance. When I've been involved in minor conspiracies, say when we had an HR problem with another employee, I've always made the point to meet furtively in person and avoid leaving a paper trail so that I'd never need to explain an email I wrote in front of an unfriendly audience.
If you think for one single second that businesses and governments who rely on a lost disk being secure don’t trust bitlocker, I have oceanfront property in Missouri to sell you.
Bitlocker + PIN is as secure as anything.
A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.
> A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.
First off: I agree with your thesis, BitLocker with PIN is Just Fine, equivalent in all practical senses to most disk encryption strategies, and an enterprise standard.
I post this to reinforce what you're saying, because there are a ton of weird theories about how this works that make people think it's weaker than it is.
BitLocker with PIN works like this:
* BitLocker seals an encrypted key IK into the TPM using a policy on the TPM which requires the SHA-256 of the PIN to be sent to the TPM to unlock the record (and has anti-hammering at the TPM level).
* Encryption using another key called the SK. Once the OS acquires the e(IK) from the TPM, it needs to derive SK to decrypt the IK. The SK is generated by applying a salt and 0x100000 rounds SHA256 to the PIN.
* The IK can then decrypt the VMK, which can decrypt the FVEK which is the actual data encryption key used on the on-disk data.
Fully offline (no TPM access) decryption is hopeless; the IK is random and not attached to the PIN at all.
Fully online decryption relies on TPM anti-hammering; if you can manage to hammer the TPM and find a PIN where h(PIN) matches, you can then use the PIN to generate both h(PIN) (unseal TPM) and reverse e(IK).
Partially offline decryption (imagining TPM content is somehow dumped, for example by bus sniff while a user uses their PIN) relies on bruteforcing the key for e(IK), which is possible but difficult (IMO Microsoft should ratchet this up or use a more expensive algorithm than SHA-256 in order to deal with modern hardware capabilities, but they have issues like FIPS to deal with that make new algorithm selection difficult).
I appreciate your desire to shit on Microsoft for everything they’ve ever done, but they got BitLocker with PIN right.
Explain how an exploit can decrypt the drive without the portion of the key that the user must enter. The computer doesn’t know the entire key, and can’t decrypt the drive without it, or the recovery key. This is why BitLocker with PIN hasn’t been defeated yet. I don’t understand how it could ever be defeated without entering the PIN.
veracrypt lost their drivers license so afaik you should avoid it since it cannot update its drivers any longer. didnt see any news about them reacquiring that license
aah cool, thank you..100% missed the update :). thanks! thats good to read honestly lol. not that i use windows much but i felt it was MS trying to undermine it. happy it got restored and there remains an alternative to butlocker.
Tangentially: Microsoft telemetry collects the serial# of your devices and reports it (with your IP and MS account) back to the mothership, and some printers embed their serial# in printed pages.
So take countermeasures if you print something out criticizing any groups that abuse political or law-enforcement powers.
Only if you store your key with Microsoft, which is not required or the default if you're using a local account which I assume most privacy sensitive people are.
Unfortunately Microsoft keeps working to destroy that option and force consumers to make a remote account. [0][1] Their consistent moves towards wanting to co-own my computer were one of the many last-straws that made me migrate everything to Linux this year.
> Local-only commands removal: We are removing known mechanisms for creating a local account in the Windows Setup experience (OOBE). While these mechanisms were often used to bypass Microsoft account setup, they also inadvertently skip critical setup screens, potentially causing users to exit OOBE with a device that is not fully configured for use. Users will need to complete OOBE with internet and a Microsoft account, to ensure device is setup correctly.
Not to mention that unless the bitlocker activation flow changed recently, it specifically asks you how to store your backup keys, with a choice given been local options (eg. usb drive, printing it off, etc.) and saving it to your microsoft account.
dell opts you in without telling you. one day you'll just reboot to an unexpected bitlocker screen and have to figure out whether you're getting ransomwared before eventually digging a key out of your microsoft account you weren't aware was there.
Agreed it's optional (I've seen and used that option), but are local accounts even a thing any more? Or are you just referring to "not MDM controlled" accounts?
Yes, most certainly. You can easily convert to a local account in Settings, and there is still a workaround to avoid using a Microsoft account during install. Or the far more stable and reliable method of using Rufus to create the installer ISO which has an option to use a local account without the hassle.
Rufus for install + Win11Debloat post-install is a nearly effortless way to get an ad-free, local only Win 11 install that persists through updates which removes pretty much all notorious Win 11 pain points (plus additional customization if desired).
I've been doing it for years and so reading Windows 11 complaints on HN always feels like they're coming from a strange parallel universe since I never have to deal with any of it.
"modify the windows installer via a binary patch to work around the continued bloat and feature crippling" really isn't "local accounts are supported" in my book. that's like saying "the 1965 ford mustang was an electric car" because someone did a conversion on it a few years ago.
and the actually supported workarounds have disappeared, last I saw - bypassnro and disabling internet both failed completely for me, the last time I tried. maybe they have come back (it has intermittently failed in the past and come back), but they're very clearly doing more to remove it than they did a year+ ago when bypassnro worked easily and consistently.
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.
managing a fleet of 100+ laptops with bitlocker is a breeze. its so seemless that the users don't even realize its enabled (i.e. no UX issues, at all).
on the other hand, i am not managing 100+ laptops that use veracrypt. sounds absolutely awful. i've never managed an apple fleet, so i can't speak to that, and will take your word on it.
for personal use, i do not recommend bitlocker (or windows, really), but for already-windows enterprises? absolutely
Flicking a button to turn something on is not what I'm talking about, that's normally the easy part of any setup, and I judge people harshly who only take that aspect of something into consideration when discussing systems.
Brittle is what happens when you haven't logged on to the machine in 60 days, trust with AD is broken, TPM has a glitch and wipes the in device key and forces you into recovery... or god forbid you service the laptop and now you have to enter recovery mode.
Then you're in a nightmare, trying to give someone a super long passphrase over the phone is a not-too-uncommon occurance.
That's assuming you have a good policy for storing the recovery keys. Too loose and they're handed out to everyone, sort of defeating the purpose: too strict and you need the IT department (or specific members), and its still predicated on the notion that you have a policy for it... Given that Admins are a dying breed... I don't think this is workable.
If you compare with Filevault on MacOS: which tracks the credentials of the logged in user; there's no "issue" if the device loses trust because ultimately you always use the real unlock key: not something cached in a "secure storage".
Having dealt with FileVault in this context, it's also frustrating; it's really common to have it fail to follow the logged-in user's credentials, and if you use any kind of federated login, you will frequently get users with FileVault passwords that are either ahead of or behind their system login password.
I think both approaches are valid trade-offs and I think that the default Secure Boot BitLocker configuration, for all its architectural tradeoffs, can probably be credited for an enormous amount of data loss mitigation originating from used hard drives alone.
maybe i am missing something, but how did veracrypt solve all of the admin and policy issues you’re bringing up? (specifically for large enterprise fleets)
We're sort of talking about two things and conflating them.
I'm sort of talking about my user experience of the system, and I'm getting it in the neck from helpdesk.
Enterprise rollouts are different from anything I actually deliver, despite pushing out thousands of windows servers: I have complete control over those.
Same as my local PC.
But as a user on a PC I'd buy from a store, I'm not going to forget my password without expecting to lose access to my system.
>We're sort of talking about two things and conflating them. [...] But as a user on a PC I'd buy from a store
i said multiple times that i was talking about a managed fleet in an enterprise environment, and even specifically said that i dont typically recommend bitlocker for personal use, so i am not really sure what to say here. i was really clear.
Yes, but I still think we've been talking passed each other.
I doubled down on "it's fine but not excellent" when I should have pulled away and explained that the main issues I have are about bitlocker as a user.
FileVault absolutely has an optional iCloud Keychain escrow. That’s how the “unlock with Apple Account” feature works. Apple doesn’t have the keys for iCloud Keychain, but it is still stored in iCloud.
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.
Veracrypt is more difficult to set up - whether on one machine or a fleet. Bitlocker is a few buttons in the UI, configurable via Group Policy, and so much more.
D) Written down on a scrap of paper when I set up the laptop
the fact that they never ask for the passphrase is a weakness of the system. Because now you have an extremely difficult situation as soon as you're off the happy path.
It's also like 64 characters alphanumeric with no capability to copy/paste.
Compare it to Vera/Filevault where the access key is the users passphrase. In MacOS it's literally your account password, which follows along with your in-OS account credentials.
Or nowhere you know at all if you're a non-technical user who was on a local account Win 11 setup who was tricked by microsoft dark pattern pop-ups getting you to go to "online accounts" which automatically and silently encrypts your drives in the background and then tells you to go to to some shady domain called aka.ms (with another computer, since yours is now locked on a bluescreen and unusable). Basically a typical ransomware message. In truth in this case it's #1 (uploaded to Microsoft) but the non-technical user doesn't know that. Even I thought aka.ms screen was ransomware when my parent called me saying their computer had a "virus".
That happens with Veracrypt as well. I have plenty of friends and family who can't remember their WiFi password without remembering where it was written down, and they use that far more often than an encryption recovery code.
In fleets users wouldn't even be setting up their own code.
I've installed Windows thousands of times on dozens, probably hundreds of systems - long ago I even worked on the Windows team and was installing it every day - and in the last 20 years (yes, I ran Vista Ultimate in 2006) I've had to deal with Bitlocker recovery prompts perhaps 20 times - not 20 times per machine, 20 times across all of them.
"iCloud account: Click “Allow my iCloud account to unlock my disk” if you already use iCloud. Click “Set up my iCloud account to reset my password” if you don’t already use iCloud."
"FileVault Full Disk Encryption (FDE) recovery keys are, by default, sent to Apple if the user requests them. Only one payload of this type is allowed per system."
makes me wonder if there is potential for a more "main stream"/by default friendly version of this, where the key during suspend is encrypted using the TPM even if the TPM isn't a possible unlock from cold boot (i.e. no TMP encrypted volume key in the LECS headers/meta only temporary in memory during suspend)
or the alternative (for more convenient usage) for single user systems auto login on boot + use disc password for doas/sudo?
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)
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:
Future AGESA updates will still include memory encryption for all processor models. It's one of the rare instances of consumer backlash creating a clear and immediate response.
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.
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.
> 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.
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.
You can just wipe the luks header as a nice middle ground.
Luks uses an anti-forensics algorithm that requires the entire volume key being available to unlock the disk at all (it combines the blocks of the key with some diffuse algorithm and xors stuff together to form the actual master key), so in theory you can just clear one sector of the volume key and the whole thing should be unrecoverable.
What I mean is that if even one block of the key is missing you can't guess the rest easily.
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.
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"?
While I can see the shortcomings of C and generally don't recommend it for new projects I don't see this particular bug as a good example of something Rust's borrow checker or some other language's type system will catch. I don't think even static analyzers can catch this.
In my experience a substantial portion of gnarly bugs come down to a violation of a high-level system invariant and those do not strike me as something that can be automated. Even with something like Lean you can prove your program satisfies certain properties but you need to have thought about those properties in the first place. The proof doesn't discover the invariant for you.
If you'd had thought about the relevant security property you could have written a regression test for it which is not hard. IMO the really hard part isn't expressing the implementation safely, but it's the realization that this was a property the implementation needed to preserve.
I agree re Rust vs C - this is not (only) a language issue. What would (roughly) the invariant be here?
In another thread comment below i argue that maybe the system (OS) itself is so complex that it lacks clear contract / the contract evolves too quickly over time (as other parts of the code need to change the given piece of code to extend it to their use case) and that defies clear encoding?
Or we lack easy enough means to describe specs? I tried reading jepsen spec earlier today and despite it being an "integration test" of sorts, it is far from "simple".
Can an entire OS or a system of comparable complexity be decomposed into objects simple enough that their entire intended behavior (with all edge cases) can be explained in a paragraph of human text + half a screen of dense behavioral "spec" - if i do X and do Y, Z should come out / hold _no matter what happens in-between_. Or that's what asserts + fuzzing is effectively supposed to do? Is there a clear distinction between invalid input and failed invariant in typical C code? I guess error code vs seg fault?
This is in effect a state machine, and when you have a type system more complex than C's you can encode state transitions in the type system (either by having state transitions explicitly return a new return type or by using sum types). You still need to architect the system to encode the invariants in types. No language will fix all logic bugs for free. But you can leverage language features to reduce their number.
> You still need to architect the system to encode the invariants in types.
That's the problem though, right? If it's pointed out we all agree the "do not keep credentials alive" is a property that should hold and we can leverage whatever the environment offers to help preserve it. I fully agree modern languages have amazing support for this, but in C you can still run tests. Let's just say I don't think the language's inability to express logic of this kind held all those involved back from testing for it. I personally find "we just didn't think of it" much more likely.
That said, I am not a fan of C and recommend leveraging whatever fantastic modern tooling is available to you.
Like set an generic marker struct IsEncrypted<T> where T is yes or now and only allow its state to change when proven and then write the shutdown function to only take the yes variant?
If you think open source is bad, wait till you see enterprise code. I'm talking full auth bypass due to the stupidest crap. You can do that in any language if you have fools working on the code base.
I explicitly make sure services I lead have Integration tests in CI pipeline to validate the "negative paths" against all APIs with missing, invalid, un-authorised identities, expired, un-authenticated tokens. Of course that still doesn't cover every surface, but even that gets sideways glances from some folks who think we should just test happy paths and why we're testing for access controls in Integration tests.
Even security code. Fortinet, a vendor whose entire thing is security for your network, is consistently getting caught out with default passwords, backdoors, etc.
"It is better to keep your mouth closed and let people think you are a fool than to open it and remove all doubt" is a reason why people don't open-source more often.
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.
I think https://news.ycombinator.com/item?id=48766436 is a practical answer. A marker that can't be forged (without explicitly malicious code being written), which is needed by the "yield to suspend/shutdown" function.
Missing the "wipe key from memory" means you don't have the marker, and trying to continue the suspend/shutdown will fail to compile, because you don't have the marker.
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 abstraction ("random arcane weird C shit" in the case of code versus "does this property hold" in the case of a regression test).
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.
Not sure why you're getting downvoted, this is the entire point of open source.
Does such a bug exist in Windows? OSX? Who checks? If someone finds the key in memory, can they tell what conditions might be causing it and where?
Their only recourse under those situations is to hand it off to the OS Vendor and trust that what they implement does solve the problem, and trust that it wasn't a deliberate back-door that is now being replaced by another back-door.
Oh, and large companies quite often fix these horrific issues silently, especially in online services where the customer can't diff bins. We're talking auth bypasses and RCE's that you'll never know about.
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.
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.)
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.)
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
Anyone with physical access, significant tools, and experience. The FBI has people who can pull data out of memory after freezing the RAM but the average laptop thief doesn’t so how serious this is depends significantly on your threat model. If you’re not a major criminal, bitcoin whale, or intelligence target this is almost certainly academic.
While that is true, the fact is that encryption is technically useless for anyone who is not constantly powering off and on, which is surely a bunch of people. That this is not widely understood is IMO a problem. And excellent reason for Debian's feature.
PS: Downvoting is not a rebuttal. Disk encryption is not effective security on a suspended (sleeping) system. That is a fact.
You’re being downvoted because you’re taking a narrow edge case and saying it invalidates all usage. Disk encryption is not “technically useless” when it works for 99.999+% of the people using it who aren’t targeted by professional attackers. Most people expect it to protect them against an unskilled thief or when they resell the device, and it works for that.
People in those high risk categories already need more than disk encryption anyway, so this isn’t even the critical piece for them! (Consider how likely it is that I would have the resources and access to freeze and extract your RAM but not, say, the ability to record you entering your password using the same access. Yes, you can come up with scenarios where that makes a difference but it really underscores that you have many additional things to worry about if this is your threat model.)
Yes I understand all that. I don't have secure boot, so I'm not protected against the evil-maid attack either. I know that too.
It's why I used the word "technically", by which I meant "in the absolute". What word do you propose instead? Encryption that can be worked around by anyone with skills and commonly available equipment is technically useless. It offers some protection (the thief will probably reboot or unplug) but ultimately it's null and void.
>Most people expect
This would need to be sourced. I say most people expect "encryption" to be as secure as the encryption password. In the case of an unattended sleeping computer using Linux with FDE enabled and the screen locked, it's not. I'm not sure most people know that. I believe things are different on, say, iOS. All of this was the rationale for Debian's (buggy) feature.
I would talk about threat models. There’s a bunch of detail to cover but the short of it is “you’re protected when you resell the device or replace a drive” or “you’re safe from a laptop thief in a coffeeshop but not the Mossad”. How you get there is the step in the conversation after you decide which of those concerns you.
> 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?
Several options. One is you restart and boot from a live system where you are root, and then dump all memory. This is described in the paper with the witty title "Lest We Remember: Cold Boot Attacks on Encryption Keys":
Other options: DMA attacks. Also you never know what the Intel Management Engine hidden in your computer is doing. It's running a version of Minix you don't have any control over, and it has full access to memory.
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.
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.
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.
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.
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.
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?
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.)
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-preven...
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.
Definitely not a symptom of Linux being a hodgepodge of code thrown together from a thousand different sources and no one person could tell you how it all fits.
Bugs happen in all code. The difference is, anyone can fix stuff in open source. Closed source bugs are out of control and must be worked around. Usually by switching to OSS
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.
Qubes OS, the Linux distribution aspiring to offer a reasonably secure operating system, pioneering a "every app runs in a virtual machine" approach in the Linux laptop/desktop space, tracks this at the following issue:
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".
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.
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.
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.
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.
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.
> Can I ask one question? Why not use hibernation at that point?
Not GP but hibernation is completely disabled for lockdown kernels[1], which is always enabled when booting under secure boot for kernels trusted by the Microsoft secure boot keys (it is considered a requirement to get you shim signed by rhboot[2] as it is believed that Microsoft considers it a hard requirement, as otherwise you could chain-load a patched version of Windows under secure boot).
This doesn't matter for custom kernels but most official distro kernels are built this way to be signed, as otherwise they won't Just Work (TM) on modern laptops. If you disable secure boot then hibernation works again, though I must admit I'm a little surprised how many people seem to disable secure boot.
[1]: https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.... [2]: https://github.com/rhboot/shim-review#how-does-your-signed-k...
> I must admit I'm a little surprised how many people seem to disable secure boot.
To me, secure boot is the setting that I need to remember to turn off before installing the OS, but I would be willing to be convinced otherwise
To be fair the security argument for secure boot is weakened by the fact that everything is signed by the same set of trusted keys when using the default Microsoft trust root, but on paper it does protect against certain kinds of attacks. (In theory, distros could use UEFI setup mode to only trust their own keys but this causes issues with signed firmware and there have been cases of bricked devices.)
Even if you use full disk encryption, without secure boot someone can replace your kernel (or bootloader to inject a bad kernel) with one that is backdoored without you noticing. So someone only needs temporary access to your powered off laptop to gain access to your data once you use it again. I've had my devices taken away from me at airports and I know people who have had their laptops mysteriously missing screws when travelling overseas, so this is not an entirely hypothetical problem.
Of course, the fact that hibernation doesn't work on Linux is a negative from a practical security perspective, and so stuff like luksSuspend on suspend end up being quite important. And trusting the Microsoft keys is a little concerning if you're worried about state actors.
If you use TPM-backed keys with tools like systemd-pcrlock you can get some similar (and arguably nicer) protections but in practice nobody locks to enough PCRs to provide more protection than you would get if you also enabled secure boot.
> Not GP but hibernation is completely disabled for lockdown kernels[1]
The manpage that you linked says that unencrypted hibernation/suspend is disabled, but this seems a bad idea anyway if you're using FDE.
The man page does say that but there is no mechanism to actually make use of that at the moment.
It's not enough for it to be encrypted, it needs to be encrypted with a single-purpose key that is not known by the user. Otherwise the user could replace the hibernation image with a malicious one and chain-load a backdoored version of Windows in secure boot mode, which violates the security model that Windows has and Linux needs to uphold to continue to get signed by Microsoft.
It is my understanding that there is work on generating a non-exportable single-purpose key using the TPM to make this work, but that's still a WIP.
> which violates the security model that Windows has and Linux needs to uphold to continue to get signed by Microsoft.
Oh ok, thanks for clarifying why this is a thing.
> Can I ask one question? Why not use hibernation at that point?
The sibling post by cyphar gives a good reason; while UEFI Secure Boot has its own share of issues, it can be a valuable ingredient in defending against evil maid attacks.
But another reason is... convenience. Resuming from RAM is faster than resuming from disk, especially so if your "disk" is actually just a USB flash drive. I know that it might be a bit weird to ask for convenience when the motivation is security. But I argue that there are use cases where the tradeoff is sound.
With hibernation, all your data is safe but the inconvenience might seduce you not to use it.
With suspend to RAM and your distro's version of cryptsetup-suspend (and the kernel patch or alternatively the cryptsetup workaround), only your volume key (and hence the bulk of your data, potentially terabytes worth of sensitive information) is safe, but sensitive data in memory (recent files, recent chat messages, session cookies, ...) is not. But on the other hand it's quick.
Some people use a combination: suspend to RAM for short breaks, where they expect to remain physically able to fully switch off the laptop when something happens; and suspend to disk for longer breaks.
It all depends on your threat model.
I'm confused why you're saying this is a Debian-specific thing -- luksSuspend is upstream and was added back in 2009[1] in release v1.1.0[2]. I've used it (though somewhat sparingly) on Arch and openSUSE in the past and it definitely exists on non-Debian distributions. Maybe you're thinking of the automatic integration with system suspend? If so, that's kind of besides the point -- luksSuspend documents itself as clearing the keys from system memory, which stopped happening in Linux 6.9 due to the referenced refactor patch.
Though it should be noted that it seems that this is actually a bug in cryptsetup in that it was depending on very specific lifetime behaviour of kernel keyring keys, when it arguably should've been more explicitly cleared by userspace[3].
[1]: https://gitlab.com/cryptsetup/cryptsetup/-/commit/3cea5dcc7b... [2]: https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/v1... [3]: https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/93...
I've used this feature on arch its available on bog standard luks but as far as I know it's not used by default when you suspend.
You are thinking of the machinery to actually actuate suspend to ram after a luks suspend in a way that is actually useful which was first a Debian targeted thing then arch and used by default by neither.
Hmm, the subcommand is in the official cryptsetup repository and the description matches? https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/man/cry...
what debian version first shipped 6.9?
Only the current stable (13/trixie); bookworm shipped with 6.1 as the main kernel (with 6.12 available in backports).
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.
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.
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?").
It was still more secure than the default if I understand this correctly. On resume from suspend the laptop would still be locked by the encryption key and without access to the disk even if you can somehow circumvent the lock. The only insecurity was that somewhere in the kernel memory the key still exists so if you can somehow extract that from the live system you can unlock it.
Yes, you are right: LUKS encryption protests your data at rest. An attacker which steals your disk can only gain little, like the information that you have used LUKS (unless you put your LUKS headers elsewhere, separated from the disk) and perhaps disk and disk sector usage statistics.
You need to get quite specific on actual attacks to call this insecure to be clear.
Having access to the raw RAM of a machine suspended but demanding the key to resume is certainly possible but the number of attacks where you don't need this bug is "almost all of them" given at that point if the machine ever unlocks you won in this hypothetical attack even with a bug fix.
I don’t know about “almost all”.
If the key has been purged but you can read RAM, then you can do two things:
1. You can extract whatever user data happens to be in RAM.
2. If you can either write RAM or reboot into your own OS, and then return the device to the unsuspecting user who will put in their password, then you can run a fake password dialog and get everything.
1 is bad, since there may be quite a lot of user data in RAM. But it’s not quite as bad as having the disk key, which gives the attacker all the data plus the future ability to decrypt or modify user data given only the physical disk. (Still, a better solution would be encrypting the hibernation image, preventing this attack entirely.)
2 is fully bad, but in many plausible scenarios (e.g. seized device) the attacker cannot just return the device to the user without them knowing something happened. Or even if they can, the method of RAM access may be one where reads are much more practical than writes, such as cold boot attacks involving physically swapping out the RAM.
The seized device scenario is starting to get very specific though: in the actual cases it's relevant like the Silk Road take down the device was intercepted while open.
It's of some frustration to me that more security devices don't have a "pull pin to destroy" function available in them for this reason if you have any type of threat model where this applies: e.g. when I thought about using a Yubikey to secure remote access, a core problem is you can't quickly wipe a Yubikey in your possession - and while they're fragile in daily use, they're also surprisingly hard to intentionally destroy quickly.
> "pull pin to destroy"
Insert old joke about folks rigging a packet of thermite with an igniter over their hard drive.
You need to only have the ability to execute code after the hibernation not before and the machine needs to be permanently unavailable to the user after.
As I said quite rare situations.
If you can read this kind of data you have the ability to run code which means you already owned the entire operating system making capturing the key next entry beyond trivial.
You don't need to spoof anything, we assume here you can read the key from RAM remember.
If you could execute code before hibernation you similarly already had the key.
I mean, isn't the threat model here that the attacker has stolen your device? That is about the only thing full disk encryption is good for.
It also prevents the addition of content onto the disk, providing tamper-protection in addition to secrecy.
For example, spyware/remote-control software would open new routes to penetrate your employer's systems, or steal money from your bank account, bypassing other security measures like an additional layer of encryption on your password mode, or 2FA.
Even a relatively unsophisticated foe could connect your hard drive, dump incriminating data on it to frame you, put it back, and then call the authorities with a tip.
You are generally guarding against the device being shutdown.
Anything assuming the OS is running is already into "well that is easy" territory since if the OS is running those keys are in the same place as this attack leverages.
I've been wondering why hibernate didn't work with encryption, because this seems like the extremely obvious way to handle it, but I have struggled to find anything about it for years - glad to hear it does exist!
But yeah, also rather obviously it's inherently a bit leak-prone. Though it seems probably pretty simple to test, just hibernate and scan all stored data. They could probably even do it on shutdown, as a hash of the key data would be sufficient to detect the key.
For me it works and I use it all the time. I hibernate with:
sudo systemctl hibernate -i
And when waking up it requests the LUKS passowrd. Using NixOS, worked since 2019 or so.
FYI: VeraCrypt is not the defacto encryption software for Windows.
Oh, which one is it?
(You don't mean BitLocker, right?)
It absolutely is and they have most the enterprise market.
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
The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed).
BitLocker with a password (the equivalent of the LUKS configuration in question) does not share these issues.
Bitlocker with a password has always felt like a second class citizen to me. You have to dig into a bunch of group policies to use it. Maybe most people don't even realize it exists.
Yah, it seems blatantly hostile how much they hide it.
I can understand the default being TPM-only + online key backup, huge amounts of the population forget their login passwords (which can be involuntary, e.g. head injury) and huge amounts of them still want some backup way to access their data rather than losing it forever.
But for anyone who cares just a little more, or would prefer to lose data in those situations, it's such an abnormal and hidden path that it's clearly blocking tons of people from choosing it.
For the system drive they seem to really strongly prefer PIN, which also doesn't have the problems linked above. I was going to use PIN as my example but didn't want to explain another set of recent BitLocker conspiracy theories yet again; maybe I should have.
It is annoying that they hate password for system drive _so_ much; the reason is actually pretty obvious when you think about how their "happy path" AD-driven enterprise deployment with stupid password rotation requirements works (and FileVault is a nightmare in this scenario), but I wish they'd make it easier for individual power users.
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
"Disk must be in expected hardware environment" versus "Same environment plus PIN" makes a huge difference if a thief simply steals a whole computer.
Just a PIN? For most people that's a 4-digit number, which has a worst-case scenario of 10,000 attempts and a median of only a few hundred. Why not use a full 8-digit password?
Because the TPM effectively rate limits brute forcing of the key.
https://learn.microsoft.com/en-us/windows/security/hardware-...
> For example, when BitLocker is used with a TPM + PIN configuration, the number of PIN guesses is limited over time. A TPM 2.0 in this example could be configured to allow only 32 PIN guesses immediately, and then only one more guess every two hours. This totals a maximum of about 4,415 guesses per year. If the PIN is four digits, all 9999 possible PIN combinations could be attempted in a little over two years.
In that case, the median would still be just over a month, if the PINs were entered in order of how commonly they are used. Even the worst case of two years is still soon enough for a lot of data still be useful.
Also, how is the time limit enforced? With hardware access, it would be easy to change time or increase the clock rate, as well as many other side-channel attacks that could eliminate the wait altogether.
The time limit is enforced by the TPM itself which defends against tampering.
I found some pictures of TPM modules with crystal oscillators, so those could keep time while powered on, but wouldn't be able to keep time while off. It would be possible to only count time while on, but that would be really annoying to a legitimate user that kept turning off the computer, waiting for the time limit to expire, especially if it doesn't tell the user how much time is left.
Anyway, crystal oscillators connect to one input pin and one output pin, with an internal feedback circuit that causes the crystal to resonate. It's possible to change out the crystal for a higher frequency, or even directly drive the input pin for a much higher frequency. Semiconductor manufacturers often only characterize the limit of the feedback circuit, but not the limit of the internal clock circuitry when directly driven. Considering that the logic design supports an SPI bus running up to tens of megahertz, it's totally possible that the crystal input could be driven at a similar speed, possible a thousand times faster than a normal real-time clock oscillator.
There would be several ways to mitigate such an attack, but a quick search for TPM side-channel attacks brings up multiple much simpler vulnerabilities, so it's not likely that TPM manufacturers are putting any real effort into mitigation.
The TPM can have a lockout counter that it decrements over time.
>It's possible to change out the crystal for a higher frequency
You can't access the internals of a TPM by design.
Most enterprises require a 12 digit code, to meet a specific security standard. Bruteforcing that, with hardware access restricted by TPM, would take a very, very long time.
You're also not restricted to 4 digits. A full passphrase is an option.
Which I wish was more heavily advertised because a passphrase is a lot easier to remember.
> the TPM effectively rate limits
I had a friend working at trusted compute at Microsoft, and he had so many stories.
These TPM firmwares are often written by shitty companies that have no fxcking clue what they are doing.
Most TPM implementations are a clown show, companies just want to check a box on paper so they say "look! We have a TPM!" and move on.
A quick search for "TPM side-channel attack" substantiates that claim.
Looking at the manufacturers of TPM ICs, it makes sense. Most of them make microcontrollers that have code-protect bits in them that are notorious for being susceptible to simple side channel attacks, but also for not being a target simply because no one cares about the object code on any random product's microcontroller.
I worked at a company that sold a microcontroller that executed from external memory, so there was no possible way to have built-in code protect bits, and some potential customers complained until we included a library to encrypt the external memory, run a small unencrypted bootloader which included the a plain-text decryption key, then run the encrypted program. That checked their box, despite doing nothing useful.
No one uses a 4-digit pin for BitLocker. No one who knows what they are doing, anyway.
My employer requires at least an 18-digit PIN, and not just numbers, either.
If you're really serious, you use a strong password, not a PIN.
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
And then depending on how "serious" you are you also don't consider Linux.
But also, threat models and the best way to mitigate them aren't really a linear scale of being <unserious> to <serious>, but a complex consideration of a particular situation.
People just plain suck at opsec. Like Che Guevara might have had a longer career as a revolutionary if he'd used his one time pads only once.
Back in the late 1980s it was clear that it would be no problem at all to hook up a hard drive to a digital phone exchange and record all the calls! I had a strict policy of "don't talk about anything illegal using electronic communication" even when it was rather banal stuff like selling weed.
The carelessness of people at Facebook documenting policies that nobody in their right mind would document boggles my mind: you might as well leave it mysterious why you didn't crack down on scam ads, for instance. When I've been involved in minor conspiracies, say when we had an HR problem with another employee, I've always made the point to meet furtively in person and avoid leaving a paper trail so that I'd never need to explain an email I wrote in front of an unfriendly audience.
If you think for one single second that businesses and governments who rely on a lost disk being secure don’t trust bitlocker, I have oceanfront property in Missouri to sell you.
Bitlocker + PIN is as secure as anything.
A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.
> A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.
First off: I agree with your thesis, BitLocker with PIN is Just Fine, equivalent in all practical senses to most disk encryption strategies, and an enterprise standard.
I post this to reinforce what you're saying, because there are a ton of weird theories about how this works that make people think it's weaker than it is.
BitLocker with PIN works like this:
* BitLocker seals an encrypted key IK into the TPM using a policy on the TPM which requires the SHA-256 of the PIN to be sent to the TPM to unlock the record (and has anti-hammering at the TPM level).
* Encryption using another key called the SK. Once the OS acquires the e(IK) from the TPM, it needs to derive SK to decrypt the IK. The SK is generated by applying a salt and 0x100000 rounds SHA256 to the PIN.
* The IK can then decrypt the VMK, which can decrypt the FVEK which is the actual data encryption key used on the on-disk data.
Fully offline (no TPM access) decryption is hopeless; the IK is random and not attached to the PIN at all.
Fully online decryption relies on TPM anti-hammering; if you can manage to hammer the TPM and find a PIN where h(PIN) matches, you can then use the PIN to generate both h(PIN) (unseal TPM) and reverse e(IK).
Partially offline decryption (imagining TPM content is somehow dumped, for example by bus sniff while a user uses their PIN) relies on bruteforcing the key for e(IK), which is possible but difficult (IMO Microsoft should ratchet this up or use a more expensive algorithm than SHA-256 in order to deal with modern hardware capabilities, but they have issues like FIPS to deal with that make new algorithm selection difficult).
https://www.techspot.com/news/112410-security-researcher-mic...
BitLocker with pin is not vulnerable to that (or any other) attack.
10 points deducted. Try again.
> or any other
last famous words? :D
I appreciate your desire to shit on Microsoft for everything they’ve ever done, but they got BitLocker with PIN right.
Explain how an exploit can decrypt the drive without the portion of the key that the user must enter. The computer doesn’t know the entire key, and can’t decrypt the drive without it, or the recovery key. This is why BitLocker with PIN hasn’t been defeated yet. I don’t understand how it could ever be defeated without entering the PIN.
veracrypt lost their drivers license so afaik you should avoid it since it cannot update its drivers any longer. didnt see any news about them reacquiring that license
Assuming this is what you are referring to, it was resolved within a few days. The incident being resolved just didn't make headlines. https://sourceforge.net/p/veracrypt/discussion/general/threa...
aah cool, thank you..100% missed the update :). thanks! thats good to read honestly lol. not that i use windows much but i felt it was MS trying to undermine it. happy it got restored and there remains an alternative to butlocker.
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...
Tangentially: Microsoft telemetry collects the serial# of your devices and reports it (with your IP and MS account) back to the mothership, and some printers embed their serial# in printed pages.
So take countermeasures if you print something out criticizing any groups that abuse political or law-enforcement powers.
Only if you store your key with Microsoft, which is not required or the default if you're using a local account which I assume most privacy sensitive people are.
> if you're using a local account
Unfortunately Microsoft keeps working to destroy that option and force consumers to make a remote account. [0][1] Their consistent moves towards wanting to co-own my computer were one of the many last-straws that made me migrate everything to Linux this year.
> Local-only commands removal: We are removing known mechanisms for creating a local account in the Windows Setup experience (OOBE). While these mechanisms were often used to bypass Microsoft account setup, they also inadvertently skip critical setup screens, potentially causing users to exit OOBE with a device that is not fully configured for use. Users will need to complete OOBE with internet and a Microsoft account, to ensure device is setup correctly.
[0] https://blogs.windows.com/windows-insider/2025/10/06/announc...
[1] https://www.windowslatest.com/2025/10/07/microsoft-confirms-...
Not to mention that unless the bitlocker activation flow changed recently, it specifically asks you how to store your backup keys, with a choice given been local options (eg. usb drive, printing it off, etc.) and saving it to your microsoft account.
dell opts you in without telling you. one day you'll just reboot to an unexpected bitlocker screen and have to figure out whether you're getting ransomwared before eventually digging a key out of your microsoft account you weren't aware was there.
Like it's easy to create local accounts on windows 11… the default are microsoft accounts and microsoft having access to your key.
Also this: https://www.techspot.com/news/112410-security-researcher-mic...
Agreed it's optional (I've seen and used that option), but are local accounts even a thing any more? Or are you just referring to "not MDM controlled" accounts?
Rufus for install + Win11Debloat post-install is a nearly effortless way to get an ad-free, local only Win 11 install that persists through updates which removes pretty much all notorious Win 11 pain points (plus additional customization if desired).
I've been doing it for years and so reading Windows 11 complaints on HN always feels like they're coming from a strange parallel universe since I never have to deal with any of it.
"modify the windows installer via a binary patch to work around the continued bloat and feature crippling" really isn't "local accounts are supported" in my book. that's like saying "the 1965 ford mustang was an electric car" because someone did a conversion on it a few years ago.
and the actually supported workarounds have disappeared, last I saw - bypassnro and disabling internet both failed completely for me, the last time I tried. maybe they have come back (it has intermittently failed in the past and come back), but they're very clearly doing more to remove it than they did a year+ ago when bypassnro worked easily and consistently.
Bitlocker can use keys that are local only, but the default for home editions of Windows was to use the online account to back it up.
'Happily' is also a stretch, as they really don't have a choice if served a valid court order.
If you want encryption that is safe from the US government, keys need to be stored in your head. Anything physical is subject to court orders.
Does that mean it's not the de facto standard on Windows?
So exactly like FileVault?
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.
>if by "great" you really mean "fine".
no, i mean great.
managing a fleet of 100+ laptops with bitlocker is a breeze. its so seemless that the users don't even realize its enabled (i.e. no UX issues, at all).
on the other hand, i am not managing 100+ laptops that use veracrypt. sounds absolutely awful. i've never managed an apple fleet, so i can't speak to that, and will take your word on it.
for personal use, i do not recommend bitlocker (or windows, really), but for already-windows enterprises? absolutely
Flicking a button to turn something on is not what I'm talking about, that's normally the easy part of any setup, and I judge people harshly who only take that aspect of something into consideration when discussing systems.
Brittle is what happens when you haven't logged on to the machine in 60 days, trust with AD is broken, TPM has a glitch and wipes the in device key and forces you into recovery... or god forbid you service the laptop and now you have to enter recovery mode.
Then you're in a nightmare, trying to give someone a super long passphrase over the phone is a not-too-uncommon occurance.
That's assuming you have a good policy for storing the recovery keys. Too loose and they're handed out to everyone, sort of defeating the purpose: too strict and you need the IT department (or specific members), and its still predicated on the notion that you have a policy for it... Given that Admins are a dying breed... I don't think this is workable.
If you compare with Filevault on MacOS: which tracks the credentials of the logged in user; there's no "issue" if the device loses trust because ultimately you always use the real unlock key: not something cached in a "secure storage".
Having dealt with FileVault in this context, it's also frustrating; it's really common to have it fail to follow the logged-in user's credentials, and if you use any kind of federated login, you will frequently get users with FileVault passwords that are either ahead of or behind their system login password.
I think both approaches are valid trade-offs and I think that the default Secure Boot BitLocker configuration, for all its architectural tradeoffs, can probably be credited for an enormous amount of data loss mitigation originating from used hard drives alone.
maybe i am missing something, but how did veracrypt solve all of the admin and policy issues you’re bringing up? (specifically for large enterprise fleets)
If you use your key every day you tend not to forget it.
If I as an admin give you your key: it is “leaked” effectively.
>If you use your key every day you tend not to forget it.
hoping users don’t forget their password is a very weak policy.
specifically, the policy and admin points you brought up above, how does veracrypt solve them?
We're sort of talking about two things and conflating them.
I'm sort of talking about my user experience of the system, and I'm getting it in the neck from helpdesk.
Enterprise rollouts are different from anything I actually deliver, despite pushing out thousands of windows servers: I have complete control over those.
Same as my local PC.
But as a user on a PC I'd buy from a store, I'm not going to forget my password without expecting to lose access to my system.
>We're sort of talking about two things and conflating them. [...] But as a user on a PC I'd buy from a store
i said multiple times that i was talking about a managed fleet in an enterprise environment, and even specifically said that i dont typically recommend bitlocker for personal use, so i am not really sure what to say here. i was really clear.
Yes, but I still think we've been talking passed each other.
I doubled down on "it's fine but not excellent" when I should have pulled away and explained that the main issues I have are about bitlocker as a user.
You don't have remote back ups enabled?
veracrypt does not include a remote backup system
Of the work, not of the encryption.
we're talking about veracrypt vs. bitlocker in a managed enterprise environment.
whether there are backups or whatever else is irrelevant because it would be true in both the veracrypt and the bitlocker scenario.
We are talking about IT policies. I don't know what YOU think we're talking about.
Our helpdesk deals with 2-300 users per day that logon every single day yet forgot their password.
This type of thinking doesn't work in large enough orgs dealing with end users.
Have you never gone on vacation and forgotten your daily-use password upon return?
Nop.
Managing an Apple fleet is similarly fine, and that includes using any of the MDM tooling that also does key escrow on enterprise Filevault devices.
FileVault absolutely has an optional iCloud Keychain escrow. That’s how the “unlock with Apple Account” feature works. Apple doesn’t have the keys for iCloud Keychain, but it is still stored in iCloud.
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.
Veracrypt is more difficult to set up - whether on one machine or a fleet. Bitlocker is a few buttons in the UI, configurable via Group Policy, and so much more.
What is brittle or awkward?
"PLEASE ENTER YOUR BITLOCKER RECOVERY KEY"
Where is it?
A) Uploaded to microsoft
B) Somewhere in EntraID?
C) Somewhere in our onprem AD?
D) Written down on a scrap of paper when I set up the laptop
the fact that they never ask for the passphrase is a weakness of the system. Because now you have an extremely difficult situation as soon as you're off the happy path.
It's also like 64 characters alphanumeric with no capability to copy/paste.
Compare it to Vera/Filevault where the access key is the users passphrase. In MacOS it's literally your account password, which follows along with your in-OS account credentials.
Or nowhere you know at all if you're a non-technical user who was on a local account Win 11 setup who was tricked by microsoft dark pattern pop-ups getting you to go to "online accounts" which automatically and silently encrypts your drives in the background and then tells you to go to to some shady domain called aka.ms (with another computer, since yours is now locked on a bluescreen and unusable). Basically a typical ransomware message. In truth in this case it's #1 (uploaded to Microsoft) but the non-technical user doesn't know that. Even I thought aka.ms screen was ransomware when my parent called me saying their computer had a "virus".
That happens with Veracrypt as well. I have plenty of friends and family who can't remember their WiFi password without remembering where it was written down, and they use that far more often than an encryption recovery code.
In fleets users wouldn't even be setting up their own code.
I've installed Windows thousands of times on dozens, probably hundreds of systems - long ago I even worked on the Windows team and was installing it every day - and in the last 20 years (yes, I ran Vista Ultimate in 2006) I've had to deal with Bitlocker recovery prompts perhaps 20 times - not 20 times per machine, 20 times across all of them.
> Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else)
Did you read the documentation?
https://support.apple.com/guide/mac-help/protect-data-on-you...
"iCloud account: Click “Allow my iCloud account to unlock my disk” if you already use iCloud. Click “Set up my iCloud account to reset my password” if you don’t already use iCloud."
https://developer.apple.com/documentation/devicemanagement/f...
"FileVault Full Disk Encryption (FDE) recovery keys are, by default, sent to Apple if the user requests them. Only one payload of this type is allowed per system."
Can.
If you click "Allow my iCloud account to unlock my disk", your recovery key is escrowed to Apple, tied to your Apple Account.
If you don't select that option it never does.
I should have said "without your explicit permission", but I assumed we were all adults and understood that.
The main point is that it's using your account password to unlock, the recovery key is for if you forget your account password.
No, you were just plain wrong. You said “never”, when in reality BitLocker and FileVault both have optional escrow.
[dead]
makes me wonder if there is potential for a more "main stream"/by default friendly version of this, where the key during suspend is encrypted using the TPM even if the TPM isn't a possible unlock from cold boot (i.e. no TMP encrypted volume key in the LECS headers/meta only temporary in memory during suspend)
or the alternative (for more convenient usage) for single user systems auto login on boot + use disc password for doas/sudo?
[dead]
The luks feature is not Debian specific
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)
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...
AMD backtracked on that strategy: https://www.techpowerup.com/350142/amd-to-restore-tsme-memor...
Future AGESA updates will still include memory encryption for all processor models. It's one of the rare instances of consumer backlash creating a clear and immediate response.
[dead]
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.
Because debian users with luks-suspend have to re-enter their boot password after sleep.
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.
Ah, my bad. Yes, if the user was being presented with the prompt on wake, I see the problem.
I have never had that setup so I was confused.
> 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.
Well, potentially a key might be stored in TPM. But I don't think that's better
I would hope that it is harder to get into the TPM than into the RAM.
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.
You can just wipe the luks header as a nice middle ground.
Luks uses an anti-forensics algorithm that requires the entire volume key being available to unlock the disk at all (it combines the blocks of the key with some diffuse algorithm and xors stuff together to form the actual master key), so in theory you can just clear one sector of the volume key and the whole thing should be unrecoverable.
What I mean is that if even one block of the key is missing you can't guess the rest easily.
Assuming the encryption key is strong, the wiping is theoretically redundant.
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.
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.
Agreed. It's also very low effort and as such I'm ok with the redundancy.
Indeed. Truth be told, I do it too.
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"?
While I can see the shortcomings of C and generally don't recommend it for new projects I don't see this particular bug as a good example of something Rust's borrow checker or some other language's type system will catch. I don't think even static analyzers can catch this.
It's basically something like this:
original: DoTheThing()
new: DoTheThingSlightlyDifferentButKeepMyCredentialsAlive()
fix: DoTheThingSlightlyDifferentButDoInFactNOTKeepMyCredentialsAlive()
In my experience a substantial portion of gnarly bugs come down to a violation of a high-level system invariant and those do not strike me as something that can be automated. Even with something like Lean you can prove your program satisfies certain properties but you need to have thought about those properties in the first place. The proof doesn't discover the invariant for you.
If you'd had thought about the relevant security property you could have written a regression test for it which is not hard. IMO the really hard part isn't expressing the implementation safely, but it's the realization that this was a property the implementation needed to preserve.
I agree re Rust vs C - this is not (only) a language issue. What would (roughly) the invariant be here?
In another thread comment below i argue that maybe the system (OS) itself is so complex that it lacks clear contract / the contract evolves too quickly over time (as other parts of the code need to change the given piece of code to extend it to their use case) and that defies clear encoding?
Or we lack easy enough means to describe specs? I tried reading jepsen spec earlier today and despite it being an "integration test" of sorts, it is far from "simple".
Can an entire OS or a system of comparable complexity be decomposed into objects simple enough that their entire intended behavior (with all edge cases) can be explained in a paragraph of human text + half a screen of dense behavioral "spec" - if i do X and do Y, Z should come out / hold _no matter what happens in-between_. Or that's what asserts + fuzzing is effectively supposed to do? Is there a clear distinction between invalid input and failed invariant in typical C code? I guess error code vs seg fault?
This is in effect a state machine, and when you have a type system more complex than C's you can encode state transitions in the type system (either by having state transitions explicitly return a new return type or by using sum types). You still need to architect the system to encode the invariants in types. No language will fix all logic bugs for free. But you can leverage language features to reduce their number.
> You still need to architect the system to encode the invariants in types.
That's the problem though, right? If it's pointed out we all agree the "do not keep credentials alive" is a property that should hold and we can leverage whatever the environment offers to help preserve it. I fully agree modern languages have amazing support for this, but in C you can still run tests. Let's just say I don't think the language's inability to express logic of this kind held all those involved back from testing for it. I personally find "we just didn't think of it" much more likely.
That said, I am not a fan of C and recommend leveraging whatever fantastic modern tooling is available to you.
Like set an generic marker struct IsEncrypted<T> where T is yes or now and only allow its state to change when proven and then write the shutdown function to only take the yes variant?
Yes, that would be one way of doing it. You can model off of the Typed Builder pattern:
This won't work for everything, but it is a pattern that I find useful to ensure that things can't happen out of order.The premise of a secure open codebase is fine.
The problem is being more auditable does not automatically make it more audited.
There have to be enough people with skill taking enough time to work on it.
If you think open source is bad, wait till you see enterprise code. I'm talking full auth bypass due to the stupidest crap. You can do that in any language if you have fools working on the code base.
I explicitly make sure services I lead have Integration tests in CI pipeline to validate the "negative paths" against all APIs with missing, invalid, un-authorised identities, expired, un-authenticated tokens. Of course that still doesn't cover every surface, but even that gets sideways glances from some folks who think we should just test happy paths and why we're testing for access controls in Integration tests.
Even security code. Fortinet, a vendor whose entire thing is security for your network, is consistently getting caught out with default passwords, backdoors, etc.
https://community.spiceworks.com/t/hard-coded-password-backd...
This sort of thing leads to every kind of exploit, like
https://www.linkedin.com/pulse/half-worlds-fortinet-firewall...
"It is better to keep your mouth closed and let people think you are a fool than to open it and remove all doubt" is a reason why people don't open-source more often.
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.
I think https://news.ycombinator.com/item?id=48766436 is a practical answer. A marker that can't be forged (without explicitly malicious code being written), which is needed by the "yield to suspend/shutdown" function.
Missing the "wipe key from memory" means you don't have the marker, and trying to continue the suspend/shutdown will fail to compile, because you don't have the marker.
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 abstraction ("random arcane weird C shit" in the case of code versus "does this property hold" in the case of a regression test).
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.
In open source, someone (many, many) someone’s can at least check.
Closed source…..
Not sure why you're getting downvoted, this is the entire point of open source.
Does such a bug exist in Windows? OSX? Who checks? If someone finds the key in memory, can they tell what conditions might be causing it and where?
Their only recourse under those situations is to hand it off to the OS Vendor and trust that what they implement does solve the problem, and trust that it wasn't a deliberate back-door that is now being replaced by another back-door.
Security researchers find security bugs in closed source operating systems all of the time.
Yup, it’s just harder to know for sure.
Oh, and large companies quite often fix these horrific issues silently, especially in online services where the customer can't diff bins. We're talking auth bypasses and RCE's that you'll never know about.
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.
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.)
"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.)
Of course, I'm not saying closed source is better. I'm saying that just because it's open it doesn't mean people really care to read it thoroughly.
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?
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.
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.
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.
> 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...
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.
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.
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.
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.
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.
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.
This is correct, the memory encryption stuff is to prevent side channel attacks, not secure data.
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.
> 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.
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.
Anyone with physical access, significant tools, and experience. The FBI has people who can pull data out of memory after freezing the RAM but the average laptop thief doesn’t so how serious this is depends significantly on your threat model. If you’re not a major criminal, bitcoin whale, or intelligence target this is almost certainly academic.
> If you’re not a major criminal, bitcoin whale, or intelligence target this is almost certainly academic.
Thanks, that's what I thought.
While that is true, the fact is that encryption is technically useless for anyone who is not constantly powering off and on, which is surely a bunch of people. That this is not widely understood is IMO a problem. And excellent reason for Debian's feature.
PS: Downvoting is not a rebuttal. Disk encryption is not effective security on a suspended (sleeping) system. That is a fact.
You’re being downvoted because you’re taking a narrow edge case and saying it invalidates all usage. Disk encryption is not “technically useless” when it works for 99.999+% of the people using it who aren’t targeted by professional attackers. Most people expect it to protect them against an unskilled thief or when they resell the device, and it works for that.
People in those high risk categories already need more than disk encryption anyway, so this isn’t even the critical piece for them! (Consider how likely it is that I would have the resources and access to freeze and extract your RAM but not, say, the ability to record you entering your password using the same access. Yes, you can come up with scenarios where that makes a difference but it really underscores that you have many additional things to worry about if this is your threat model.)
Yes I understand all that. I don't have secure boot, so I'm not protected against the evil-maid attack either. I know that too.
It's why I used the word "technically", by which I meant "in the absolute". What word do you propose instead? Encryption that can be worked around by anyone with skills and commonly available equipment is technically useless. It offers some protection (the thief will probably reboot or unplug) but ultimately it's null and void.
>Most people expect
This would need to be sourced. I say most people expect "encryption" to be as secure as the encryption password. In the case of an unattended sleeping computer using Linux with FDE enabled and the screen locked, it's not. I'm not sure most people know that. I believe things are different on, say, iOS. All of this was the rationale for Debian's (buggy) feature.
I would talk about threat models. There’s a bunch of detail to cover but the short of it is “you’re protected when you resell the device or replace a drive” or “you’re safe from a laptop thief in a coffeeshop but not the Mossad”. How you get there is the step in the conversation after you decide which of those concerns you.
> 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?
Several options. One is you restart and boot from a live system where you are root, and then dump all memory. This is described in the paper with the witty title "Lest We Remember: Cold Boot Attacks on Encryption Keys":
https://www.usenix.org/legacy/event/sec08/tech/full_papers/h...
Other options: DMA attacks. Also you never know what the Intel Management Engine hidden in your computer is doing. It's running a version of Minix you don't have any control over, and it has full access to memory.
>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
Still, this is a pretty crazy definition of "anyone".
you dump the physical memory, then decrypt the disk offline
LUKS still keeps unencrypted header on the harddrive; real men use plain dm-crypt instead! Plausible deniability compatible.
Ah yes, it is very plausible you just keep a partition of hundreds of gb of perfectly random data for no reason at all.
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.
https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-...
Proper capitalization makes English easier to read.
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?
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.
Well yes and I don't see how this can be avoided.
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.
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.
https://xkcd.com/538/
(No, no, I take this stuff seriously too, but it had to be said)
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.
Why is something this important not tested with every build?
[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
AI reply, triggered my spidey senses
Yup look at the rest of their comments
We should just automatically ban every new account with "AI" in the about field. I don't think we'd lose much.
[dead]
[flagged]
[dead]
[flagged]
[flagged]
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 :-).
Suggesting I'm an exotic animal for being budget and environmentally friendly is being a jerk too.
> 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."
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?
Except shutting down and hibernate are two actions the user can literally select from the same menu.
I shutdown mine too but only because suspend is still a crapshoot on linux
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.)
I am too lazy for that, and I hate that after boot you need to launch everything again.
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-preven...
You can usually change that in the settings of the Desktop environment.
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.
Definitely not a symptom of Linux being a hodgepodge of code thrown together from a thousand different sources and no one person could tell you how it all fits.
Bugs happen in all code. The difference is, anyone can fix stuff in open source. Closed source bugs are out of control and must be worked around. Usually by switching to OSS
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.
It's still better general OS than any alternative. :)
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.
Qubes OS, the Linux distribution aspiring to offer a reasonably secure operating system, pioneering a "every app runs in a virtual machine" approach in the Linux laptop/desktop space, tracks this at the following issue:
https://github.com/QubesOS/qubes-issues/issues/2890
QubesOS is Xen based. Not Linux.
It's kinda both, right? In any case, good clarification, thank you.
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".
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.
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.
"Mythos, find me a bug in LUKS. I know there is one in there".