0

I have an laptop running 20.04 (no secure-boot, title it old). I wanted to move the boot disk to a new laptop (titled new) which has secure-boot enabled. I do not want to disable secure boot on new, because I have windows installed on new with requirements to keep secure boot enabled.

To test whether this was possible for new, I plugged my original install live-media (the xubuntu 18.04 live boot image from 2019 on USB, used to install old), and tried to boot new off it. This succeeded perfectly.

Next I took the boot disk from old, plugged it into new, selected the disk as boot media, and got to the grub console. This is where I got stuck with the following error message:

Loading Linux 5.4.0-70-generic ...
error: bad shim signature.
Loading initial ramdisk ...
error: you need to load the kernel first.

Press any key to continue...

I booted old to compare the kernel on the boot media vs the kernel on disk:

samveen@samveen-X230:~$ sudo sbverify --list /media/temp/casper/vmlinuz 
signature 1
image signature issuers:
 - /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority
image signature certificates:
 - subject: /C=GB/ST=Isle of Man/O=Canonical Ltd./OU=Secure Boot/CN=Canonical Ltd. Secure Boot Signing
   issuer:  /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority

samveen@samveen-X230:/media/temp/casper$ sudo sbverify --list /boot/vmlinuz-5.4.0-70-generic 
signature 1
image signature issuers:
 - /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority
image signature certificates:
 - subject: /C=GB/ST=Isle of Man/O=Canonical Ltd./OU=Secure Boot/CN=Canonical Ltd. Secure Boot Signing (2017)
   issuer:  /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority

Both are signed and valid, so I checked on the bootloader chain (shim and grub):

samveen@samveen-X230:~$ sudo sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi 
warning: data remaining[834920 vs 960472]: 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
samveen@samveen-X230:~$ sudo sbverify --list /boot/efi/EFI/ubuntu/grubx64.efi 
signature 1
image signature issuers:
 - /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority
image signature certificates:
 - subject: /C=GB/ST=Isle of Man/O=Canonical Ltd./OU=Secure Boot/CN=Canonical Ltd. Secure Boot Signing (2022 v1)
   issuer:  /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority
samveen@samveen-X230:~$ sudo sbverify --list /boot/efi/EFI/ubuntu/mmx64.efi 
warning: data remaining[742792 vs 860824]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority
image signature certificates:
 - subject: /C=GB/ST=Isle of Man/O=Canonical Ltd./OU=Secure Boot/CN=Canonical Ltd. Secure Boot Signing (2022 v1)
   issuer:  /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority

That's all valid, with the Canonical Ltd. Master CA being able to validate everything.

What am I missing here which is causing the failure to boot?

Samveen
  • 180
  • 10
  • 2
    Root cause is https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996 . This was previously discussed at https://askubuntu.com/q/1429678/1004020 but I prefer your answer over that one because secure boot shouldn't be disabled – Daniel T Mar 04 '24 at 03:34
  • 2
    If this question gains traction, I might flag https://askubuntu.com/q/1503878/1004020 https://askubuntu.com/q/1495766/1004020 https://askubuntu.com/q/1494338/1004020 https://askubuntu.com/q/1486219/1004020 https://askubuntu.com/q/1501752/1004020 as duplicates and point them to this one – Daniel T Mar 04 '24 at 03:35

1 Answers1

0

After investigating a lot more, I found that the certificate used to sign the kernel I was booting was in the Secure Boot Forbidden Signature Database (dbx) (Canonical Ltd. Secure Boot Signing (2017)).

To fix the issue, I had to update to the latest image-generic kernel which was linux-image-5.4.0-172-generic (signed by latest CA) instead of the outdated linux-image-5.4.0-70-generic that I was using.

A couple of other issues with missing drivers were fixed by replacing the image-generic kernel series with the Hardware Enablement kernel series linux-generic-hwe-20.04. More details at https://wiki.ubuntu.com/Kernel/LTSEnablementStack

DKMS modules signing was already implemented, even on old(even though it was unused) , with the machine owner key already created when I first installed the OS (xubuntu 18.04 on old, in 2019). I just needed to enroll my MOK into the Shim by following the process as documented in https://wiki.ubuntu.com/UEFI/SecureBoot . Edit: I needed this only to load upstream VirtualBox kernel modules built by DKMS, else this step wasn't required.

Side note: I had installed Xubuntu 18.04 on old in 2019, and then went through the dist-upgrade process to 20.04 in early 2021. The secure boot setup as created at install was valid on new in 2024 (5 years after install) even after dist-upgrade to 20.04. That's quite some planning for future-proofing by Ubuntu. Even though I am unhappy with how 22.04 is structured and am planning on shifting to upstream Debian eventually, 20.04 with hwe kernel series is a good bet for even the recent laptops.

Samveen
  • 180
  • 10
  • New install media was created; https://fridge.ubuntu.com/2023/03/23/ubuntu-20-04-6-lts-released/ before the keys were revoked. If all security fixes had been applied (on installed systems, prior to this ISO release too), you should have had new keys installed already. – guiverc Mar 04 '24 at 03:44
  • @guiverc Before or after, I have no keys installed. I used the Xubuntu 18.04 boot media created in 2019. The private key used to sign the kernel image in that boot media was valid, allowing that kernel to boot. However, the signing key used to sign the older boot media kernel was different than the one uses for the 5.4.0-70 generic kernel for 20.04(the old 20.04 signing key fingerprint was added to the blacklist). That aside, you are right** that I missed the updates that used the new signing key, which is why the first boot failed. – Samveen Mar 04 '24 at 07:01
  • My mention of Keys refers to MOK/keys on the OS itself, required to boot with uEFI secure boot. The release link I provided mentions "Unlike previous point releases, 20.04.6 is a refresh of the amd64 installer media after recent key revocations, re-enabling their usage on Secure Boot enabled systems", those keys being disabled on INSTALLED systems as well as all install media; if updates were fully applied, the revoked keys would have been replaced prior the revocation [date]. – guiverc Mar 04 '24 at 07:19
  • FYI: All Xubuntu 18.04 media uses now revoked keys, and can only be used with with secure boot disabled; as no flavor of 18.04 was still supported when new 18.04 media was created (https://fridge.ubuntu.com/2021/09/17/ubuntu-18-04-6-lts-released/).. again similar message "Unlike previous point releases, 18.04.6 is a refresh of the amd64 and arm64 installer media after the key revocation related to the BootHole vulnerability, re-enabling their usage on Secure Boot enabled systems. More detailed information can be found here.." Keys on Xubuntu media were valid at time of creation – guiverc Mar 04 '24 at 07:22
  • @guiverc DBX is up to date on new (newly bought, with all Win11 updates). The Xubuntu 18.04 media still booted up fine (README.diskdefines says Xubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64), so older media was signed different. The MOK is not required to boot, per se. It'sare only required to tack local modifications onto the secure boot chain of validations, like DKMS modules or locally built kernels. Upstream kernels are signed by the the key embedded in the Ubuntu shim, which, in turn, is signed by the root CA of the secure boot system, i.e. the Microsoft UEFI CA 2011. – Samveen Mar 04 '24 at 10:51