#8 bad shim signature on Secure Boot
Opened 8 months ago by onursam. Modified 7 months ago

HP Elitedesk with secure boot enabled. Fedora running with default kernel just fine, but installing kernel-lqx and I get the following after reboot:

error: ../../grub-core/kern/efi/sb.c:151:bad shim signature.
error: ../../grub-core/loader/i386/efi/linux.c:208:you need to load the kernel first.

On COPR it says:
UEFI Secure Boot Compatible Kernel: The kernel image along with the modules are signed with the Red Hat Secure Boot CA, which can be registered to the EFI keystore to ensure system integrity
But Fedora seems to be using Fedora CA:

#  mokutil -l
[key 1]
SHA1 Fingerprint: 7e:68:65:1d:52:68:5f:7b:f5:8e:a0:1d:78:4d:2f:90:d3:f4:0f:0a
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2574709492 (0x9976f2f4)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Fedora Secure Boot CA
        Validity
            Not Before: Dec  7 16:25:54 2012 GMT
            Not After : Dec  5 16:25:54 2022 GMT
        Subject: CN=Fedora Secure Boot CA

I tried finding a source to install Red Hat CA for secure boot but couldn't find it anywhere.
It would be nice to provide the CA or instructions on how to get it or ideally, having it signed with Fedora key instead of Red Hat key (assuming they're not the same).


Metadata Update from @rmnscnce:
- Issue assigned to rmnscnce

8 months ago

Wait, so I didn't add the Red Hat CA into the installation, haha. Sorry for my sloppiness on the packaging. This will get sorted out soon on the next release (5.12.7 upstream)

Regarding the key, it is indeed different but it's named redhatsecureboot*.cer so I called it the Red Hat key

Please close this issue when it's solved

Just a heads up that it may be not the missing cert but the signed files
instead.

I tried putting redhatsecurebootca1.cer
to /usr/share/doc/kernel-keys/5.12.6-lqx2.3.fc34.x86_64/kernel-signing-ca.c=
er
but it didn't help, I got the same error at boot.

I'd been looking at the kernel.spec in Fedora 34 and it seems like it signs
the modules in addition to the kernel and also adds the certs to the system
trusted keys in *.config.

Modules signing on line 2156:
https://src.fedoraproject.org/rpms/kernel/blob/f34/f/kernel.spec#_2156
System trusted keys on line 1364:
https://src.fedoraproject.org/rpms/kernel/blob/f34/f/kernel.spec#_1364

Spec files look drastically different so I've got the feeling that
something like this may be missing (rather than just some files).

On Tue, 25 May 2021 at 15:56, =E1=85=9F pagure@pagure.io wrote:

rmnscnce added a new comment to an issue you are following:
``
Wait, so I didn't add the Red Hat CA into the installation, haha. Sorry
for my sloppiness on the packaging. This will get sorted out soon on the
next release (5.12.7 upstream)

Regarding the key, it is indeed different but it's named
redhatsecureboot*.cer so I called it the Red Hat key

Please close this issue when it's solved
``

To reply, visit the link below or just reply to this email
https://pagure.io/kernel-lqx/issue/8

After looking around possible fixes for this, I'll conclude that it's impossible to sign kernel images for secure boot on Copr builds due to the everchanging build chroots and impossibility to prepare the chroot for stuff like signing (it is possible, but not really recommended because if the keys are in the Copr it would just get exposed as an RPM source file)

I will remove the misleading "UEFI Secure Boot Compatible Kernel: The kernel image along with the modules are signed with the Red Hat Secure Boot CA, which can be registered to the EFI keystore to ensure system integrity" on the project page, at least until there's a way to distribute properly signed kernels

This issue will be closed immediately and tagged as REGR (for regression) and WONTFIX:LIMITS (for impossibility to fix due to limitations)
This issue will be open for the time it's possible to resolve it

Metadata Update from @rmnscnce:
- Issue status updated to: Closed (was: Open)

8 months ago

Metadata Update from @rmnscnce:
- Issue status updated to: Open (was: Closed)

8 months ago

I had been literally burning with this question and reading everything I could find about the Secure Boot process in Fedora and how to make it work.

Correct me if I'm wrong here:

1- shim is signed with Microsoft CA that is already in the firmware. Signing the shim is handled by Red Hat/Fedora.
2- shim includes the certs that verify the kernel AND modules.
3- the certs AND keys that were used to sign the kernel and modules are already available in fedora kernel git tree:

Source10: redhatsecurebootca5.cer
Source11: redhatsecurebootca1.cer
Source12: redhatsecureboot501.cer
Source13: redhatsecureboot301.cer

%define secureboot_ca_1 %{SOURCE10}
%define secureboot_ca_0 %{SOURCE11}
%ifarch x86_64 aarch64
%define secureboot_key_1 %{SOURCE12}
%define pesign_name_1 redhatsecureboot501
%define secureboot_key_0 %{SOURCE13}
%define pesign_name_0 redhatsecureboot301

4- The certs that are used for signing the kernels distibuted by Fedora are these very keys and they are already in the shim that was installed by Fedora, hence a successful boot.
5- (most important one) It's just a matter of making sure the exact certs (that are in the installed shim) are used to sign the kernel and modules so Secure Boot can verify the shim and shim can verify the kernel and modules. Right?

I had been literally burning with this question and reading everything I could find about the Secure Boot process in Fedora and how to make it work.

Correct me if I'm wrong here:

1- shim is signed with Microsoft CA that is already in the firmware. Signing the shim is handled by Red Hat/Fedora.

Yes, Red Hat handles the shim enrollment to Microsoft.

2- shim includes the certs that verify the kernel AND modules.

Yes, shim verifies the kernel and modules being loaded to match the included signature

3- the certs AND keys that were used to sign the kernel and modules are already available in fedora kernel git tree:

Source10: redhatsecurebootca5.cer
Source11: redhatsecurebootca1.cer
Source12: redhatsecureboot501.cer
Source13: redhatsecureboot301.cer

%define secureboot_ca_1 %{SOURCE10}
%define secureboot_ca_0 %{SOURCE11}
%ifarch x86_64 aarch64
%define secureboot_key_1 %{SOURCE12}
%define pesign_name_1 redhatsecureboot501
%define secureboot_key_0 %{SOURCE13}
%define pesign_name_0 redhatsecureboot301

Yep they're there and those are what I'm using to sign the builds

4- The certs that are used for signing the kernels distibuted by Fedora are these very keys and they are already in the shim that was installed by Fedora, hence a successful boot.

True

5- (most important one) It's just a matter of making sure the exact certs (that are in the installed shim) are used to sign the kernel and modules so Secure Boot can verify the shim and shim can verify the kernel and modules. Right?

Not really about making sure it's the same certs. The problem lies within the signing mechanism. We need Red Hat's private keys to properly sign the kernel. Those private keys are distributed within Red Hat's, CentOS', and Fedora's koji instances. You can see the here to see what I mean

I'm trying to find a way to add stuff like private keys secretly into Copr chroots so I can build signed kernels and you all can add the CA into the MOK.

Login to comment on this ticket.

Metadata