@Daniel "In either case, however, the CA that signs the kernel signing key needs to be built in to the kernel's .builtin_trusted_keys keyring."
On Ubuntu, for OPAL singing, on PowerPC, we do not use CA at all. It is our understanding that firmware doesn't support verifying signature chains to a CA. Thus instead we use self-signed certificates for the kernel which have not been signed by a CA. Thus we should simply include them all in trusted keyring, and there is no need to ship anything on disk or load anything from the userspace. We have UEFI CA which is used for UEFI booting and embedded in the UEFI shim, but I do not believe it is appropriate to use that CA here, as the revocations are controlled by a KEK key which has no relationship with POWER firmware vendors. @sforshee Subject: CN = Canonical Ltd. Live Patch Signing Subject: C = GB, ST = Isle of Man, L = Douglas, O = Canonical Ltd., OU = Secure Boot, CN = "Canonical Ltd. Secure Boot Signing (POWER, 2017)" Subject: C = GB, ST = Isle of Man, L = Douglas, O = Canonical Ltd., CN = Canonical Ltd. Kernel Module Signing This is all that's needed for now. However, we should start also shipping the next/future OPAL signing certificate that we have generated in 2019. Please add the 2019 opal signing certificate as debian/opal-2019-ppc64el.pem Key ID: 6B:E5:A1:25:FC:48:97:91:02:2C:2B:FB:54:91:16:F6:07:16:EA:81 There are no CA to add, and no keys to load from userspace. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1903288 Title: Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: New Bug description: == Comment: #2 - Daniel John Axtens <daniel.axte...@ibm.com> - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
