Support linux keyring for kernel module signing

[Foxboron]

Heftig is probably adding support for loading UEFI keys into the Linux keyring when secure boot is enabled. This allows us to use the db key for kernel module signing which is handy if you are using lockdown=confidentialy and dkms modules needs to be signed by a trusted key.

https://bbs.archlinux.org/viewtopic.php?pid=1861193#p1861193

I think sbctl should have some support to sign kernel modules by path, or by name. And also verify that the keyring has the UEFI certificate loaded.

[savchenko]

Isn't this important for lockdown=integrity in the equal measure?.. Which is the default when SB is enabled.

[Foxboron]

I don't think integrity disallows loading of unsigned modules, so not as important I reckon. I'm unsure if the UEFI keys gets loaded into the keyring with ìntegrity and confidentiality. But I'd guess so.

I displaced the documentation I had up yesterday :D But I should build a kernel and try this out :)

[savchenko]

I believe it does: lkrg-org/lkrg#27

Is there anything that would benefit from an additional testing? Happy to help.

[Foxboron]

There is nothing to test yet I believe. I'll try write a separate go library for kernel module signing and see if that works first. Then I'll work on some integration with sbctl.

If you have any ideas, requirements or wants for the command line design please do tell me. I'll poke you once I have some code available :) Thanks!

(Hit the close button by accident :))

[Foxboron]

I was wrong :/

Turns out this was possible, but the kernel seperated the UEFI keys into the .platform keyring which the modules does not verify against.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.0.y&id=9dc92c45177ab70e20ae94baa2f2e558da63a9c7

Fedora/RedHat carries patches that adds the platform keyring for kernel module signing, but this as been rejected upstream.

https://lore.kernel.org/lkml/20190425182134.GA7823@laptop.jcline.org/T/

Regardless I have patched the x509 cert code to create certificates the kernel accepts. a6445c4

This was fairly disappointing

[Foxboron]

Seems like there is some movement upstream to have MokTrustPlatform tell the kernel if the secure boot keys should be trusted or not. I'm annoyed that a lot of this functionality is gated behind the shim.

https://patchwork.kernel.org/project/keyrings/patch/20210517225714.498032-2-eric.snowberg@oracle.com/

[swsnr]

That'd be a great feature to have; missing signatures for the virtualbox modules are the one reason I have to disable lockdown=integrty on some of my systems 🙂

[Foxboron]

After reading up on the patches I think we can get this to work using sbctl with this workflow.

• Create and set MokListTrustedRT to 1
• Write our keys to MokListRT

And then we can implement kernel module signing with sbctl with kernel 5.18. If the patches do get accepted.

[Klaus327]

The patches you mentioned above found the way to the kernel meanwhile. Do you now plan to add the feature to save the keys to MokListRT?

[Foxboron]

"Yes", but the issue is that the MOK variables are read from the EFI configuration table setup by shim. So without the shim software in your bootchain the kernel is going to ignore the values regardless.

[Klaus327]

You're right - I ignored the MOK / shim issue. This is knocking out systemd-boot which operates w/o shim - what a pity. Maybe it's even better to have different keys for module signing and UEFI secure boot.
Thanks for your work!

[Foxboron]

The issue is that there is only two ways to load a trusted key into the Linux keyring. Include one at build-time or use the patch series above. There is no other way currently.

[medhefgo]

Well, this is silly. Considering systemd/systemd#20255 has landed now, it could be extended to also enroll a MOK for these kind of cases…

[Foxboron]

You would still need to have the shim there, unless you have sd-boot setup the EFI configuration table :)

I wanted to mention it at some point, but it's a bit hard to know when it was relevant information.

[medhefgo]

You would still need to have the shim there, unless you have sd-boot setup the EFI configuration table :)

The idea would be that for this pseudo-shim support, you'd rely on the custom keys (and MOK) to be in the secure boot db and additionally add the MOK-related vars. Then you'd not have to implement any of the hackery that shim does, as afaik it does not provide any UEFI runtime APIs to the kernel (and the kernel stub afaik doesn't need any of the shim boot services either).

[Foxboron]

Mm, the kernel refuses to read the MOK variables unless they are present in the EFI configuration table. So you would need some shim hackery? Am I misunderstanding something? Simply adding the MOK variables is not enough as stated earlier in this issue.

[medhefgo]

Mm, the kernel refuses to read the MOK variables unless they are present in the EFI configuration table.

I see. But installing the MOK key store should be a simple operation that doesn't need hackery (as the UEFI API provides this for us).

[Foxboron]

Sure, that would be fine I believe. But be aware that it doesn't really do anything on it's own without the shim.

[medhefgo]

But that's the idea, no? Provide a MOK store so that the user can give the kernel a trusted key for kernel module signing, while relying on the regular UEFI secure boot key store (probably without the MOK in it) with custom keys managed by sbctl for boot security.

(If you haven't noticed, I hate shim. It's such an incredibly ugly and hacky solution and should be avoided as much as possible.)

[Foxboron]

But that's the idea, no? Provide a MOK store so that the user can give the kernel a trusted key for kernel module signing, while relying on the regular UEFI secure boot key store (probably without the MOK in it) with custom keys managed by sbctl for boot security.

I'm fumbling a bit because it's hard to go from implementation details to see the big-picture :)

(If you haven't noticed, I hate shim. It's such an incredibly ugly and hacky solution and should be avoided as much as possible.)

Which is fine and I somewhat agree, but it's important to realize that the current assumptions from people writing the kernel code, and people working on Secure Boot in Linux distros, regard the shim as the main component in all of this. Moving away from it is hard :/

[Grafcube]

Is there an update or workaround for this issue? I'm not able to load v4l2loopback without disabling secure boot on my device.

[Foxboron]

You need to use the shim and load the db key into the MOKList.

This isn't something sbctl is going to support without a shim/MOK mode or setup awareness.

[Grafcube]

You need to use the shim and load the db key into the MOKList.

Sorry but I don't know what that means. For my setup I generated bundles for each boot entry and put them in /boot/EFI/Linux.