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.
Getting hibernation to work under Linux Lockdown is technically impressive, and now we know how it can be done. But should it be done?