[Operative0198]

For secureboot you may want to took a look at this project [0]. Don't think it has ever gotten easier to sign UKIs than that though systemd should have a new project (systemd-ukify) that aims to make it more integrated.

Hiberation is not supported in lockdown mode because I'm assuming the kernel (maintainers) expect most people to have an unencrypted swap partition. If you have secured your swap, you can patch [1] the kernel to allow hibernation.

[0] https://github.com/Foxboron/sbctl

[1] https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1...

[Nursie]

Thanks, yeah I think I came across sbctl when I was playing around with it. Haven't tried it yet... it got a little confusing when I was reading various guides to try to achieve what I've been trying to achieve, and they started referring to various different tool sets!

I'll have a go with it to enroll some keys and see if they persist. mokutil, and then rebooting into shim to persist them, has failed me. It all seems to go OK and then they're just not there on the next boot.

On hibernation, that makes sense. I hadn't read into the reasoning, just got as far as "MS allows it in secure boot mode, linux devs consider it insecure by design" or some such thing.

[Operative0198]

You don't need any other tools sets when using sbctl to enroll and sign your keys. It's a one-stop shop for creating UKI bundles and signing them. I use systemd-boot with UKIs created by it and it has no issues detecting the UKIs. Maybe your problem is holding on to grub(legacyware IMO) which has poor support for what you are trying to accomplish.

Hibernation support in lockdown has nothing do with the MS politics around secure boot. You can generate and use your own keys to use with secureboot. The issue is that "accessible" unencrypted hibernation files invalidate secureboot when you can break into RAM and modify system images/files.

[Nursie]

> Maybe your problem is holding on to grub(legacyware IMO)

My problem is that I can't enroll keys, going through the enroll procedure (which doesn't involve grub) results in ... nothing.

I'm not specifically wedded to grub, and a UKI signed with a key is a fine idea if I can get a key installed. As such, I'll try sbctl but I have no particular reason to think it will work where shim/mokmanager fail if there's a motherboard issue of some sort.

There may well be challenges using grub down the line, but right now I'm not even getting far enough for that to be an issue.

[patrakov]

It is not because of an unencrypted swap partition. It is because, even if it is encrypted, you know the key and can thus replace the image with an arbitrary modified one, or, in theory, with a hacked version of a Windows boot loader, which would break DRM.

There were some movements to remove this restriction, on the condition that the encryption key is properly sealed in the TPM and is not extractable.

[Operative0198]

Except you'd have to know the encryption passphrase to unlock the swap partition. Only after this step can you use the stolen key to manipulate the state of trusted images.

TPM has never been a pre-requisite for secureboot nor kernel_lockdown. Infact the proposal you are speaking of sounds very exclusionary since TPM hardware is still relatively new and not ubiqitous.

[patrakov]

Correct. But you do know the passphrase, and, from the viewpoint of Secure Boot and the locked-down kernel, you (the legitimate owner) are also the attacker who tries to run some unapproved kernel-mode code and will stop at nothing in order to do that.