On Tue, Jan 19, 2021 at 12:20:19PM +0100, Takashi Iwai wrote:
On Tue, 19 Jan 2021 10:36:34 +0100,
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.
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
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.
The biggest drawback of MOK approach is that it's
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!