Making hibernation work under Linux Lockdown
mjg59.dreamwidth.org
mjg59.dreamwidth.org
Getting hibernation to work under Linux Lockdown is technically impressive, and now we know how it can be done. But should it be done?
You can always use mokutil to disable this.
Computers should be loyal by default.
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.
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.
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.
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.
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.
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.
Combined with full drive encryption, the bootloader not matching will make the TPM not release the drive encryption key.
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.
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.
> "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 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.
I could easily see reasons to have a box that can boot a signed kernel but the signing keys are held by me offline.
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.
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.
So, how does the localities of TMP, solve the problem of rogue root installing custom TPM kernel module, that have access to locality 1?
I had similar issues, and IIRC, I had to disable wakeups for network adapters in Device Manager.
I've not perceived any time difference between cold boot and wake from hibernation, on a decently fast SSD.
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.
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.
(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.)
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.
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've had far more issues with the physical connection between the laptop & the battery not being very solid anymore…)
- 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.