↓Zum Hauptinhalt springen
Chris’ wirre Gedankenwelt
  1. posts/

Wait... What??? Where are all my /boot files gone?

Learning Secure Boot Uefi

Hello future me 👋

You might wonder where all the files e.g. /boot/vmlinuz-linux, /boot/amd-ucode.img, /boot/initramfs-linux.img and the boot loader configs in /boot/loader/entries are gone.

I changed everything to Unified kernel images, by primarily changing the file /etc/mkinitcpio.d/linux.preset to generate the UKI. I also told the generation of /boot/vmlinuz-linux to be placed in /usr/local/share/boot/vmlinuz-linux instead, by setting ALL_kver="/usr/local/share/boot/vmlinuz-linux". The newly generated files will end up in /boot/EFI/Linux/arch-linux.efi and /boot/EFI/Linux/arch-linux-fallback.efi. systemd-boot will pick up these automatically. So no further entries are needed. Since, there are no boot loader entries any more, we must tell the system somehow about our cmdline. This is done in /etc/cmdline.d/*.conf. This files are respected by mkinitcpio and are bundled into the mentioned /boot/EFI/Linux/arch-linux*.efi files.

$ cat /etc/cmdline/10-root.conf
rd.luks.name=9c8381f8-7e0f-44f6-be26-655b70d33a32=root root=UUID=a1af7e43-857b-4903-8896-e25484175e5d

$ cat /etc/mkinitcpio.d/linux.preset
ALL_kver="/usr/local/share/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

default_uki="/boot/EFI/Linux/arch-linux.efi"
default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"

fallback_uki="/boot/EFI/Linux/arch-linux-fallback.efi"
fallback_options="-S autodetect"

While I was there, I decided to get rid of /boot/amd-ucode.img as well. mkinitcpio collects the firmware from /usr/lib/firmware/amd-ucore/ anyways, and packs it into the initramfs. No need to keep the file around. However, /boot/amd-ucode.img is part of the package amd-ucode. I had to tell pacman to don’t extract those files.

$ grep NoExtract /etc/pacman.conf
NoExtract   = boot/*-ucode.img

Those changes do provide nothing but a learning opportunity 😄 And maybe… just maybe… in some point in the future, I will sign everything.

Update 2024-12-23 #

That went faster than expected. I just went on and created some keys and signed my images, roughly following Unified Extensible Firmware Interface / Secure Boot. Using systemd-ukify for signing, and systemd-boot for enrolment.

I decided to create my own files using openssl like documented. But first of all, backed up the my old setup. However, I realized that there is a “Restore to Factory Settings” in the Setup of the Zenbook.

My first attempt were to sign the resulted efi images, as well as the boot loader, with my own keys. Boot worked. However, now Windows for sure doesn’t boot any more.

To fix that, I just grabbed my backed up .esl files and combined the new with the old ones, and sign everything with my Platform Key (PK) or Key Exchange Key (KEK) respectively.

And voilà. A couple of hours and attempts later, Windows boots with Secure Boot enabled. The process took far to long, but I thought, my signing stuff was wrong. However, it turned out the filesystem of my /boot was broken, and ate the windows boot loader. Took me a while to figure it out and find the original to restore my system :grim:

Generate keys #

openssl req -newkey rsa:4096 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=chrigl Platform Key/" -out PK.crt
openssl x509 -outform DER -in PK.crt -out PK.cer
openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=chrigl 2024-12-21 Key Exchange Key/" -out KEK.crt
openssl x509 -outform DER -in KEK.crt -out KEK.cer
openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "/CN=chrigl Signature Database key/" -out db.crt
openssl x509 -outform DER -in db.crt -out db.cer

Create all the efi things #

The old_*.esl were backed up from efi and now included so that Windows and ASUS stuff works. I know… not very secure… but this is only for toying around anyways :)

sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth
sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt new_KEK.esl
cat new_KEK.esl old_KEK.esl > KEK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt new_db.esl
# Leaving PK.esl here for now, because how ukify uses the same cert everywhere
cat new_db.esl old_db.esl PK.esl > db.esl

sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth
sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt dbx old_dbx.esl dbx.auth

cp db.auth keys/db/
cp dbx.auth keys/dbx/
cp KEK.auth keys/KEK/
cp PK.auth keys/PK/

Verifying everything, but not using sbkeysync for enrolment:

sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

Enrolment with systemd-boot #

cp keys/*/*.auth /boot/loader/keys/auto/

cat /boot/loader/loader.conf

secure-boot-enroll manual

On reboot, you should see an additionally menu entry, given Secure Boot Setup Mode is enabled.

Signing kernel images #

systemd-ukify must be installed and configured properly.

# cat /etc/kernel/uki.conf

[UKI]
SecureBootPrivateKey=/etc/secureboot/db.key
SecureBootCertificate=/etc/secureboot/db.crt

[PCRSignature:initrd]
PCRPrivateKey=/etc/secureboot/tpm2-pcr-private-key.pem
PCRPublicKey=/etc/secureboot/tpm2-pcr-public-key.pem
Phases=enter-initrd

[PCRSignature:system]
PCRPrivateKey=/etc/secureboot/tpm2-pcr-private-key.pem
PCRPublicKey=/etc/secureboot/tpm2-pcr-public-key.pem
Phases=enter-initrd:leave-initrd
       enter-initrd:leave-initrd:sysinit
       enter-initrd:leave-initrd:sysinit:ready

Manually Signing systemd-boot #

There is no automation in place as of now.

Sign the systemd-bootx64.efi and install systemd-boot.

sbsign \
  --cert /etc/secureboot/db.crt \
  --key /etc/secureboot/db.key \
  /usr/lib/systemd/boot/efi/systemd-bootx64.efi

bootctl install

With all of this in place, systemd-cryptenroll can be used to unseal the luks encrypted disk without requiring the real password.

E.g.

systemd-cryptenroll \
  --tpm2-public-key=/etc/secureboot/tpm2-pcr-public-key.pem \
  --tpm2-with-pin=yes \
  --tpm2-pcrs=7 \
  --tpm2-device=auto /dev/nvme0n1p5

For sure, especially the signing keys should live somewhere else, in a secure space.