Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
bad shim signature; you need to load the kernel first.
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
incman
n00b
n00b


Joined: 14 May 2024
Posts: 7
Location: Ishikawa, Japan

PostPosted: Tue May 14, 2024 1:23 pm    Post subject: bad shim signature; you need to load the kernel first. Reply with quote

I installed Gentoo Linux on a Fujitsu Esprimo Q556/M. There are no problems with normal booting.
I want to enhance security by enabling Secure Boot. Therefore, I followed the instructions here to set up Secure Boot:
https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Optional:_Secure_Boot

When I set the BIOS to Secure Boot and started the system, the shim started and grub also loaded, but at the kernel loading stage, the following error appeared:
Quote:
bad shim signature
you need to load the kernel first

I was unable to load the Linux kernel.

The following is some reference information.
I am using a distribution kernel. Although I am using a signed distribution kernel, I did not use the certificates in /usr/src/linux-x.y.z/certs because I did not understand how to use them.

I tried the following but got the same result:
I tried registering the certificate with the command
Code:
mokutil --import /usr/src/linux-6.6.30-gentoo-dist/certs/signing_key.x509

thinking it might be necessary to register it in the MOKLIST, but I received the response:
Quote:
Already in kernel trusted keyring. Skip signing_key.x509

Additionally, I do not understand why I am getting a "bad shim signature" error, even though the shim (including mmx64.efi) and the signed grub have started.
If this error means that the Linux kernel to be loaded is not signed, then it would be understandable.
Back to top
View user's profile Send private message
AndrewAmmerlaan
Developer
Developer


Joined: 25 Jun 2014
Posts: 299
Location: Nijmegen

PostPosted: Wed May 15, 2024 9:44 pm    Post subject: Reply with quote

You are indeed missing the certificate in the MOKlist, mokutil --import says that the kernel already trusts they key. This makes sense since this key was built into the kernel image and is therefore trusted by default. Now you need shim to trust the key as well. mokutil has some option you can pass it to ignore the key ring from the kernel and import the key anyway, I forgot what the exact name was of that option but it should be in the manual somewhere.
_________________
OS: Gentoo 6.8.10-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
incman
n00b
n00b


Joined: 14 May 2024
Posts: 7
Location: Ishikawa, Japan

PostPosted: Fri May 17, 2024 4:29 pm    Post subject: Reply with quote

I executed man mokutil to check the manual. I found the --ignore-keyring option to be relevant. After running the following commands:

Code:
openssl x509 -in /usr/src/linux-6.8.9-dist/certs/signing_key.x509 -out /root/signing_key.der --outform DER

Code:
mokutil --import /root/signing_key.der --ignore-keyring

I was able to add the key to the MOKlist without using the keyring.

Then, I enabled Secure Boot, set shim as the primary bootloader, and tried to load the Linux kernel via grub, but I still encountered the same error....


At this point, I had a realization. Upon rereading the grub error message carefully, I noticed that the error:

Quote:
bad shim signature.

occurs when attempting to load the Linux kernel, and the error:

Quote:
you need to load the kernel first

occurs when trying to load the initramfs. This means that the second error indicates that the kernel must be loaded before the initramfs.

Therefore, it seems that while grub as the secondary bootloader is loading correctly, there is an issue with the signature when loading the Linux kernel.
Back to top
View user's profile Send private message
AndrewAmmerlaan
Developer
Developer


Joined: 25 Jun 2014
Posts: 299
Location: Nijmegen

PostPosted: Fri May 17, 2024 4:34 pm    Post subject: Reply with quote

Could you show us the output of 'sbverify --cert /path/to/your/certificiate /path/to/your/kernel'?
_________________
OS: Gentoo 6.8.10-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
incman
n00b
n00b


Joined: 14 May 2024
Posts: 7
Location: Ishikawa, Japan

PostPosted: Sat May 18, 2024 7:26 am    Post subject: Reply with quote

Since sbverify only accepts PEM format, I first converted the certificate to PEM format using the following command:

