search

rhboot / shim

UEFI shim loader
Other
816 stars 284 forks source link

RFE: add protocol to let 2nd/3rd stage loaders append ephemerally to MokListRT #574

Open bluca opened 1 year ago

bluca commented 1 year ago

These days MokListRT certificates are consumed by the kernel and added to the machine keyring, which can be linked into the secondary keyring, which allows using those certificates, among other things, for verifying kernel modules and dm-verity images.

We'd like to extend UKIs with a .keyring section. As part of the UKI, it would be covered by the UKI's signature. systemd-stub would parse this new section, and append the content to the Mok variable that is read by the kernel.

It was mentioned by @vathpela that the preference would be to add a new protocol for this, rather than letting other stages simply write directly to the variable, due to concerns with variable sizes, even when they are volatile.

julian-klode commented 1 year ago

I feel like it would make more sense to extend vendor db or something? We already have the certmule thingy from @jsetje, I feel like this basically turns every binary loaded into a certmule too

bluca commented 1 year ago

Is that picked up by the kernel for the machine keyring?

julian-klode commented 1 year ago

Even upstream kernel reads the db, I don't know if everyone reads the dbx yet.

Regardless, the UKI keyring would not be machine-owner controlled, so it shouldn't be in the machine-owner-key list?

bluca commented 1 year ago

As long as the key turns up in a keyring linked into the kernel primary or secondary keyrings, and thus it can be used to verify dm-verity and so on, I don't mind which variable is used.