2

I am trying to understand Secure Boot and what it is doing on my system. I am using systemd-boot as my bootloader, not shim or GRUB, and Secure Boot is reported as enabled: running mokutil --sb-state outputs SecureBoot enabled. However, as far as I can tell, the EFI binary that's being used to boot my system is not signed at all. So why is Secure Boot allowing it to execute?

I am running Proxmox with two mirrored SSDs using ZFS RAID-1. Each SSD has its own EFI System Partition. Here is an excerpt from lsblk -f -o +PARTUUID:

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS PARTUUID nvme1n1 ├─nvme1n1p1 4588a2cf-ad9e-4f34-a7aa-f14e4af37bb9 ├─nvme1n1p2 vfat FAT32 63B6-C9B7 865.8M 15% /mnt/nvme1n1p2 a208fcf8-78d8-4439-add8-30fb25e23af0 └─nvme1n1p3 zfs_member 5000 rpool 12777350608230387080 d5aeebcb-401d-4440-8e78-39668cbc5559 nvme2n1 ├─nvme2n1p1 bdc25142-22c5-4661-8fdb-e23c516293af ├─nvme2n1p2 vfat FAT32 63B7-1142 865.8M 15% /mnt/nvme2n1p2 dec9db8c-35f0-4e30-81ba-b25e763e125d └─nvme2n1p3 zfs_member 5000 rpool 12777350608230387080 d6c55518-f2a3-4793-bc4a-27ad2bd87058 

Note that I manually mounted the ESPs to /mnt/nvme1n1p2 and /mnt/nvme2n1p2 respectively.

Here is the output of bootctl --esp-path /mnt/nvme2n1p2 status:

System: Firmware: UEFI 2.90 (American Megatrends 5.35) Firmware Arch: x64 Secure Boot: enabled (user) TPM2 Support: yes Measured UKI: no Boot into FW: supported Current Boot Loader: Product: systemd-boot 257.7-1 Features: ✓ Boot counting ✓ Menu timeout control ✓ One-shot menu timeout control ✓ Default entry control ✓ One-shot entry control ✓ Support for XBOOTLDR partition ✓ Support for passing random seed to OS ✓ Load drop-in drivers ✓ Support Type #1 sort-key field ✓ Support @saved pseudo-entry ✓ Support Type #1 devicetree field ✓ Enroll SecureBoot keys ✓ Retain SHIM protocols ✓ Menu can be disabled ✓ Multi-Profile UKIs are supported ✓ Boot loader set partition information Partition: /dev/disk/by-partuuid/dec9db8c-35f0-4e30-81ba-b25e763e125d Loader: └─/EFI/BOOT/BOOTX64.EFI Current Entry: proxmox-6.14.11-4-pve.conf Random Seed: System Token: not set Exists: yes Available Boot Loaders on ESP: ESP: /mnt/nvme2n1p2 (/dev/disk/by-partuuid/dec9db8c-35f0-4e30-81ba-b25e763e125d) File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 257.7-1) └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 257.7-1) Boot Loaders Listed in EFI Variables: Title: UEFI OS ID: 0x0006 Status: active, boot-order Partition: /dev/disk/by-partuuid/dec9db8c-35f0-4e30-81ba-b25e763e125d File: └─/EFI/BOOT/BOOTX64.EFI Title: UEFI OS ID: 0x0005 Status: active, boot-order Partition: /dev/disk/by-partuuid/a208fcf8-78d8-4439-add8-30fb25e23af0 File: └─/EFI/BOOT/BOOTX64.EFI Title: Linux Boot Manager ID: 0x0001 Status: active, boot-order Partition: /dev/disk/by-partuuid/a208fcf8-78d8-4439-add8-30fb25e23af0 File: └─/EFI/systemd/systemd-bootx64.efi Title: Linux Boot Manager ID: 0x0002 Status: active, boot-order Partition: /dev/disk/by-partuuid/dec9db8c-35f0-4e30-81ba-b25e763e125d File: └─/EFI/systemd/systemd-bootx64.efi Boot Loader Entries: $BOOT: /mnt/nvme2n1p2 (/dev/disk/by-partuuid/dec9db8c-35f0-4e30-81ba-b25e763e125d) token: debian Default Boot Loader Entry: type: Boot Loader Specification Type #1 (.conf) title: Proxmox Virtual Environment (6.14.11-4-pve) id: proxmox-6.14.11-4-pve.conf source: /mnt/nvme2n1p2//loader/entries/proxmox-6.14.11-4-pve.conf (on the EFI System Partition) version: 6.14.11-4-pve linux: /mnt/nvme2n1p2//EFI/proxmox/6.14.11-4-pve/vmlinuz-6.14.11-4-pve initrd: /mnt/nvme2n1p2//EFI/proxmox/6.14.11-4-pve/initrd.img-6.14.11-4-pve options: root=ZFS=rpool/ROOT/pve-1 boot=zfs iommu=pt 

As far as I can tell, my system is booting from /EFI/BOOT/BOOTX64.EFI from the ESP on /dev/nvme2n1p2. However, this binary seems to not be signed at all. Here are some commands I tried to run and their outputs that led me to this conclusion:

  • sbverify --list /mnt/nvme2n1p2/EFI/BOOT/BOOTX64.EFI
No signature table present 
  • pesign --show-signature --in /mnt/nvme2n1p2/EFI/BOOT/BOOTX64.EFI
No signatures found. 
  • pesigcheck --in /mnt/nvme2n1p2/EFI/BOOT/BOOTX64.EFI
Searching dbx dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f Searching db db-d719b2cb-3d3a-4596-a3bc-dad00e67656f pesigcheck: "/mnt/nvme2n1p2/EFI/BOOT/BOOTX64.EFI" is invalid. 

As a sanity check, I followed some of the same steps taken here to verify the signature of shimx64.efi in a different system running Fedora:

sudo mokutil --export --db openssl x509 -inform der -outform pem -in DB-0001.der -out DB-0001.der.pem sudo sbverify --cert DB-0001.der.pem /boot/efi/EFI/fedora/shimx64.efi 

which output Signature verification OK as expected.

Am I missing something obvious here? It seems like Secure Boot is not doing its job if my EFI binary really is not signed at all.

4
  • Maybe your firmware is not enforcing the secure boot somehow? It seems that you have unsigned images, give your BIOS settings a visit to check if any setting is not as it should. Commented Nov 10 at 14:31
  • @td211 I triple checked the BIOS since I was getting very confused. Unless my motherboard firmware is straight up lying to me, Secure Boot is definitely enabled. Commented Nov 11 at 5:56
  • 2
    Maybe your system is booting from a previous signed boot loader, which is still saved in the boot order of your UEFI as fallback. You should try to delete all other boot loaders in the filesystem, besides the one you want to boot from. Please take note, that this might make your system unbootable. If it becomes unbootable, you will know, that only signed boot loaders are able to boot. So switch back to non secure boot, and boot the unsigned boat loader and reconfigure your system. Commented Nov 11 at 10:59
  • 1
    @paladin This should be posted as an answer, since although it doesn't provide a definitive solution, it gives a possible explanation of why the system is able to boot and a way to rule out that "secure boot is not working". Commented Nov 30 at 9:25

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.