On Wed, 20 Jan 2021 09:32:06 +0100, Marcus Meissner wrote:
On Wed, Jan 20, 2021 at 04:27:00PM +0800, joeyli wrote:
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.
No, Security does NOT accept embedding openSUSE certs by default in SLE kernels.
This would break our primary security certification Common Criteria and also other assurance, especially as also non-SUSE employees are now able to work directly on Leap.
Thank you for clarification. It's more or less expected, but we had to discuss this publicly once, in anyway.
Some other form of enrollment needs to be considered or e.g. that all KMPs are built in SLES.
Hmm, I don't think it's a good idea. It doesn't scale, and would just bring more burden to both SUSE and openSUSE contributors. The MOK enrollment itself is an easy action, and once after we have some automatic cert installation via a package chain, the only remaining problem is the UI, IMO. We need to improve the dialog in shim itself and/or provide more guidance at installation. thanks, Takashi