key enrollment on non-EFI systems for `module.sig_enforce=1` kernel parameter

[adrelanos]

key enrollment on non-EFI systems for `module.sig_enforce=1` kernel parameter

[evelikov]

From my casual reading at the kernel documentation, you should be able to add any x509 as builtin_trusted_keys via keyctl. That said I haven't tried it and I'm not sure if it makes sense to automate in dkms.

If anything, I'm more inclined to remove all the ad-hoc module install/signing and use the upstream Kbuild to do that for us. Although this is more of a pie in the sky idea currently.

If you have a compelling reason why it has to be done by dkms, I won't mind reviewing a PR.

[evelikov]

Actually on second read, I noticed this:

Note, however, that the kernel will only permit keys to be added to .builtin_trusted_keys if the new key's X.509 wrapper is validly signed by a key that is already resident in the .builtin_trusted_keys at the time the key was added.

So I guess, it might not be possible since we don't sign the key we generate as required.

[evelikov]

Reading through the docs, a few days later, it seem that you can either reuse the key used during the initial build to sign the dkms build modules. Or the original key must be used to sign the dkms generated key - in that case the new key must be added to the kernel via keyctl.

Distributions don't ship the key - understandably - so the only way for things to work is to rebuild the kernel. At this point, you can proceed with reusing it or creating/signing another key for dkms modules. Don't think such functionality belongs in dkms.

If my understanding is off, please correct me. Similarly if there is some reason why this should belong in dkms.