3 ms·

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

by sprayk 5y ago

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.

einnhverr 5y ago
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.
- vladvasiliu 5y ago
  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.
d110af5ccf 5y ago
"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.
- d110af5ccf 5y ago
  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.
vbezhenar 5y ago
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.

by sprayk 5y ago

einnhverr 5y ago

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.

vladvasiliu 5y ago
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.

d110af5ccf 5y ago

"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.

d110af5ccf 5y ago
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.

vbezhenar 5y ago

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.