Hacker News new | ask | show | jobs
by fpoling 262 days ago
I really do not understand why hibernate under secure boot is not implemented on Linux and this continues for years.

It is as if the features are implemented by completely different people. But this is not obviously the case since systemd supports both and actively improving both.

Note for me hibernation is a security measure and not about saving battery. I am traveling sometimes with the laptop and risk of theft is non-trivial. If it is hibernated, then it is just a property loss. But with just suspend there is a chance that the data can be extracted. So I configured it to hibernate automatically after 15 minutes in suspension. Surprisingly it has been working reliably with Linux.

3 comments

I have secure boot, hibernation, and full disk encryption working fine on linux, but I have never heard of kernel lockdown.

The solution I found involves making a custom initramfs to support hibernation and compiling the kernel into a signed EFI stub.

To add some context: man kernel_lockdown[1] reads "Unencrypted hibernation/suspend to swap are disallowed as the kernel image is saved to a medium that can then be accessed.". And to my understanding there is currently no way to tell a (mainline) kernel that allows "encrypted hibernate", i.e. no way to tell the kernel that its hibernation disk is "secure".

So its not a direct "linux prevents hibernate on secure boot", its "linux recommends kernel_lockdown when secure booting", "kernel_lockdown prevents hibernate with unencrypted swap" and "theres no well to make the kernel believe the hibernation disk is encrypted", but the result is the same.

You can "just" run secure boot without lockdown. Its a cmdline, you can just omit it. You can run custom patch sets that add cmdline options so the kernel allows hibernation in lockdown (if you pinky-promise the swap is encrypted).

But neither of these are easily accessible to the average user.

1: https://manpages.debian.org/bullseye/manpages/kernel_lockdow...

It seems there should be a distro that eases this route with some configuration options. Is there none?
Does the system use a boot loader? Or does it boot directly into kernel bypassing bootloaders?
The term to search for is "UKI".

A UKI is a kernel+initramfs+boot-arguments bundle all as a single WinPE/UEFI executable using the "EFI Stub Loader".

You configure your system firmware to execute it, passing no arguments. It boots using the command line you set earlier. It's signed, and verified by the platform secure boot.

Hibernation works fine with this approach.

> Hibernation works fine with this approach.

Can you explain why it improves the hibernation behavior? I have seen UKI mentioned before but never heard that it improves hibernation.

It doesn't, it's just another bootstrapping method that happens to work fine with hibernation.

UKI allows you to extend your chain of trust from the bootloader to ramdisk, instead of just your bootloader and kernel. From there, you can enable kernel lockdown and checking of module signatures if you want to.

I think you can do the same thing without UKI (I forget tbh), but UKI simplifies it with one UEFI executable that doesn't even need a bootloader.

Does this mean that the hibernated image must be signed each time the laptop hibernates?
It boots directly into the kernel without a bootloader. You can specify built-in command line options when you're compiling the kernel.

To dual-boot, I boot from a removable USB drive on my keychain. When it's not plugged in, it boots windows instead.

This may or may not apply to your situation, but at least some motherboards have an integrated bootloader. You need to register the options with it (via efibootmgr for example). Then pressing a key (check your manual) presents you with the options.

This has worked with both Linux and Widows on all my machines: handbuilt 3rd gen intel with an asus MB, 6th gen with some msi, 10th gen with a cheap Gigabyte, and an assorted bunch of HP Elite desks and books with intel and AMD.

I understand there’s even a way for them to auto detect the options, but since this has been a set it forget it type thing, I never bothered to look into it.

You can do both.
> It is as if the features are implemented by completely different people

This is almost definitely true considering it’s an massive open source project

I have looked into this. It is possible, and documented on the Arch wiki. My main concern is constantly writing a large file to a small SSD.
Unless it's a really old SSD, lifetime is so massively extended over 15+ old SSDs, that it's not even a consideration any more. People use consumer grade SSDs for databases which last years, even when mostly full.

I expect many of the servers I have deployed, again consumer grade SSDs, would have more writes in a day than you in a year -- even with several suspends a day.

I cannot of course address the specific model you have, or the size of RAM you're suspending to swap space.

There’s also the fact that some laptops have laughably slow SSDs. I’m thinking my 2020 HP elitebook whose nvme drive is basically always slower than my 2012 sata drives… it takes forever to write the 32 GB of ram to it. It’s actually a better experience tu turn it completely off and on, unless there’s something I absolutely need to keep in its current state.