Update on Linux hibernation support when lockdown is enabled(mjg59.dreamwidth.org)
mjg59.dreamwidth.org
Update on Linux hibernation support when lockdown is enabled
https://mjg59.dreamwidth.org/58077.html
36 comments
I'm still waiting for someone to explain any legitimate use of kernel lockdown. To me, it just seems like a tool that makes it easier for bad guys to do tivoization.
You have a disk encrypted laptop. That key is protected by a password.
Secure boot means that when you log in you can trust that the disk decryption screen is not a disk encryption key exfiltration screen waiting for you to enter your password so that a disk backup taken earlier can be decrypted.
How?
The disk encryption is based on a key in the TPM which only is decrypted with your password. That TPM gets wiped when you disable secure boot. The result is that when you enter your password either you get a correct decryption key or your disk encryption key has already been wiped. Assuming it's not possible to run untrusted code before the disk encryption key login screen with secure boot enabled.
kernel lockdown is part of the parcel for making sure that untrusted code does not run that can exfiltrate the disk decryption key.
Secure boot means that when you log in you can trust that the disk decryption screen is not a disk encryption key exfiltration screen waiting for you to enter your password so that a disk backup taken earlier can be decrypted.
How?
The disk encryption is based on a key in the TPM which only is decrypted with your password. That TPM gets wiped when you disable secure boot. The result is that when you enter your password either you get a correct decryption key or your disk encryption key has already been wiped. Assuming it's not possible to run untrusted code before the disk encryption key login screen with secure boot enabled.
kernel lockdown is part of the parcel for making sure that untrusted code does not run that can exfiltrate the disk decryption key.
That doesn't actually protect against that attack, though. The evil maid just steals the guts of your computer and replaces them with ones that always say "sorry, wrong password", while exfiltrating the password you tried over Wi-Fi or Bluetooth. Then they use your password to decrypt your unmodified hard drive with your unmodified TPM on your unmodified motherboard.
Also, I don't think this is true:
> That TPM gets wiped when you disable secure boot.
Won't the TPM not be able to decrypt anything while Secure Boot is disabled, since the PCRs will be different, but then it will work again if you later re-enable it? I don't think it actually wipes itself. And even if it did, couldn't you just unplug the TPM, disable Secure Boot, steal the password, re-enable it, and then plug the TPM back in? Then even if it did want to wipe itself, it wouldn't know to.
Also, I don't think this is true:
> That TPM gets wiped when you disable secure boot.
Won't the TPM not be able to decrypt anything while Secure Boot is disabled, since the PCRs will be different, but then it will work again if you later re-enable it? I don't think it actually wipes itself. And even if it did, couldn't you just unplug the TPM, disable Secure Boot, steal the password, re-enable it, and then plug the TPM back in? Then even if it did want to wipe itself, it wouldn't know to.
There's one flaw in your scenario: if your computer suddenly stopped respecting valid credentials, it'd be extremely obvious that the motherboard had been replaced or tampered with.
Generally speaking most evil-maid attacks assume that the attacker wants to remain covert, otherwise the victim will start revoking stolen credentials, calling the authorities, etc. If you don't care about remaining covert then you don't need to do an evil-maid attack; just buy a wrench.
Generally speaking most evil-maid attacks assume that the attacker wants to remain covert, otherwise the victim will start revoking stolen credentials, calling the authorities, etc. If you don't care about remaining covert then you don't need to do an evil-maid attack; just buy a wrench.
The evil maid could use the credentials within seconds of you typing them in, so you wouldn't have time to revoke anything. With rubber-hose attacks, you might give the attacker a duress code rather than the real password, which wouldn't happen with this one. And let's face it: it's probably nation-states that would do this kind of attack, so calling the authorities wouldn't be helpful anyway.
In a high security situation. It would not be a password, but a smartcard which authenticates the device before providing its key, and the device authenticating the smartcard.
Edit: For the purposes of the Networked Evil Maid Attacks. Mutual Authentication (of device and user) is currently the purpose of research. It has not needed to be implemented yet as the regular Evil Maid is still possible due to the fact that Secure Boot is currently the easier target to circumvent. Once Secure Boot becomes harder to circumvent and old "assumed" buggy kernels are revoked from running. Networked Evil Maid counter measures will need to be implemented as standard
Edit: For the purposes of the Networked Evil Maid Attacks. Mutual Authentication (of device and user) is currently the purpose of research. It has not needed to be implemented yet as the regular Evil Maid is still possible due to the fact that Secure Boot is currently the easier target to circumvent. Once Secure Boot becomes harder to circumvent and old "assumed" buggy kernels are revoked from running. Networked Evil Maid counter measures will need to be implemented as standard
And you can still proxy that smart card over WiFi/LTE and boot the stolen internals at least once :)
Does anything actually support this, or is it purely hypothetical? And even if that did exist, wouldn't that mean that password stealing wouldn't be an issue even without Secure Boot?
There are machines that keep track of chassis intrusion and measure it into a PCR, making the hardware replacement part of the attack less feasible; I’ll grant that your “evil maid” could also pass off a completely separate device as being yours, though.
FYI: The tone of your original question suggests that you might have prepared responses to any answers you might receive about secure boot and kernel lockdown. If that’s the case, maybe a comment tree isn’t the correct forum for having a discussion about it because of the inherent information inequity.
FYI: The tone of your original question suggests that you might have prepared responses to any answers you might receive about secure boot and kernel lockdown. If that’s the case, maybe a comment tree isn’t the correct forum for having a discussion about it because of the inherent information inequity.
The historic goal of the free software movement has been to make sure that users have freedom over their computing environment. Implicit in that is the idea that other people do not have freedom to mess with your computing environment, that the computer runs exactly what you tell it to run, no more and no less.
To that end, the goal is in fact similar from a technical perspective to TiVoization! The only difference is that TiVoization is where the manufacturer of a device controls the device after it's been sold to a new owner, and lockdown is where the owner controls their own device. For the most part, this is a social constraint, not a technical one.
It shouldn't be surprising that the technical tools are similar between the two opposed social goals of user freedom and corporate control. The entire idea of free software licensing depends on the idea that software is copyrightable and its copyrights can be enforced in court. The free software movement demands access to source code to enable user freedom, but companies also demand access to source code for business continuity reasons using source code escrow services (if not for ongoing access - Microsoft licenses Windows source code to major customers, for instance). The GNU Project demands their contributors sign papers assigning copyright so that GNU is in a better legal position to enforce licenses, but so do proprietary software development shops, for exactly the same reason. They just are achieving different things.
But there is an important way in which this has technical implications: the owner of the device needs to be able to change. TiVo does not need to change who is the admin. That is why the lockdown work is harder. Remember that TiVoization actually happened without any of this work, and in fact happened so long ago that barely anyone remembers what a "TiVo" is.
To that end, the goal is in fact similar from a technical perspective to TiVoization! The only difference is that TiVoization is where the manufacturer of a device controls the device after it's been sold to a new owner, and lockdown is where the owner controls their own device. For the most part, this is a social constraint, not a technical one.
It shouldn't be surprising that the technical tools are similar between the two opposed social goals of user freedom and corporate control. The entire idea of free software licensing depends on the idea that software is copyrightable and its copyrights can be enforced in court. The free software movement demands access to source code to enable user freedom, but companies also demand access to source code for business continuity reasons using source code escrow services (if not for ongoing access - Microsoft licenses Windows source code to major customers, for instance). The GNU Project demands their contributors sign papers assigning copyright so that GNU is in a better legal position to enforce licenses, but so do proprietary software development shops, for exactly the same reason. They just are achieving different things.
But there is an important way in which this has technical implications: the owner of the device needs to be able to change. TiVo does not need to change who is the admin. That is why the lockdown work is harder. Remember that TiVoization actually happened without any of this work, and in fact happened so long ago that barely anyone remembers what a "TiVo" is.
The amount of setup required to make a laptop go into hibernation and boot to the same state every time is pretty substantial:
https://austingwalters.com/increasing-battery-life-on-an-arc...
This would make things a tad easier, but at the end of the day. Still think it’s gonna be a hard setup, plus it’ll slow boot up by wiping memory (should save power if I understand that correctly).
https://austingwalters.com/increasing-battery-life-on-an-arc...
This would make things a tad easier, but at the end of the day. Still think it’s gonna be a hard setup, plus it’ll slow boot up by wiping memory (should save power if I understand that correctly).
The amount of setup required to make a laptop go into hibernation and boot to the same state every time is pretty substantial:
https://austingwalters.com/increasing-battery-life-on-an-arc...
This would make things a tad easier
https://austingwalters.com/increasing-battery-life-on-an-arc...
This would make things a tad easier
And this article doesn't even tackle encrypted-dm and swap on btrfs which is even less straightforward :
https://wiki.archlinux.org/title/Power_management/Suspend_an...
I have it working and it's wonderful tho...
https://wiki.archlinux.org/title/Power_management/Suspend_an...
I have it working and it's wonderful tho...
This would make a huge difference in battery life for Linux laptops with secure boot enabled. Lots of modern laptops don’t even properly support S3 sleep properly (looking at you dell) and want to be able to hibernate to save power.
> Lots of modern laptops don’t even properly support S3 sleep properly (looking at you dell) and want to be able to hibernate to save power.
"modern standby" is such a scam and shit show.
And completely opposite that, I was a bit shocked how aggressive modern macos (at least on M1 machines) are at hibernating, I have had to get used to `caffeinate` long-running process because on battery if that's not in use as soon as the screen turns off the machine stops doing anything, even with "low power mode" disabled.
I expect there's a pmset somewhere to change that (as there is an option in the UI when on power adapter), but with the battery life of the new devices I've kinda stopped plugging it in (even at my desk).
"modern standby" is such a scam and shit show.
And completely opposite that, I was a bit shocked how aggressive modern macos (at least on M1 machines) are at hibernating, I have had to get used to `caffeinate` long-running process because on battery if that's not in use as soon as the screen turns off the machine stops doing anything, even with "low power mode" disabled.
I expect there's a pmset somewhere to change that (as there is an option in the UI when on power adapter), but with the battery life of the new devices I've kinda stopped plugging it in (even at my desk).
And this is why I am forced to use mac, where I can safely close the lid and expect the battery to last
Serious question: i'm back at daily driving macOS at work after using other platforms for a while. Caffeine vs Amphetamine (app), whats the preferred one these days?
May I suggest https://keepingyouawake.app/
As a gnu/linux person forced on Mac for work, this was what I settled on that worked reliably for me. (I found I would often crash iterm2 or alacritty and lose my terminal based caffiene commands)
As a gnu/linux person forced on Mac for work, this was what I settled on that worked reliably for me. (I found I would often crash iterm2 or alacritty and lose my terminal based caffiene commands)
Couldn't say, I'm using caffeinate because it's builtin, and more or less every time I need the feature it's because of a dev / shell thing, so the ability to run `caffeinate <command>` or `caffeinate -w <pid-of-program-I-forgot-to-run-through-caffeinate >` is what I need.
I'm pretty sure they both work through the standard power assertions API[0], so nothing precludes having both (in fact if you have amphetamine you necessarily have both) and using whichever's more convenient for your needs at any time.
Unlike AlDente (versus native) there should not be any conflict between caffeinate and amphetamine, because both simply signal to the system that some forms of sleep / power saving should not be used. If caffeinate says the disks can't idle-sleep and amphetamine says the system can't idle sleep, then neither will happen and that's that.
[0] https://developer.apple.com/documentation/iokit/iopmlib_h
I'm pretty sure they both work through the standard power assertions API[0], so nothing precludes having both (in fact if you have amphetamine you necessarily have both) and using whichever's more convenient for your needs at any time.
Unlike AlDente (versus native) there should not be any conflict between caffeinate and amphetamine, because both simply signal to the system that some forms of sleep / power saving should not be used. If caffeinate says the disks can't idle-sleep and amphetamine says the system can't idle sleep, then neither will happen and that's that.
[0] https://developer.apple.com/documentation/iokit/iopmlib_h
> "modern standby" is such a scam and shit show.
On x86, maybe. Try booting an M1 Mac, turning off the screen (without closing the lid - that's what makes it go to sleep instantly), SSHing in, and running a shell loop that prints out the date every minute.
I left it running and the thing didn't even drop from 100% battery after 3 hours, when macOS finally decided to go into real standby and that killed the connection. Did it for another 3 hours and I was at 98%. That's 2% battery usage per 3 hours for a system with an OS running, active WiFi, and an open TCP connection.
"Modern standby" works when your hardware has good power management.
FWIW, I've never seen an M1 go into hibernation other than when the battery is about to die. The normal lid closed state is true sleep, not hibernation. You can tell because waking up from actual hibernation actually takes a progress bar and a few seconds.
On x86, maybe. Try booting an M1 Mac, turning off the screen (without closing the lid - that's what makes it go to sleep instantly), SSHing in, and running a shell loop that prints out the date every minute.
I left it running and the thing didn't even drop from 100% battery after 3 hours, when macOS finally decided to go into real standby and that killed the connection. Did it for another 3 hours and I was at 98%. That's 2% battery usage per 3 hours for a system with an OS running, active WiFi, and an open TCP connection.
"Modern standby" works when your hardware has good power management.
FWIW, I've never seen an M1 go into hibernation other than when the battery is about to die. The normal lid closed state is true sleep, not hibernation. You can tell because waking up from actual hibernation actually takes a progress bar and a few seconds.
[deleted]
Is this only true of Windows hardware, or does it include hardware designed for Linux?
AFAIK Dell has removed S3 from all their recent laptops, only S0iX ("modern standby") is available. Doesn't matter what OS you install.
Does consumer hardware designed for linux even exist? Even bigger shops like system76 buy preconfigured laptops and install coreboot and PopOS! on it.
Yes. System76 partnered with Clevo to do their laptops, but it's not the exact same hardware as when you buy Clevo directly. E.g. https://twitter.com/jeremy_soller/status/1322954964549824512 I recall also discussing this with them when I was waiting for a laptop to get refreshed. There were working with Clevo to get some firmware issue fixed before they would ship it.
Of course, their Thelio hardware is very much not just a rebranded white box vendor. :)
I agree it could be better. It'd be really nice if the Linux hardware vendors had sufficient pull with the odms to get even more Linux didn't designs put together. Buying Windows hardware and putting Linux on it, however--even if you're waiting for some day when the better situation has arisen--, is actively working _against_ that goal.
Of course, their Thelio hardware is very much not just a rebranded white box vendor. :)
I agree it could be better. It'd be really nice if the Linux hardware vendors had sufficient pull with the odms to get even more Linux didn't designs put together. Buying Windows hardware and putting Linux on it, however--even if you're waiting for some day when the better situation has arisen--, is actively working _against_ that goal.
There may be others that do more. If so, I'd like to know it. Pine perhaps? System76 has done really good work on this and is the best option I know of.
Their Thelio hardware is off the shelf, mine has a regular Gigabyte board.
I don't think they fab their own chips either. It's a stretch to say the whole system is off the shelf because it has a commercially available motherboard with custom firmware, e.g. https://tech-docs.system76.com/models/thelio-massive-b1.2/RE...
The XPS13 DE could be construed as that, it's only available with Linux, has different hardware than the standard XPS, and is very routinely called "Linux Developer Edition" by the press (though I couldn't say if Dell ever called it that).
I explored the situation on a few dells, and they have obvious bugs in their bios ACPI tables: it's as if they had been written by an intern discovering this technology.
Long story short, on at least a few ones I explored deeply (The 7275 or the 9250 can't remember) the dell just can't sleep right, even on Windows.
What saves the day is Windows proper sleep support, including hybrid sleep, that prepares for the worst (save an S4 hibernation image) and hopes for the best (wakes up time to time to check what's left in be battery, to decide when to give up when the power goes below what's called the sleep budget, to ensure the laptop will be able to wake up)
The beauty of it is when laptops have a wrong bios that just cant sleep, windows hides the bug away.
The sad part of it is that Windows takes the blame (the laptol takes a long time to wake up from suspend to disk, and shows the power has been almost exhusted) for the manufacturer incompetence.
I think this is why they introduced a change early on in Windows 10 that when tne measurements at the beginning of the sleep showed the power was going down with a dangerously steep slope, it was a clear sign Windows was running on a poorly designed laptop, and that it should abandon all hope of s2idle working right, and instead just powed off the poor laptop to put it out of its misery and instead try to do a fast start with the hibernation image the next time
The worst part is that the dangerously incompetent people at dell, unaware of their own incompetence (they couldnt write proper ACPI sleep in the first place) decided to double down on the stupidity and did some weird things to mislead windows and prevent it from giving up on s2idle.... which is why dell latops have acquired a reputation they may catch fire when in a bad.
It's all both funny and sad, so I applaud lenovo for finding ways to make S3 sleep work on laptops like the x10 gen1, which uses a generation of intel CPU where the excuse of manufacturer of 'made for linux' laptops is that S3 can't work because it was no longer supported by Intel anymore...
Long story short, on at least a few ones I explored deeply (The 7275 or the 9250 can't remember) the dell just can't sleep right, even on Windows.
What saves the day is Windows proper sleep support, including hybrid sleep, that prepares for the worst (save an S4 hibernation image) and hopes for the best (wakes up time to time to check what's left in be battery, to decide when to give up when the power goes below what's called the sleep budget, to ensure the laptop will be able to wake up)
The beauty of it is when laptops have a wrong bios that just cant sleep, windows hides the bug away.
The sad part of it is that Windows takes the blame (the laptol takes a long time to wake up from suspend to disk, and shows the power has been almost exhusted) for the manufacturer incompetence.
I think this is why they introduced a change early on in Windows 10 that when tne measurements at the beginning of the sleep showed the power was going down with a dangerously steep slope, it was a clear sign Windows was running on a poorly designed laptop, and that it should abandon all hope of s2idle working right, and instead just powed off the poor laptop to put it out of its misery and instead try to do a fast start with the hibernation image the next time
The worst part is that the dangerously incompetent people at dell, unaware of their own incompetence (they couldnt write proper ACPI sleep in the first place) decided to double down on the stupidity and did some weird things to mislead windows and prevent it from giving up on s2idle.... which is why dell latops have acquired a reputation they may catch fire when in a bad.
It's all both funny and sad, so I applaud lenovo for finding ways to make S3 sleep work on laptops like the x10 gen1, which uses a generation of intel CPU where the excuse of manufacturer of 'made for linux' laptops is that S3 can't work because it was no longer supported by Intel anymore...
[deleted]
Yes even the project sputnik laptops have it removed, which is incredibly frustrating. I got a precision 5530 replaced by dell with a precision 5550 and the new one doesn’t sleep.