On Fri, Mar 24, 2023 at 06:01:36PM +0800, joeyli via openSUSE Factory wrote:
Hi Joe,
Sorry for my delay!
On Fri, Mar 10, 2023 at 03:17:19PM -0000, Joe Salmeri wrote:
Hi Joey,
Is there a way we can have Secure Boot, kernel lockdown enabled, BUT still have the ability to generate our own key, compile and sign modules with that key, mokutil --import and enroll the key during reboot, and have the kernel load the modules signed with our key?
If that is possible, then it sounds like that would resolve all the complaints from the users I have talked too.
It would certainly work for my use case which involves compiling the vmware vmmon and vmnet kernel modules.
I didn't port KEYS-Make-use-of-platform-keyring-for-module- signatu.patch patch to Tumbleweed kernel. We need this patch >> to allow .platform (db and mok) keyring be used to verify kernel module. Otherwise we will need shim v15.5 and later. But now we only have MS-signed shim 15.4 for Tumbleweed.
If that patch had been ported, would that have provided what I asked in my first question?
Yes, we put a downstream patch KEYS-Make-use-of-platform-keyring-for-module-signatu.patch to SLE/Leap kernel then MOK can be used to verify kernel module. Actually almost all big distros included similar patch, except Tumbleweed.
Currently it's still a gap between upstream kernel with distros. Kernel community is working on this:
Newest patch set: [PATCH v5 0/6] Add CA enforcement keyring restrictions https://lore.kernel.org/lkml/20230302164652.83571-1-eric.snowberg@oracle.com...
Which is completely irrelevant for usability of MOK keys in the distribution if not outright harmful. So long as upstream does not implement key management that is usable in a general purpose distribution we do need downstream patches, and there is no indication that upstream is heading in that direction. Thanks Michal