Hi Takashi, On Tue, Jan 19, 2021 at 12:20:19PM +0100, Takashi Iwai wrote:
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.
Yes, this is the most user-friendly way. And this approach is also benefit to no-EFI/MOK machines. As you said, SUSE side should accepts. I believe that SLE product manager and security team should accept at least. In a conversation in labs conf, I raised an idea to embed PTF or PLDP cert to SLE kernel. But a SLE partner disagrees because end user should awares and accepts which key they will trust. If Leap key be embedded in SLE kernel, it means that SLE user also trusts Leap key by default. To SLE user, this is a unnecessary risk.
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.
Yes.
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?
I am not sure how many effort on YaST team, but I think that's a good idea. Comparing with EFI text UI, a YaST step with picture can bring more detail to user. Thanks a lot! Joey Lee