Code:
openssl x509 -in /usr/src/linux-6.8.9-gentoo-dist/certs/signing_key.x509 -out /root/secure_boot/signing_key.pem --outform PEM

Then, I performed the verification using the following command:

Code:
sbverify --cert /root/signing_key.pem /boot/vmlinuz-6.8.9-gentoo-dist


The result was that there were no problems.
Quote:
Signature verification OK
Back to top
View user's profile Send private message
AndrewAmmerlaan
Developer
Developer


Joined: 25 Jun 2014
Posts: 299
Location: Nijmegen

PostPosted: Sat May 18, 2024 7:55 am    Post subject: Reply with quote

Strange, it should work then.

A couple of things you could double check:
- Is the kernel you are trying to boot actualy the kernel you think it is (maybe grub is booting the wrong kernel)?
- Whats the expiry date on your keys? I'm not sure if this is actually checked at runtime, but maybe it is and maybe the key is expired.
- Try 'sbverify --list', there might be multiple signatures and maybe only the first or last is checked.
- Try again with a new key
_________________
OS: Gentoo 6.8.10-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
incman
n00b
n00b


Joined: 14 May 2024
Posts: 7
Location: Ishikawa, Japan

PostPosted: Sat May 18, 2024 1:26 pm    Post subject: Reply with quote

-There were two kernels and their related files in the boot directory: `vmlinuz-6.6.30-gentoo-dist` and `vmlinuz-6.8.9-gentoo-dist`. I used `eclean-kernel` to remove the older kernel.

-Upon checking the expiration dates, I found the following:

Code:
[/efi/.../gentoo]: openssl x509 -noout -dates -in /root/secure_boot/kernel_key.pem
notBefore=May 13 14:05:07 2024 GMT
notAfter=Jun 12 14:05:07 2024 GMT

[/efi/.../gentoo]: openssl x509 -noout -dates -in /usr/src/linux-6.8.9-gentoo-dist/certs/signing_key.x509
notBefore=Aug 26 09:04:17 2023 GMT
notAfter=Aug 2 09:04:17 2123 GMT

kernel_key.pem is the key and certificate I generated recently, while signing_key.x509 is a certificate file included with the distribution kernel stored in `/usr/src/linux-6.8.9-gentoo-dist/certs/`.

-The result of running the `sbverify --list` command was somewhat puzzling to me:

Code:
[/efi/.../gentoo]: sbverify --list
Usage: sbverify [options] --cert <certfile> <efi-boot-image>
Verify a UEFI secure boot image.

