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

[bluca]

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]

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]

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

[julian-klode]

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]

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.