Comment # 19 on bug 1173158 from Martin Wilck

(In reply to Stefan Dirsch from comment #18)
> > It's indeed not easy. We could use a key stored in a standard location on
> > the user's system. However, at the very least the build procedure should
> > allow to enter the pass phrase for the key in a secure manner. Otherwise the
> > secret key would need to be stored unencrypted on the target system, which
> > would forfeit the use of secure boot, or a locked-down kernel, almost
> > entirely.
> 
> I haven't looked deeper into this, but this were my first thoughts as well.
> I think the idea was to sign the module with the first boot after installing
> it in a still to be developed interactive mode. Technical ideas. No idea. 

You can't sign the module during boot. All you can do is enroll the key with
which the module was signed into MOK. The signature must be made while the
module is built, or thereafter. Once the key is enrolled, and you always sign
self-build modules with the same key, you don't need to enroll again (but you
must sign every single .ko file you build).

> > Alternatively, there could be a way to transform the Nvidia pseudo-KMP into
> > a real KMP *by the user*. The user could run this procedure on some
> > particularly protected system, and distribute the generated KMP plus the
> > associated cert to the systems in his data center.
> 
> Which then may break with the first kernel update. Yes, a kernel update
> triggers a rebuild and reinstallation of the module.

I didn't make myself clear. That "real KMP" I talked about would not trigger
the rebuild. It would rather rely on KABI, like real KMPs do. If the KABI
changes, the "real KMP" would need to be rebuilt. I'd hope that wouldn't happen
too often, at least not on Leap.