I’ve made the effort to secure mine and am aware of how the trusted protection module works with keys, Fedora’s Anaconda system, the shim, etc. I’ve seen where some here have mentioned they do not care or enable secure boot. Out of open minded curiosity for questioning my biases, I would like to know if there is anything I’ve overlooked or never heard of. Are you hashing and reflashing with a CH341/Rπ/etc, or is there some other strategy like super serious network isolation?
This is patently false. Secure boot and hibernation are not mutually exclusive.
Not mutually exclusive, but it’s highly probable that if you’re running a mainstream distro, the default kernel is in lockdown mode, preventing hibernation while secure boot is enabled.
On Linux there have been some challenges. Lockdown mode and hibernation don’t play nice. This isn’t to do with secure boot (you can also disable lockdown mode individually) but to prevent kernel access to processes that can edit the hibernation image last-minute (to bypass SELinux, for instance, which shouldn’t be possible even as root), lockdown mode has prevented hibernation for the longest time. I don’t know if it’s been fixed yet, it’s been a while since I last checked.
Disabling secure boot makes the kernel go “whelp, looks like there’s no way to secure the boot process anyway” and will disable lockdown mode by default. If your device is free from other lockdown mode issues, this’ll seem to turn secure boot into a lockdown mode toggle, even though it’s just a side effect.
While I believe you, I haven’t been able to enable hibernation with it on.
It’s a kernel build config. Debian for ships with support disabled due to security concerns.
So I’d have to rebuild the kernel, not just provide a kernel argument? That’s definitely not a step I’m ready for.
Correct