Making hibernation work under Linux Lockdown(mjg59.dreamwidth.org)
mjg59.dreamwidth.org
Making hibernation work under Linux Lockdown
https://mjg59.dreamwidth.org/55845.html
10 comments
Anyone else fondly remember when the TPM chip was considered the most evil chip in the world? Simpler times...
...or when something that seems almost innocuous today, a processor serial number, caused such a huge amount of opposition that it was actually removed:
https://news.ycombinator.com/item?id=10106870
Now, users are getting dumbed down and herded in the name of "security", and losing more and more freedoms every day... while being almost completely unaware of it.
https://news.ycombinator.com/item?id=10106870
Now, users are getting dumbed down and herded in the name of "security", and losing more and more freedoms every day... while being almost completely unaware of it.
I don't understand the issue at stake here.
> "if you were root you could just replace the on-disk kernel with a backdoored one and reboot."
Isn't this a vital necessity? You want to be able to update the kernel to a new version, don't you? Preventing root from being able to do vital system maintenance sounds to me like the opposite of what you want.
If an attacker has become root, the system is compromised. As far as I know, security should focus on preventing an intruder from getting root access. Once the intruder gets root access, isn't it kinda pointless to worry about the kernel?
> "if you were root you could just replace the on-disk kernel with a backdoored one and reboot."
Isn't this a vital necessity? You want to be able to update the kernel to a new version, don't you? Preventing root from being able to do vital system maintenance sounds to me like the opposite of what you want.
If an attacker has become root, the system is compromised. As far as I know, security should focus on preventing an intruder from getting root access. Once the intruder gets root access, isn't it kinda pointless to worry about the kernel?
There's three things we really want here:
1) Prevent people gaining inappropriate privileges
2) Detect if people have gained inappropriate privileges
3) Prevent those inappropriate privileges form being persisted
If we can achieve (1) then (2) and (3) are irrelevant. If we can't, then (2) depends on the kernel being trustworthy (things like IMA and audit can give strong indications of compromise, but if the attacker can get into the kernel then they can just hide themselves), and (3) is much easier for an attacker to undetectably pull off if they can switch out the on-disk kernel.
If we can achieve (1) then (2) and (3) are irrelevant. If we can't, then (2) depends on the kernel being trustworthy (things like IMA and audit can give strong indications of compromise, but if the attacker can get into the kernel then they can just hide themselves), and (3) is much easier for an attacker to undetectably pull off if they can switch out the on-disk kernel.
Replace kernel with unsigned kernel where appropriate. They’re saying basically root should NOT be able to get to an unsigned kernel via swap/hibernation tricks. Who holds the keys is left up for discussion.
And I disagree with that. You've got to be able to run your own OS on your own system, don't you? If you disagree with some choices made in the "official" kernel, you should be able to make your own changes. If you work on kernel development, you should be able to test your changes.
If root can't control these things, then who can? Besides, even if root can't change the kernel, the system will still be compromised if an intruder gets root access.
If root can't control these things, then who can? Besides, even if root can't change the kernel, the system will still be compromised if an intruder gets root access.
The point is that if the owner has chosen to required signature verification to boot, one shouldn't be able to get around this by restoring from a hibernation image. Imagine you as the party who booted the original kernel, and an evil maid as the party injecting the fake hibernation image.
The real problem with TPM and its ilk is that keys owned by the manufacturer are baked in, rather than being owner-changeable by some suitable procedure. Overall, local cryptographic integrity does make sense. Remote Attestation is the actual threat to Freedom, but that's a separate discussion.
The real problem with TPM and its ilk is that keys owned by the manufacturer are baked in, rather than being owner-changeable by some suitable procedure. Overall, local cryptographic integrity does make sense. Remote Attestation is the actual threat to Freedom, but that's a separate discussion.
You can pretty easily sign your own kernel, it's not just manufacturer discretion.
Yeah, it's the same as SELINUX - layers of security.
I could easily see reasons to have a box that can boot a signed kernel but the signing keys are held by me offline.
I could easily see reasons to have a box that can boot a signed kernel but the signing keys are held by me offline.
I wish hibernation would consistently work at all...
Why is hibernation even a thing? I can count the number of times I've wanted it on zero fingers.
Laptops, mostly, to maximize battery life. If I'm going on a flight, I'll charge and hibernate my system at home, bag it, then drive to the airport and get through security. This is about a 2 hours process and entails zero battery drain.
But over suspend to RAM? Suspend to RAM eats through basically zero battery, and can trivially survive the plane flight. (I've taken my laptop on flights, drained the battery to <10% in the course of the flight, and had it spent the last several hours in suspend-to-RAM.)
(There might be some discussion about security in America's airports, and their overzealousness towards illegal searches, and on that basis, I'd entertain hibernation as superior.)
(There might be some discussion about security in America's airports, and their overzealousness towards illegal searches, and on that basis, I'd entertain hibernation as superior.)
If you suspend to RAM, and there's some kind of failure, you lose everything, likely leaving some things in a bad state. Hibernation is way less likely to have something like that happen. Of course, the best of both worlds is Suspend then Hibernate.
You lose the running state, as if you'd pulled the battery out. I've had that only happen a few times, ever. Many applications nowadays recover from that. My editor has recovery files, many of my games autosave, my web browser restores the session, etc. It is disruptive, yes, but it's rare enough that I just don't care that much about it. (And definitely not enough that I'd trade the speed of suspend-to-RAM for the reliability of suspend-to-disk.)
(I've had far more issues with the physical connection between the laptop & the battery not being very solid anymore…)
(I've had far more issues with the physical connection between the laptop & the battery not being very solid anymore…)
What do you mean by lose everything? AFAIK, suspend syncs the disks so there really shouldn’t be any half-written data.
On Linux with SystemD at least, suspend doesn't sync to swap unless you use suspend-then-hibernate, which involves getting hibernation set up. That's exactly what I do, though with a relatively short timer since my laptop is encrypted. Not that realistically anyone stealing my laptop would be able to extract the key if it was suspended, but I just like putting in the password in the stark, pre-boot environment.
Everything being "the contents of ram and the running system image". Suspend to ram doesn't write the contents of ram to disk, it keeps the ram active, constantly refreshing it.
Hybrid Suspend will suspend to ram, then additionally write the contents of ram to disk, so that the image can be resumed in the event of a power failure. The "resume" codepaths in this case are literally the same as if you'd just hibernated.
Hybrid Suspend will suspend to ram, then additionally write the contents of ram to disk, so that the image can be resumed in the event of a power failure. The "resume" codepaths in this case are literally the same as if you'd just hibernated.
I interpreted that as "syncs the disks", as in, flushes the buffers. (which it does, I believe, do.) A failure to suspend from RAM isn't that harmful: it's just an unscheduled reboot, as if you'd suddenly removed power.
The wording they're responding to is pretty vague: "lose everything". What is "everything"? E.g., the filesystem state is in good order. And even though RAM gets reset, many applications, like Firefox, will usually simply realize what happened, and recover.
The wording they're responding to is pretty vague: "lose everything". What is "everything"? E.g., the filesystem state is in good order. And even though RAM gets reset, many applications, like Firefox, will usually simply realize what happened, and recover.
I meant the system state when you suspended. You're absolutely right that it's just like an unplanned reboot, which isn't the worst thing in the world, but if (for example) you're doing funny things with tmpfs it can cause issues. Or, if you suspend habitually with unsaved progress, you would be in greater danger of losing it. Neither is enormously important, but it's worth noting.
But what's the real value over a cold boot? Wake from hibernate takes a lot longer than a cold boot, and to me it doesn't seem to save any time.
You don't lose open apps, files, tabs, etc., so your work is not interrupted.
I've not perceived any time difference between cold boot and wake from hibernation, on a decently fast SSD.
I've not perceived any time difference between cold boot and wake from hibernation, on a decently fast SSD.
Which OS are you using? I've never noticed a difference between cold boot and hibernate on Linux.
Anecdata: back in the days when I was using Ubuntu (pre-Unity) on what was even at the time moderately old hardware, there was an obvious difference. Standard bootup took 20-30 seconds, resuming from hibernation took multiple minutes.
Just thinking about it on an abstract level, it's not that unintuitive that resuming from hibernation should be slower than both cold boot and resuming from sleep. When you cold boot you need to load the kernel and startup programs into memory. With hibernation you need to load the whole previous operating state into storage, which is going to mean multiple GBs need to be read from your swap partition into memory. It's not hard to imagine that on many systems the hard drive will be the slowest piece of hardware.
Just thinking about it on an abstract level, it's not that unintuitive that resuming from hibernation should be slower than both cold boot and resuming from sleep. When you cold boot you need to load the kernel and startup programs into memory. With hibernation you need to load the whole previous operating state into storage, which is going to mean multiple GBs need to be read from your swap partition into memory. It's not hard to imagine that on many systems the hard drive will be the slowest piece of hardware.
Are you sure you're including the amortized lifetime cost of whatever you had to do / whatever you will have to do to troubleshoot Linux resume-from-disk?
I kid, but I do use Linux, it's just a Linux that doesn't even offer hibernate and boots cold in one second: ChromeOS.
I kid, but I do use Linux, it's just a Linux that doesn't even offer hibernate and boots cold in one second: ChromeOS.
I'd absolutely love to use it on my secondary machine, a desktop PC running Windows 10 – just hibernate and pick up right where I've been a few days later without leaving it in standby blinking its super bright LED aggressively. Sadly if I send it to hibernate the PC will always turn itself back on in the night, so no hibernate for me...
You should check `powercfg lastwake` via PowerShell, and Event Viewer, to determine what wakes up your PC.
I had similar issues, and IIRC, I had to disable wakeups for network adapters in Device Manager.
I had similar issues, and IIRC, I had to disable wakeups for network adapters in Device Manager.
Thank you for this -- I've been bothered by my Windows PC not sleeping properly for the best part of a year. `powercfg lastwake` indicated the Ethernet adapter and then disabling the option "Wake on Pattern Match" has allowed the computer to sleep soundly.
I've tried lots of things from the first page of google results but I don't think I've tried that. Will give it a shot for sure!
I really do not understand Windows 10. It really seems like Windows 10 laptops and PCs are unable to sleep. They keep waking up, and then refuse to sleep. Frequently I find my work laptop in the morning turned on by itself, screen on, fan blowing enthusiastically. Power management in Windows 10 seems to be utterly broken. It certainly doesn't obey any of my settings.
To prevent a machine with full disk-encryption from having its key in memory while you're not watching it:
- With hibernation it is possible to store the hibernation file on the encrypted root partition so you will have to re-enter the password during boot.
- With suspend-to-RAM, it would always be in memory.
- With hibernation it is possible to store the hibernation file on the encrypted root partition so you will have to re-enter the password during boot.
- With suspend-to-RAM, it would always be in memory.
An awful lot of work to protect my system from myself.
It was unfortunate to use that name Linux Lockdown. It was selected before COVID-19 though.
I'm no kernel dev but yet I understood pretty much all of it. Well written!
Matthew's blog is great, I've been subscribed to it for years.
I'm always a little wary of technological innovations that stop the system administrator from being able to administer the system. I understand the concept of not trusting root, but the solution surely isn't “so make the manufacturer the real root”. There isn't even a hardware override for this!
Getting hibernation to work under Linux Lockdown is technically impressive, and now we know how it can be done. But should it be done?
Getting hibernation to work under Linux Lockdown is technically impressive, and now we know how it can be done. But should it be done?
but the solution surely isn't “so make the manufacturer the real root”
I think it's pretty clear what features like this are designed for. The mobile ecosystem and their walled gardens, where the manufacturers --- and Google --- certainly do want complete control (and it's a little funny to see the power struggles between them), and treat the users as nothing more than consumption-slaves to be milked for profit.
I think it's pretty clear what features like this are designed for. The mobile ecosystem and their walled gardens, where the manufacturers --- and Google --- certainly do want complete control (and it's a little funny to see the power struggles between them), and treat the users as nothing more than consumption-slaves to be milked for profit.
You put your computer into hibernation and walk away for a few hours, then come back and wake it up. Wouldn't it be nice to have a cryptographic guarantee that the image you are resuming from is indeed the same one you hibernated to? That takes away a possible attack vector.
In that scenario attacker doesn't have access to root anyway, so disk encryption is sufficient to protect against this.
> There isn't even a hardware override for this!
You can always use mokutil to disable this.
You can always use mokutil to disable this.
Unless the motherboard doesn't implement those APIs. It's difficult to tell until you've bought the computer – and my concern is that being able to change the keys might become a premium feature.
Computers should be loyal by default.
Computers should be loyal by default.
Which APIs? I've never seen a motherboard where SetVariable() is sufficiently broken that mokutil won't work.
Thanks - this isn't a case of not implementing APIs, this is a broken implementation. I'll look into it.
Then just disable lockdown in your kernel.
It's the administrator that enables or disables this feature, though. Laptops often come with some pretty advanced encryption hardware (the TPM) built in, and it's mostly useless silicon if you don't find a way to use it.
The kernel trusts the hardware it runs on to do what it's supposed to do, unless it has some good reason to apply security restrictions to a device.
_Real_ root turns on or off the hardware by configuring hibernation in lockdown or disabling it. Leave it disabled if you don't trust the TPM manufacturer, but I don't see a reason why not to use it to secure your operating system. Intel processors run a separate 486 CPU for scheduling reasons, there's so many potential security backdoors in the average laptop that I wouldn't worry about the TPM too much.
In the end, this is just another trick that Windows could already securely do for years that Linux only just learned. "Can I hibernate without compromising kernel security measures when Windows can" isn't a great question to have to answer with "no, because..." if you want to advocate Linux to businesses.
The kernel trusts the hardware it runs on to do what it's supposed to do, unless it has some good reason to apply security restrictions to a device.
_Real_ root turns on or off the hardware by configuring hibernation in lockdown or disabling it. Leave it disabled if you don't trust the TPM manufacturer, but I don't see a reason why not to use it to secure your operating system. Intel processors run a separate 486 CPU for scheduling reasons, there's so many potential security backdoors in the average laptop that I wouldn't worry about the TPM too much.
In the end, this is just another trick that Windows could already securely do for years that Linux only just learned. "Can I hibernate without compromising kernel security measures when Windows can" isn't a great question to have to answer with "no, because..." if you want to advocate Linux to businesses.
Do you have a source for Windows being able to use the TPM to attest the validity of the hibernation file?
The TPM and TPM state are used to unlock the filesystem that contains the hibernation file. If the TPM state is altered, Bitlocker won't boot without a recovery key.
Unencrypted Windows installations do not validate the hibernation file as far as I know.
Then again, encrypting Windows is a lot easier than setting up TPM encryption on Linux. On Windows it's just a button, "enable Bitlocker". On Linux, you're reinstalling if you didn't enable encryption on startup or messing about with moving files in between encrypted and and unencrypted partitions, followed by random tutorials or Github shell scripts to enable the TPM. Or, if you don't care about the easy of use of the TPM, enter a passphrase during every boot.
However, even on unencrypted Windows, you never needed to disable the system enforcing signature checks just to enable hibernation.
Unencrypted Windows installations do not validate the hibernation file as far as I know.
Then again, encrypting Windows is a lot easier than setting up TPM encryption on Linux. On Windows it's just a button, "enable Bitlocker". On Linux, you're reinstalling if you didn't enable encryption on startup or messing about with moving files in between encrypted and and unencrypted partitions, followed by random tutorials or Github shell scripts to enable the TPM. Or, if you don't care about the easy of use of the TPM, enter a passphrase during every boot.
However, even on unencrypted Windows, you never needed to disable the system enforcing signature checks just to enable hibernation.
Without drive encryption, you cannot ensure that you have a secure system.
[deleted]
Well, if you don't need Linux Lockdown, don't enable it.
The problem Linux Lockdown fixes as follows: Microsoft BitLocker stores its key in TPM which is accessible to Ring 0 code only. If the user would be able to run arbitrary Ring 0 code they could bypass BitLocker without actually knowing the password.
To prevent this, Secure Boot is being used which requires the kernel to be signed. To avoid the necessity for user to allow distribution key in UEFI settings, many Linux distributions sign their kernel using Microsoft keys and to make sure this couldn't be used to run arbitrary Ring 0 code (which could end up with Microsoft revoking their key). Linux kernel enforces various restrictions: no loading custom modules and so on.
Hibernation is complicated with Linux Lockdown as during hibernation, kernel loads contents of swap disk into RAM. Somebody could make their own Linux distribution, use a signed kernel from Canonical and make sure the bootloader would load their own malicious swap disk which would bypass Secure Boot requirements.
The problem Linux Lockdown fixes as follows: Microsoft BitLocker stores its key in TPM which is accessible to Ring 0 code only. If the user would be able to run arbitrary Ring 0 code they could bypass BitLocker without actually knowing the password.
To prevent this, Secure Boot is being used which requires the kernel to be signed. To avoid the necessity for user to allow distribution key in UEFI settings, many Linux distributions sign their kernel using Microsoft keys and to make sure this couldn't be used to run arbitrary Ring 0 code (which could end up with Microsoft revoking their key). Linux kernel enforces various restrictions: no loading custom modules and so on.
Hibernation is complicated with Linux Lockdown as during hibernation, kernel loads contents of swap disk into RAM. Somebody could make their own Linux distribution, use a signed kernel from Canonical and make sure the bootloader would load their own malicious swap disk which would bypass Secure Boot requirements.
Sibling comment says this doesn't matter because you can "just" tap the chip. I don't know if that's true, but practically, isn't the real reason why this doesn't matter is that there are a bunch of signed bootloaders that let you boot untrusted code? For example, famously, the Kaspersky rescue disk. [1] Even assuming that the key for this particular disk has been revoked, trusting this to protect your system seems rather fraught, as it's not good enough for your kernel to be secure from ring-0 privesc, every single signed image in the world needs to be as well.
Could be I'm missing something. Is it impossible to replace the boot disk entirely once Secure Boot is enabled? Hard to see how the hardware failure case would be handled.
[1] https://habr.com/ru/post/446238/
Could be I'm missing something. Is it impossible to replace the boot disk entirely once Secure Boot is enabled? Hard to see how the hardware failure case would be handled.
[1] https://habr.com/ru/post/446238/
PCRs of the TPM.
Combined with full drive encryption, the bootloader not matching will make the TPM not release the drive encryption key.
Combined with full drive encryption, the bootloader not matching will make the TPM not release the drive encryption key.
Wait - given that Ubuntu's signed shim/GRUB is willing to load unsigned non-EFI kernels, does that mean you can use it from a USB stick to unlock a BitLocker machine, without even messing with hibernation?
No. BitLocker when it uses the TPM uses verified boot.
PCRs are filled during the boot process, recording the boot state. If the boot state does not match, the TPM will not release the key.
PCRs are filled during the boot process, recording the boot state. If the boot state does not match, the TPM will not release the key.
Then it shouldn't matter whether you can modify a hibernated Linux image to gain arbitrary code execution in ring 0, right? (That is, the benefit of securely implementing Linux lockdown hibernation would be a direct benefit for Linux users who care about lockdown and hibernation, as opposed to an indirect benefit for Windows / BitLocker users who don't want to be attacked through Linux.)
Yes, the benefit of securely implementing hibernation with Secure Boot on for Linux is a direct benefit for Linux users, no impact one way or another for those using Windows.
OK - that matches my understanding, that the threat model of BitLocker includes the possibility of attackers having ring 0 access using a different OS. I've downvoted the comment I originally replied to, since it appears to be totally wrong.
And all of this makes zero sense, given that anybody can simply tap the TPM chip itself.
All x86 TPMs are effectively pwned, and useless for their stated application.
TPM never served any real security role.
Making a system fully secure against a physical attack is impossible, and looks plainly silly to anybody knowing how computers work.
Even specially protected credit card chips cost only few thousand dollars to extract a key from in the numerous "firmware recovery" shops.
All x86 TPMs are effectively pwned, and useless for their stated application.
TPM never served any real security role.
Making a system fully secure against a physical attack is impossible, and looks plainly silly to anybody knowing how computers work.
Even specially protected credit card chips cost only few thousand dollars to extract a key from in the numerous "firmware recovery" shops.
It was mentioned in second paragraph, that there is basically no security that can be enforced since root, can load arbitrary modules into kernel.
So, how does the localities of TMP, solve the problem of rogue root installing custom TPM kernel module, that have access to locality 1?
So, how does the localities of TMP, solve the problem of rogue root installing custom TPM kernel module, that have access to locality 1?
Once you're in the secure boot world, you enforce module signatures.