Summarized from some posts on the thread these were pulled from.
TL;DR
Is Secure Boot important? Yes.
Should it be made better? Yes.
Do you benefit from it in its current form (likely until >2028)? Almost certainly no.
Can Secure Boot and Hibernate work together? Not without disabling even more important security features, or the kernel adding a feature it requires but hasn’t yet even designed.
Why Secure Boot has to be disabled, but that’s OK.
Everyone (including me) rejects the idea out of hand of disabling Secure Boot to get Hibernate working. However, Secure Boot isn’t currently (likely until >2028) what you think it is.
Fedora, like a number of more secure distros, includes and enables the Lockdown kernel driver. This driver enforces certain minimum security standards from the driver level to make sure you, as a somewhat ignorant/lazy/pragmatic/realistic end-user, don’t accidentally do something to break the security of your system. Part of what it includes however is a conditional switch based on whether Secure Boot is enabled in the UEFI/BIOS or not.
If Secure Boot is enabled, the Lockdown driver requires hibernation to use a kernel-specific implementation of “encrypted hibernate swap”, otherwise the driver will block hibernate. The standard LUKS encrypted swap partition/file however doesn’t qualify, and in fact the only thing that does qualify is a kernel implementation that doesn’t exist and hasn’t even been designed yet. So effectively you can’t do hibernation with the Lockdown driver present and Secure Boot enabled. Lockdown still has a lot of security benefits though, so you don’t want to disable it.
The way Secure Boot works in practice currently (probably >2028) isn’t really very secure. It’s promoted in concept by a lot of people and organizations, rightfully so, but the current implementation for desktop systems doesn’t really add much security.
The security mitigation of Secure Boot is mostly supposed to be against physically-present attackers (i.e. Evil Maid), attacking a system that is off, to bypass other existing security mechanisms, in order to add malicious software or access protected data. Additionally, unless you’ve taken very extreme manual steps in setting up Secure Boot, signing keys from Microsoft, your hardware vendor, Fedora, and any signing keys you manually added (e.g. dkms/akmods driver signing keys) can all be used to sign things for secure boot. Microsoft has already had a few cases where malware was found to be signed with their keys just recently, and most hardware vendors are so terrible at security that they just use the same keys for almost everything and their private signing keys get leaked often.
So current Secure Boot implementation really only gives you protection in the very niche case of:
- You have other security protections against tampering/access (e.g full disk encryption)
- Your system is off
- The attacker has physical access to the system
- The attacker doesn’t have Microsoft or hardware vendor signed binaries
Most people rarely turn off their laptops anymore, usually just suspending/sleeping it instead, so requirement 2 usually isn’t met if requirement 3 is. Requirement 2 and 3 together means it’s not just a drive-by-hack in a coffee shop but a dedicated attacker that’s probably targeting you specifically, so they’re likely to have the tools that make requirement 4 invalid.
So keeping Secure Boot enabled directly blocks the use of hibernate in Fedora systems, a major necessary feature for most laptop users, in order to provide only an incomplete part of the mitigation of an incredibly niche threat.
Side note: As of Linux kernel 6.2 , only properly functioning TPM hardware is supported anymore. Unfortunately as of now, most TPM hardware is NOT properly functioning and has hardware design defects that make them non-compliant with the TPM standards and unsupported by Linux >=6.2. If you had a working pre-6.2 setup with Secure Boot enabled but one of these bad TPMs, and then upgrade to post-6.2, your system simply won’t boot past the initial grub menu while Secure Boot remains enabled. There is no fix except to either disable Secure Boot or replace the hardware (it’s a hardware design issue though, not a manufacturing issue).
So you’ll probably be forced to turn off Secure Boot on many laptops anyway, just so they can function at all.