Hacker News Reader

Comment by kawsper | Hacker News Reader

Fedora doesn't even create swap partitions anymore, so you have to enable that first to enable hibernation, enabling it requires you to create a swap-partition, change things in systemd and meddle with the grub-configuration: https://www.ctrl.blog/entry/fedora-hibernate.html

View on HN

if you use secure boot, you cannot use hibernation under fedora (or any Linux, afaik) since there is no way to "seal" the hibernation image from modification by an attacker who could mount the swap on another OS where they have root. this is regardless of disk encryption.

Secure boot is not that useful anyway. I'm kind of security freak, but I decided that security boot is not worth it. My disk is encrypted to protect from stolen laptop. My BIOS and grub have password to protect from someone using keyboard. Scenario with someone meddling with my boot partition and replacing my kernel with modified one is just not realistic for my life. So just disable it and enjoy proper hibernation, that's my opinion.

I don't know precisely how secure boot works under fedora, but you can have FDE with swap just fine in Linux. A swap partition can live inside a LVM logical volume.

For secure boot I would guess you could have the EFI partition signed/validated with the TPM.

This.

In my case, I use SecureBoot to check the boot image's signature (contains the kernel + initrd + boot params). Then it starts everything from an LVM that lives on top of LUKS. I always have to type in the password (never bothered to get the TPM working), but I don't see why the TPM wouldn't be able to do it.

From the system boot point of view, it just starts an OS. The OS will then proceed to load some data in RAM. It's its business whether this is "fresh" data for a new boot, or "old" data from the last boot.

"Cannot" this is not true. It might not satisfy some sort of branding requirement but at the end of the day all a secure boot implementation does under the hood is to verify the kernel against the signing keys stored in the firmware before handing off control to it. The kernel can do whatever it pleases after that including granting you root access, joining a botnet, or, indeed, loading a hibernation image.

As for security, the hibernation image is at risk unless you use full disk encryption. But then (last time I checked) so is the typical Linux distro because ultimately you (the end user) have complete control over the OS. That means that at some point the kernel has to load and run privileged code that was never signed by some central authority. The only alternative to this would be sending all drivers to be signed by someone else, even those you built yourself from source.

tl;dr You can in fact use hibernation if you set it up, even with secure boot. Doing so is not a security issue. Lack of full disk encryption is always a security issue if physical access is an attack vector you are concerned about.

Huh TIL. Apparently the mainline kernel got a lockdown feature in version 5.4 that prohibits this. Ubuntu started shipping with a version of the patches in 2018. So I guess you'll have to disable that "helpful" feature first if you want to restore functionality.

TBF hibernation has never been entirely reliable under Linux due to hardware vendors being difficult (IIUC). Getting it working for me has typically involved trying to make sense of arcane kernel log messages. I never managed to on my current laptop.

I don't really understand why is it the case. I could understand that sleep is a complex mode, when hardware have to properly sleep and restore. But hibernate is just dumping RAM to disk. It should not require anything special from underlying hardware.

Because reinitialising all the hardware and bringing it back to the same state is hard, and sometimes impossible with buggy hardware or whose full spec cannot be known..

If you create a swap partition manually during installation and there's no secure boot, Fedora will put the "resume=" parameter into your grub config automatically.

You still need to create `/etc/dracut.conf.d/resume.conf` with `add_dracutmodules+=" resume "` line and regenerate initramfs with `dracut -f`. Then it should work.

I don’t really think that hubernating is worth it when you have gobs of RAM and a lot of data and state in it. The sheer time it’s going to take each time even with an NVMe drive, blergh.

Now that batteries are decent and S3 on Linux is good, I don’t bother with anything else. I reboot/power off my machines on a regular basis to make sure the things I need persisted are, in fact, persisted and everything will be brought up again.

So I was quite surprised to find resume= pointing to my swap partition in my /proc/cmdline after a default install.

Reply on news.ycombinator.com