Hibernation deliberately turned off under Secure Boot

Support and Help
, , , ,
1

Ubuntu Support Template

Ubuntu Version:
24.04.4 LTS

Desktop Environment:
KDE Plasma

Problem Description:
I tried to turn on Secure Boot in my ASUS BIOS. Everything works well on boot, including NVIDIA, but hibernation does not work, even though I have it working without problems with Secure Boot off. Secure Boot activates Kernel Lockdown, whose policy it is to prevent hibernation altogether.

While I appreciate that Secure Boot is supposed to guarantee a clean kernel on boot-up, a policy of preventing hibernation on Secure Boot makes my system less secure, not more. I hibernate to a luks encrypted swap partition, so the disk image can’t be tampered with. Granted that without the ‘prevent hibernation’ policy it’s possible that a hacked system will be saved and rebooted, surely most hacks would have already done their damage on the system before hibernation. In general, my security is pretty good and it’s unlikely my active system will get hacked (albeit with Mythos…). And, by next boot, Secure Boot would at least warn me about tampering.

My work involves many desktops loaded with applications and windows. Session Manager does a lousy job of reviving my desktop (opens applications I didn’t have open, doesn’t open some applications, puts windows on the wrong desktops, etc.). So, I have to have hibernation. But under current lockdown policy, I can’t hibernate, which means I have to turn off Secure Boot. That means that my system is vulnerable to tampering in my unencrypted /boot directory. That to me seems like a much bigger risk than being hacked while using the OS, particularly so if the hack targets /boot.

Ideally, Canonical would expose a simple switch to allow users to use hibernation in a locked down kernel. To my knowledge, that doesn’t exist.

Relevant System Information:
Kernel: 6.8.0-110-generic arch: x86_64 bits: 64
Desktop: KDE Plasma v: 5.27.12 Distro: Kubuntu 24.04.4 LTS (Noble Numbat)

Screenshots or Error Messages:
```
Lockdown: swapper/0: hibernation is restricted
Lockdown: systemd-logind: hibernation is restricted
```

What I’ve Tried:
There’s at least one solution, but it would require what sounds like substantial modification and rebuilding of the kernel every time the kernel is updated. That isn’t practical for me.

2

https://askubuntu.com/questions/1106105/hibernate-with-uefi-and-secure-boot-enabled

3

Thanks pavlos! Your reference shows that a) this kernel lockdown behavior was implemented 7 years ago and there has been no convenient fix that allows hibernation dependent users to use Secure Boot, and b) Linus Torvald rejects this lockdown behavior, saying it is very unhelpful to users–which is my point as well.

So: No solution in sight, and top kernel developers saying this is a bug not a feature.

I wish Canonical would do one of: a) make it straightforward to encrypt /boot, b) give users an easy option to allow hibernation in kernel lockdown, or c) make hibernation permitted in kernel lockdown the default behavior, perhaps with a warning.

4

It’s not about “hacking” your running system, or prevention thereof. It’s about making sure that no key material, i.e. the encryption key for disk encryption, which lives in RAM and hence in the hibernation image, can be put on an unencrypted swap partition from where it can be trivially extracted, so that’d be a catastrophic “game over”.
Also, “my security is pretty good” is not a guarantee the kernel takes at face value. :wink: It’s just that it tries to detect swap encryption and your LUKS setup is transparent to that detector. You’d need to setup cryptswap for a successful detection.

5

a) goes against security goals of Secure Boot enabled Ubuntu. And it still doesn’t solve anything, see that thread for details on why encrypting /boot does not increase security. First, its contents are pretty much public knowledge and, second, an attacker could just put a key grabber on the ESP and have grub run that first.
b) proposes to hand out footguns to all the novice users, who won’t know what they’re in for.
c) defeats lockdown

BTW, b) is already there; just disable Secure Boot.