https://bugzilla.suse.com/show_bug.cgi?id=1211224 https://bugzilla.suse.com/show_bug.cgi?id=1211224#c1 Joey Lee <jlee@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(sndirsch@suse.com | |) --- Comment #1 from Joey Lee <jlee@suse.com> --- Hi Stefan, Is it possible that NVIDIA RPM can use user's private key to sign kernel module? Then user can enroll their public key to db manually. Tumbleweed kernel will use keys in db to verify NVIDIA kernel module. Thanks! -- You are receiving this mail because: You are the assignee for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1211224 https://bugzilla.suse.com/show_bug.cgi?id=1211224#c6 --- Comment #6 from Andrei Borzenkov <arvidjaar@gmail.com> --- (In reply to Joey Lee from comment #0)

This issue is derived from boo#1211166. The openSUSE tumbleweed kernel can work with MOK for Nvidia KMP now. But in the dracut uefi_secureboot_cert case, it doesn't use shim, which means that MOK is not available.

How does Nvidia RPM works with dracut solution for modsign? Even when lockdown be enabled in kernel?

Does dracut uefi_secureboot_cert solution support dynamic local generated one time key? Nvidia KMP needs the solution.

Using dracut signed image requires complete replacement of the default certificates in BIOS with own certificates and relies on default firmware image validation. To use one time key corresponding certificate must be added to database. To do it the updated database must be signed by the private key used to generate unified kernel image. So this private key must be stored on the same system which is protected. So, "dracut uefi_secureboot_cert solution" does not care about any other key (one time or not) at all. The key to use when generating image by dracut is passed as parameter to dracut. The same key can of course be used to sign enrollment request for any other one time key. I have my reservations about storing key used to sign image on the same system where this image is verified. It is the same as writing password on a sticker on you monitor. But if the location where key is stored can itself be protected (let's say, on encrypted filesystem on on external security device like smart card) it could be considered. Of course it also means that it is impossible to access this key in unattended fashion. "Root only access" does not really protect anything. But that is not the problem unique to signing external modules, so if user trusts it to sign kernel itself, signing also external modules won't do more harm. The practical problem - I am not aware of a tool to add certificate to db directly. -- You are receiving this mail because: You are the assignee for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1211224 https://bugzilla.suse.com/show_bug.cgi?id=1211224#c20 --- Comment #20 from Stefan Dirsch <sndirsch@suse.com> --- (In reply to Ludwig Nussel from comment #19)

Let's drag the expert in. Maybe Bernhard can take a look. If we get the build reproducible we'd need some creative integration with the TW development process to make sure there's a new signature package for every snapshot. First things first though.

Later I noticed that I tested the build on a system with Secureboot enabled. So I compared kernel modules signed with different keys. So we can forget about this result. :-( -- You are receiving this mail because: You are the assignee for the bug.