On Tue, 19 Jan 2021 10:36:34 +0100, joeyli wrote:
Hi all,
In a discussion with Max Lin, he has mentioned that the KMP on OBS (e.g. virtual box) can not be loaded by closing-gap kernel. That makes sense because the kernel binary is from SLE.
For those KMP from SLE repo, the driver be signed by SLE key. It doesn't have problem to work with closing-gap kernel. But for those drivers from openSUSE Leap repo, they are signed by openSUSE key. The closing-gap kernel doesn't embed Leap kernel.
Maybe the openSUSE Leap pubic key must be included in all KMPs in Leap repo? or at least all KMPs in Leap repo must depend on a openSUSE Leap sign key RPM. After KMP be installed and reboot, user can follow MOK manager's UI to enroll openSUSE Leap key.
Any idea?
This has been discussed in the past, too, and an alternative is to embed the Leap cert in SLE kernel. It'd be the most user-friendly way, as user doesn't has to do anything new. And since it's a public key, it's fine to put the key even statically in the git branch. The kernel spec file has already an infrastructure to embed other keys. Of course, the obvious question is whether SUSE side accepts / prefers this. Other than that, the deployment via MOK would be the most feasible option, I guess, too. Maybe we can install a certain package containing the vert that is selected by install pattern or such. Or KMP may have dependency on a cert package as well. The biggest drawback of MOK approach is that it's quite non-intuitive; the dialog at shim is cryptic and novice users won't understand what to do. OTOH, we don't want (must not?) the unattended deployment. For avoiding misunderstanding, can YaST show the dialog at the end of the installer procedure, explaining what user has to do at the next step at the boot (at best with some pictures)? Or would it be just annoying / useless for most users? thanks, Takashi