Comment # 21 on bug 1173158 from Stefan Dirsch

(In reply to Martin Wilck from comment #19)
> (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).

Thanks for the comment. That's what I meant. ;-) 

> > > 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.

Thanks. That's what I already understood. But we don't guarantee kABI
compatibility on Leap. ;-)