[cyphar]

> Can I ask one question? Why not use hibernation at that point?

Not GP but hibernation is completely disabled for lockdown kernels[1], which is always enabled when booting under secure boot for kernels trusted by the Microsoft secure boot keys (it is considered a requirement to get you shim signed by rhboot[2] as it is believed that Microsoft considers it a hard requirement, as otherwise you could chain-load a patched version of Windows under secure boot).

This doesn't matter for custom kernels but most official distro kernels are built this way to be signed, as otherwise they won't Just Work (TM) on modern laptops. If you disable secure boot then hibernation works again, though I must admit I'm a little surprised how many people seem to disable secure boot.

[1]: https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.... [2]: https://github.com/rhboot/shim-review#how-does-your-signed-k...

[assbuttbuttass]

> I must admit I'm a little surprised how many people seem to disable secure boot.

To me, secure boot is the setting that I need to remember to turn off before installing the OS, but I would be willing to be convinced otherwise

[cyphar]

To be fair the security argument for secure boot is weakened by the fact that everything is signed by the same set of trusted keys when using the default Microsoft trust root, but on paper it does protect against certain kinds of attacks. (In theory, distros could use UEFI setup mode to only trust their own keys but this causes issues with signed firmware and there have been cases of bricked devices.)

Even if you use full disk encryption, without secure boot someone can replace your kernel (or bootloader to inject a bad kernel) with one that is backdoored without you noticing. So someone only needs temporary access to your powered off laptop to gain access to your data once you use it again. I've had my devices taken away from me at airports and I know people who have had their laptops mysteriously missing screws when travelling overseas, so this is not an entirely hypothetical problem.

Of course, the fact that hibernation doesn't work on Linux is a negative from a practical security perspective, and so stuff like luksSuspend on suspend end up being quite important. And trusting the Microsoft keys is a little concerning if you're worried about state actors.

If you use TPM-backed keys with tools like systemd-pcrlock you can get some similar (and arguably nicer) protections but in practice nobody locks to enough PCRs to provide more protection than you would get if you also enabled secure boot.

[kokada]

> Not GP but hibernation is completely disabled for lockdown kernels[1]

The manpage that you linked says that unencrypted hibernation/suspend is disabled, but this seems a bad idea anyway if you're using FDE.

[cyphar]

The man page does say that but there is no mechanism to actually make use of that at the moment.

It's not enough for it to be encrypted, it needs to be encrypted with a single-purpose key that is not known by the user. Otherwise the user could replace the hibernation image with a malicious one and chain-load a backdoored version of Windows in secure boot mode, which violates the security model that Windows has and Linux needs to uphold to continue to get signed by Microsoft.

It is my understanding that there is work on generating a non-exportable single-purpose key using the TPM to make this work, but that's still a WIP.

[kokada]

> which violates the security model that Windows has and Linux needs to uphold to continue to get signed by Microsoft.

Oh ok, thanks for clarifying why this is a thing.