Options:
--cert <certfile>  certificate (x509 certificate)
--list             list all signatures (but don't verify)
--detached <file>  read signature from <file>, instead of looking for an embedded signature

Quote:
Verify a UEFI secure boot image.

Only this message was output, without any information about which keys are registered. This might indicate that there is something wrong with my setup process.

-I have decided to reconfigure Secure Boot. I will report back on this.
Back to top
View user's profile Send private message
AndrewAmmerlaan
Developer
Developer


Joined: 25 Jun 2014
Posts: 299
Location: Nijmegen

PostPosted: Sat May 18, 2024 2:04 pm    Post subject: Reply with quote

Quote:
Only this message was output, without any information about which keys are registered. This might indicate that there is something wrong with my setup process.


Sorry, that's my fault, it needs the efi file (i.e. the kernel) you want to list the signatures for as the second argumment
_________________
OS: Gentoo 6.8.10-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
incman
n00b
n00b


Joined: 14 May 2024
Posts: 7
Location: Ishikawa, Japan

PostPosted: Sat May 18, 2024 2:25 pm    Post subject: Reply with quote

I decided to start over and regenerate the keys. The kernel is the distribution kernel (sys-kernel/gentoo-kernel-bin) and should be signed. I followed the instructions here to regenerate the keys:
https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Optional:_Signed_kernel_modules

Code:
mkdir -p /root/secure_boot
cd /root/secure_boot
openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem
chown root: /root/secure_boot/kernel_key.pem
chmod 400 /root/secure_boot/kernel_key.pem

I ignored the description regarding /etc/portage/make.conf in this case.

For the installation of shim and Grub, I followed the instructions in the following manual:
https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Optional:_Secure_Boot

Code:
export GRUB_MODULES="all_video boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gettext gfxmenu gfxterm gfxterm_background gzio halt help hfsplus iso9660 jpeg keystatus loadenv loopback linux ls lsefi lsefimmap lsefisystab lssal memdisk minicmd normal ntfs part_apple part_msdos part_gpt password_pbkdf2 png probe reboot regexp search search_fs_uuid search_fs_file search_label sleep smbios squash4 test true video xfs zfs zfscrypt zfsinfo"
grub-install --target=x86_64-efi --efi-directory=/efi --modules="${GRUB_MODULES}" --sbat /usr/share/grub/sbat.csv

I signed Grub with the generated key as follows, and no errors occurred:

Code:
sbsign /efi/EFI/gentoo/grubx64.efi --key /root/secure_boot/kernel_key.pem --cert /root/secure_boot/kernel_key.pem --out /efi/EFI/gentoo/grubx64.efi

Next, I copied the primary bootloader (shim) and the fallback menu screen (mmx64) in case of issues with shim:

Code:
cp /usr/share/shim/BOOTX64.EFI /efi/EFI/Gentoo/shimx64.efi
cp /usr/share/shim/mmx64.efi /efi/EFI/Gentoo/mmx64.efi

Since the Grub signature was generated by me, it needs to be added to the MOKlist (otherwise, shim won't boot Grub).
I created the key and certificate in PEM format, but since mokutil only accepts DER format, I converted them:

Code:
openssl x509 -in /root/secure_boot/kernel_key.pem -inform PEM -out /root/secure_boot/kernel_key.der -outform DER

I then loaded the converted DER format certificate into mokutil:

Code:
mokutil --import /root/secure_boot/kernel_key.der

This registered the Grub certificate, so I understand why it can boot up to Grub. The issue now is that an error occurs when the kernel is loaded. Although not mentioned in the manual (which I find questionable), I forcefully registered the x509 certificate in DER format with mokutil in the same way as above:

Code:
openssl x509 -in /usr/src/linux-6.8.9-gentoo-dist/certs/signing_key.x509 -out /root/secure_boot/signing_key.der -outform DER
mokutil --import /root/secure_boot/signing_key.der --ignore-keyring

You will be prompted for a password, which you need to enter twice for confirmation.

Finally, I created the entry with efibootmgr:

Code:
efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\gentoo\shimx64.efi' --label 'secure gentoo' --unicode

These are all the steps I redid. I didn't touch anything else. When I changed the BIOS settings to enable Secure Boot and rebooted, the mmx64 screen appeared at about half the size of the display. The boot process continued, and GRUB did start. However, the borders of the GRUB screen were garbled (this has been happening since I enabled Secure Boot).

The problem remains that when loading the Linux kernel, I still get a "bad shim signature" error, and the kernel does not load.(OMG)

After writing out the process, I am still unsure about how the signed distribution kernel's signature information is supposed to be registered in the MOKlist. It might be that this registration is done during the kernel installation stage, but I have not yet confirmed this.
Back to top
View user's profile Send private message
incman
n00b
n00b


Joined: 14 May 2024
Posts: 7
Location: Ishikawa, Japan

PostPosted: Sat May 18, 2024 2:48 pm    Post subject: Reply with quote

Thank you for the correction report. Here are the output results as follows.

Code:
sbverify --list /boot/vmlinuz-6.8.9-gentoo-dist
signature 1
image signature issuers:
- /O=Gentoo Linux/CN=Distribution Kernel Signing Key/emailAddress=dist-kernel@gentoo.org
image signature certificates:
- subject: /O=Gentoo Linux/CN=Distribution Kernel Signing Key/emailAddress=dist-kernel@gentoo.org
   issuer:  /O=Gentoo Linux/CN=Distribution Kernel Signing Key/emailAddress=dist-kernel@gentoo.org


Code:
sbverify --list /efi/EFI/gentoo/shimx64.efi
warning: data remaining[823272 vs 949424]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root


I'm concerned about the warning regarding the signature of shimx64.efi. However, I haven't made any changes to this file other than renaming it, so I don't understand the cause of this issue.

In addition, I signed grubx64.efi using a key and certificate that I created myself, so there is also a signature for grubx64.efi (I won't include it here as it contains personal information).

If these three signatures are not registered in the MOK list, the boot process should not proceed. However, I am unable to interpret efivar, so I cannot confirm whether these three certificates are registered in the MOK list.
Back to top
View user's profile Send private message
AndrewAmmerlaan
Developer
Developer


Joined: 25 Jun 2014
Posts: 299
Location: Nijmegen

PostPosted: Sat May 18, 2024 4:11 pm    Post subject: Reply with quote

Quote:
If these three signatures are not registered in the MOK list, the boot process should not proceed. However, I am unable to interpret efivar, so I cannot confirm whether these three certificates are registered in the MOK list.


This information you can find with: mokutil --list-enrolled

Just to double check, before enabling secureboot, did you reboot after running mokutil --import? Note that mokutil --import by itself does not import anything, it registers an import request in efivars, after reboot shim will find this request and it should prompt for the password you entered to proceed with actually importing the key.

The issue you're having with the grub display may indicate that some module you usually have is not included in the built grub efi binary. Grub might have some way to list all loaded modules when secureboot is disabled, this could give you some inidcation on what you need to include for your system.
_________________
OS: Gentoo 6.8.10-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
incman
n00b
n00b


Joined: 14 May 2024
Posts: 7
Location: Ishikawa, Japan

PostPosted: Sat May 18, 2024 7:57 pm    Post subject: Reply with quote

Quote:
Just to double check, before enabling secureboot, did you reboot after running mokutil --import? Note that mokutil --import by itself does not import anything, it registers an import request in efivars, after reboot shim will find this request and it should prompt for the password you entered to proceed with actually importing the key.


No, I did not reboot after running mokutil --import.This was a complete oversight on my part. I assumed that running mokutil --import would immediately enroll the key in the MOK list.

Every time I enabled Secure Boot and rebooted, I found it strange that the mmx64.efi menu screen appeared just once. Carelessly, I thought this was because the kernel certificate was not registered and I overlooked it.

After running mokutil --import again and rebooting, the mmx64.efi menu screen appeared. Reading it carefully, I realized it was prompting me to enroll the key. I was asked whether to enroll two keys: the Linux kernel certificate and the key I created. When I approved enrolling both, GRUB started, and the Linux kernel was successfully loaded, and I managed to boot into Gentoo!!!

As far as I can tell, the Gentoo manual does not mention that you need to reboot after running mokutil --import and that you need to enroll the key in the mmx64.efi menu screen. This is a confusing point, and if anyone encounters the "bad shim signature" error while setting up Secure Boot, I strongly advise them to reboot first and enroll the key in the mmx64.efi menu screen.

Lastly, I want to express my deep gratitude to Mr. AndrewAmmerlaan for his persistent and patient advice. Thank you very much!!!!!!
Back to top
View user's profile Send private message
AndrewAmmerlaan
Developer
Developer


Joined: 25 Jun 2014
Posts: 299
Location: Nijmegen

PostPosted: Sun May 19, 2024 8:23 am    Post subject: Reply with quote

Awesome, great to hear that it works now.

Quote:
As far as I can tell, the Gentoo manual does not mention that you need to reboot after running mokutil --import and that you need to enroll the key in the mmx64.efi menu screen. This is a confusing point, and if anyone encounters the "bad shim signature" error while setting up Secure Boot, I strongly advise them to reboot first and enroll the key in the mmx64.efi menu screen.


I added some notes to the handbook to clarify that the import process is not completed until the system is rebooted and that "--ignore-keyring" may be required if the kernel has the certificate already built into its keyring.
_________________
OS: Gentoo 6.8.10-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum