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?
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 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.
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.
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.
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.
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?
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.
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.
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.
...or when something that seems almost innocuous today, a processor serial number, caused such a huge amount of opposition that it was actually removed:
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.
> "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.
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.
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.
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...
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 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.
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.)
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…)
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.
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.
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.
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.
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.
Getting hibernation to work under Linux Lockdown is technically impressive, and now we know how it can be done. But should it be done?