Discuss...

Update: I no longer use dracut, and the corresponding part of this blog post no longer reflects my setup.

This article describes my Arch Linux setup which combines Secure Boot with custom keys, TPM2-based full disk encryption and systemd-homed into a fully encrypted and authenticated, yet convenient Linux system.

This setup draws inspiration from Authenticated Boot and Disk Encryption on Linux and Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248 by Lennart Poettering, and combines my previous posts on these topics.

What this setup does

• Authenticate the boot loader, kernel, initramfs, microcode with Secure Boot, using my own custom keys. Nothing can boot which wasn’t signed by my keys.
• Everything is either authenticated with my keys (kernel, initramfs, microcode) or encrypted (system partition).
• Encrypt the system partition, and unlock it automatically if the boot process was authenticated, by means of a TPM2 key bound to the secure boot state.
• Give every user their own dedicated encrypted home directory, which gets unlocked at login and locked again at logout.

What it doesn’t

• Show an ugly LUKS password prompt at boot (even with Plymouth it’s not really pretty).
• Leave some parts unencrypted and unauthenticated (conventional installations often fail to consider the initramfs).
• Ask me twice for my password, once at boot to unlock the disk and then again at login.
• Encrypt data of all users with a shared key.

Tools used

• Archlinux
• systemd >= 250
• systemd-boot as bootloader
• systemd in initramfs to automatically discover and mount the root filesystem
• dracut to generate the initramfs and build signed UEFI binaries
• sbctl to create and enroll Secure Boot keys, and sign binaries
• systemd-homed to manage user accounts with per-user encrypted home directories
• systemd-cryptenroll to add TPM2 and recovery keys tokens to a LUKS partition

The setup

Install the system

We follow the Installation Guide up to and including section “Update the system clock”. Then we partition the disk (/dev/nvme0n1 in our case); we need an EFI system partition of about 500MB and a root partition spanning the rest of the disk. The EFI partition must be unencrypted and have a FAT filesystem; for the root file system we choose btrfs on top of an encrypted partition.

First we partition the disk and reload the partition table; we take care to specify proper partition types (-t option) so that systemd can automatically discover and mount our filesystems without further configuration in /etc/crypttab or /etc/fstab (see Discoverable Partitions Specification (DPS)):

$ target_device=/dev/nvme0n1
$ sgdisk -Z "$target_device"
$ sgdisk -n1:0:+550M -t1:ef00 -c1:EFISYSTEM -N2 -t2:8304 -c2:linux "$target_device"
$ sleep 3
$ partprobe -s "$target_device"
$ sleep 3

Then we setup the encrypted partition for the root file system. We get asked for an encryption password where we pick a very simple encryption password (even “password” is good enough for now, really) to save some typing during installation, as we’ll later replace the password with TPM2 key and a random recovery key:

$ cryptsetup luksFormat --type luks2 /dev/disk/by-partlabel/linux
$ cryptsetup luksOpen /dev/disk/by-partlabel/linux root
$ root_device=/dev/mapper/root

Now we create the filesystems:

$ mkfs.fat -F32 -n EFISYSTEM /dev/disk/by-partlabel/EFISYSTEM
$ mkfs.btrfs -f -L linux "$root_device"

Now we can mount the filesystems and create some basic btrfs subvolumes:

$ mount "$root_device" /mnt
$ mkdir /mnt/efi
$ mount /dev/disk/by-partlabel/EFISYSTEM /mnt/efi
$ for subvol in var var/log var/cache var/tmp srv home; do btrfs subvolume create "/mnt/$subvol"; done

Now we’re ready to bootstrap Arch Linux: We generate a mirrorlist and install essential packages:

$ reflector --save /etc/pacman.d/mirrorlist --protocol https --latest 5 --sort age
$ pacstrap /mnt base linux linux-firmware intel-ucode btrfs-progs dracut neovim

This takes a while to download and installation all packages; afterwards we configure some essential settings. Choose locale settings and the $new_hostname according to your personal preferences.

$ ln -sf /usr/share/zoneinfo/Europe/Berlin /mnt/etc/localtime
$ sed -i -e '/^#en_GB.UTF-8/s/^#//' /mnt/etc/locale.gen
$ echo 'LANG=en_GB.UTF-8' >/mnt/etc/locale.conf
$ echo 'KEYMAP=us' >/mnt/etc/vconsole.conf
$ echo "$new_hostname" >/mnt/etc/hostname

Now we enter the new system and finish configuration by generating locales, enabling a few essential services and setting a root password:

$ arch-chroot /mnt
$ locale-gen
$ systemctl enable systemd-homed
$ systemctl enable systemd-timesyncd
$ passwd root

Still in chroot we now build unified EFI kernel images (including initrd and kernel) for booting and install the systemd-boot boot loader:

$ pacman -S --noconfirm --asdeps binutils elfutils
$ dracut -f --uefi --regenerate-all
$ bootctl install

We do not need to create /etc/fstab or /etc/crypttab; as we assigned the appropriate types to each partition and installed systemd-boot a systemd-based initramfs can automatically determine the disk the system was booted from, and discover all relevant partitions. It can then use superblock information to automatically open encrypted LUKS devices and mount file systems.

At this point we also need to take care to install everything we need for network configuration after reboot. For desktop systems I prefer network manager because it integrates well into Gnome:

$ pacman -S networkmanager

We have finished the basic setup from the live disk now; let’s leave chroot and reboot:

$ exit
$ reboot

After reboot we can complete the system installation, by adding a desktop environment, applications, command line tools, etc.

I like to automate this, and have two bash scripts in my dotfiles, one for boostrapping a new system from a live disk (arch/bootstrap-from-iso.bash) and another one for installing everything after the initial bootstrapping (arch/install.bash).

Create homed user

With the installation finished we create our user account with homectl; let’s name it foo for the purpose of this article. First we should disable copy on write for /home, because this file system feature doesn’t work well with large files frequently updated in place, such as disk images of virtual machines or loopback files as created by systemd-homed:

$ chattr +C /home/

We now create the foo user with an encrypted home directory backed by LUKS and btrfs:

$ homectl create foo --storage luks --fs-type btrfs

By default systemd assigns 85% of the available disk space to the user account, and will balance available space among all user accounts (based on a weight we can configure with —rebalance-weight). On a single user system we may prefer to set an explicit quota for the user account:

$ homectl resize foo 50G

We can also add some additional metadata to the user account:

homectl update foo --real-name 'Foo' --email-address foo@example.org --language en_GB.UTF-8 --member-of wheel

man homectl provides a complete list of flags; in particular it also offers support for various kinds of security tokens (e.g. FIDO2) for user authentication, provides plenty of means for resource accounting (e.g. memory consumption) for the user account, and supports different kinds of password policies.

Finally we may run into systemd issues with home areas on btrfs (see below); if login fails with a “Operation on home failed: Not enough disk space for home” message we need to enable LUKS discard:

homectl update foo --luks-discard=true

This flag is not safe (heed the warning in man homectl), but until systemd improves its behaviour on btrfs we have no choice unfortunately.

Setup secure boot

First let’s check the secure boot state. We must be in Setup Mode in order to enroll our own keys:

$ sbctl status
Installed:	✓ sbctl is installed
Owner GUID:	REDACTED
Setup Mode:	✗ Enabled
Secure Boot:	✗ Disabled

To enable secure boot we need some keys which we generate with sbctl. For historical reasons sbctl creates these keys in /usr/share/secureboot but plans exists to change this to a more appropriate place (see Github issue 57).

$ sbctl create-keys

Now we tell dracut how to sign the UEFI binaries it builds and rebuild our kernel images to get them signed:

$ cat > /etc/dracut.conf.d/50-secure-boot.conf <<EOF
uefi_secureboot_cert="/usr/share/secureboot/keys/db/db.pem"
uefi_secureboot_key="/usr/share/secureboot/keys/db/db.key"
EOF
$ dracut -f --uefi --regenerate-all

Next we need to sign the bootloader. With -s we ask sbctl to remember this file in its database which later lets us check signatures with sbctl verify and automatically update all signatures with sbctl sign-all. The sbctl package includes a pacman hook which automatically updates signatures when an EFI binary on /efi or in /usr/lib changed. Note that we do not sign the boot loader on /efi but instead place a signed copy in /usr/lib. Starting with systemd 250 bootctl will pick up the signed copy when updating the boot loader. Hence we reinstall the bootloader afterwards to put the signed copy on /efi.

$ sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi
$ bootctl install

We should also do the same for the firmware update to enable seamless firmware updates under secure boot. Again we use -s to remember this file in the sbtctl database:

$ sbctl sign -s -o /usr/lib/fwupd/efi/fwupdx64.efi.signed /usr/lib/fwupd/efi/fwupdx64.efi

Now let’s verify that we have all signatures in place and enroll keys if everything’s properly signed:

$ sbctl verify
Verifying file database and EFI images in /efi...
✓ /usr/lib/fwupd/efi/fwupdx64.efi.signed is signed
✓ /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed is signed
✓ /efi/EFI/BOOT/BOOTX64.EFI is signed
✓ /efi/EFI/Linux/linux-5.15.12-arch1-1-19ea0ebee1ea4de086128ce1a8e2197b-rolling.efi is signed
✓ /efi/EFI/systemd/systemd-bootx64.efi is signed
$ sbctl enroll-keys

After a reboot we can check the secure boot state again; we’ll see that setup mode is now disabled, secure boot is on, and everything was properly enrolled:

$ reboot
$ sbctl status
Installed:	✓ sbctl is installed
Owner GUID:	REDACTED
Setup Mode:	✓ Disabled
Secure Boot:	✓ Enabled

Enroll TPM2 keys

With the boot process secured we can now configure automatic unlocking of the root filesystem, by binding a LUKS key to the TPM.

We enable the tpm2-tss module in the Dracut configuration, install the dependencies of this dracut module, and regenerate our UEFI kernel images (which will again be signed for secure boot):

$ cat > /etc/dracut.conf.d/50-tpm2.conf <<EOF
add_dracutmodules+=" tpm2-tss "
EOF
$ pacman -S tpm2-tools
$ dracut -f --uefi --regenerate-all

Now we can enroll a TPM2 token (bound to the secure boot measurement in PCR 7) and a recovery key to our root filesystem. This prompts for an existing passphrase each time. Store the recovery key at a safe place outside of this disk, to have it at hand if TPM2 unlocking ever breaks.

$ systemd-cryptenroll /dev/gpt-auto-root-luks --recovery-key
$ systemd-cryptenroll /dev/gpt-auto-root-luks --tpm2-device=auto

Now reboot and enjoy: The boot process goes straight all the way to the login manager and never shows a LUKS password prompt. The root filesystem is still reasonably secure: The TPM2 key becomes invalid if the secure boot state changes (e.g. new keys are enrolled, or secure boot is disabled), and cannot be recovered if the disk is removed from the system. Consequently only a kernel signed and authenticated with your own secure boot keys can unlock the root disk automatically.

Finally we can wipe the password slots if you like (make sure to have a recovery key at this point):

$ systemd-cryptenroll /dev/gpt-auto-root-luks --wipe-slot=password

If you cannot use secure boot for some reason you can alternatively bind the TPM2 token to a combination of firmware state and configuration and the exact boot chain (up to and including the specific kernel that was started), by specifing the PCR registers 0-5:

$ systemd-cryptenroll /dev/gpt-auto-root-luks --tpm2-device=auto --tpm2-pcrs 0+1+2+3+4+5

This only permits the current kernel and its specific boot chain (e.g bootloader used) to unlock the root filesystem automatically. However this means that we need to reboot and then wipe and re-enroll the TPM2 token after every rebuild of the kernel image… which happens quite often in fact: Dracut updates or configuration changes, kernel updates, systemd updates (due to the EFI shim provided by systemd), bootloader updates, bootloader configuration changes, etc.

Hence I generally recommend to use secure boot if possible in any way.

Issues with this setup

While I am happy with this setup it still has a few drawbacks and issues.

Double encryption

In this setup home directories get encrypted twice, once by homed and then again by the underlying LUKS device. This wastes a bunch of CPU cycles and likely impacts performance a lot, though I haven’t measured the impact and it’s not so bad as to be noticeable in my day-to-day work.

We could optimize this by putting /home/ on a separate partition backed by dm-integrity to authenticate the filesystem (omitting dm-integrity and using a plain file system leaves an attack vector, because linux cannot securely mount untrusted file systems). This setup requires at least systemd 250 or newer, because earlier versions do not support dm-integrity well. With systemd 250 we can setup a HMAC-based integrity device, put the HMAC key on the rootfs (e.g. /etc/keys/home.key) and register the home partition in /etc/integritytab with that key, and then mount it via /etc/fstab.

However, this has a few issues on its own, because dm-integrity has a few design issues and is and nowhere near LUKS/dm-crypt:

• There’s no key management like LUKS for dm-crypt, meaning we can’t use passphrases or TPM2 keys for dm-integrity devices; instead we need a key file somewhere on disk.
• Unlike LUKS/dm-crypt devices dm-integrity devices aren’t self-describing, because the superblock for dm-integrity doesn’t even contain the algorithm used (see <https://github.com/systemd/systemd/pull/20902). We cannot mount a dm-integrity device without some extra configuration, and worse, getting the configuration wrong can silently corrupt the device.
• For these reasons, DPS cannot and does not support dm-integrity partitions, so we need to configure the whole home partition mount, from dm-integrity up to /etc/fstab.

Tooling issues

There are also multiple issues with current tooling that require some more or less safe workarounds:

• At the time of writing systemd-home has issues with resizing LUKS home areas on btrfs filesystems, apparently due to fallocate() idiosyncrasies in btrfs. This issue prevents users from logging in, see systemd issues 19398 and 20960, an Arch forums post, and a mail on the systemd-devel list. A workaround is to enable online discard for the user, but this flag is unsafe because it allows overcommitting disk space, which results in IO errors that the kernel and application are not well prepared to handle (which comes down to potential data loss). Keep frequent backups if you need this.

Discuss...

Discuss...

Historically cryptsetup and LUKS only supported good old passwords; however recent systemd versions extend cryptsetup with additional key types such as FIDO tokens and TPM devices.

I like the idea of encrypting the rootfs with a TPM2 key; it allows booting without ugly LUKS password prompts but still it keeps data encrypted at rest, and when combined with secure boot also still protects the running system against unauthorized access.

Secure boot will prevent others from placing custom kernels on the unencrypted EFI system partition and booting these, or changing the kernel cmdline, in order to obtain root access to the unlocked rootfs. LUKS encryption with a TPM-based key bound to secure boot state protects the data if someone removes the hard disk and attempts to access it offline, or tries to disable secure boot in order to boot a custom kernel.

I’ve covered secure boot setup in a past article; this article talks about the TPM2-based encryption.

Enroll TPM key

Check that the system supports TPM2:

$ systemd-cryptenroll --tpm2-device=list
PATH        DEVICE      DRIVER 
/dev/tpmrm0 MSFT0101:00 tpm_crb

Then enroll a new TPM2 key (use the appropriate block device path of course):

$ systemd-cryptenroll --tpm2-device=auto /dev/disk/by-partlabel/linux 
New TPM2 token enrolled as key slot 1.

Then add recovery key:

$ systemd-cryptenroll --recovery-key  /dev/disk/by-partlabel/linux
🔐 Please enter current passphrase for disk /dev/disk/by-partlabel/linux: 
A secret recovery key has been generated for this volume:

    🔐 efcfbdlt-rhkdjjul-inbhbvhi-nfkvbbbv-didjbjel-butkrrig-ugbrivdd-evnkkkgn

Please save this secret recovery key at a secure location. It may be used to
regain access to the volume if the other configured access credentials have
been lost or forgotten. The recovery key may be entered in place of a password
whenever authentication is requested.
New recovery key enrolled as key slot 2.

As suggested save this key in a secure location outside of the system. If TPM2 unlocking fails systemd will prompt for a password where you can enter this key. This lets us access the data even if the TPM2 key became invalid (e.g. when the secure boot configuration changes).

Configure dracut

Force dracut to include the TPM2 software stack, by adding /etc/dracut.conf.d/tpm.conf:

add_dracutmodules+=" tpm2-tss "
# And add files dracut currently fails to add, see
# https://github.com/dracutdevs/dracut/issues/1676
install_items+=" /usr/lib/cryptsetup/libcryptsetup-token-systemd-tpm2.so "

The last line adds necessary cryptsetup plugins which dracut doesn’t yet add (see https://github.com/dracutdevs/dracut/issues/1676).

Make sure to use dracut newer than 055-106-g813577e2; dracut 55 has a typo in the tpm2-tss module dependencies which breaks the module (see https://github.com/dracutdevs/dracut/pull/1526), and another issue with systemd-sysusers which interferes with TPM2 support in early boot (see https://github.com/dracutdevs/dracut/pull/1658). As of Dec 2021 you’ll need to install dracut-git from AUR.

Reboot and cleanup

Reboot to verify that the system now boots without a LUKS prompt. Afterwards remove the password key from the rootfs:

$ systemd-cryptenroll --wipe-slot=password /dev/disk/by-partlabel/linux

Now the system only unlocks with the TPM2 key or the recovery key.

Tighten security

Check that

• secure boot is enabled (bootctl status or sbctl status),
• secure boot uses custom keys,
• all kernels are signed (sbctl verify; also check the firmware updater and other relevant EFI binaries), and
• no unsigned initramfs or microcode image is used (at best use bundled UEFI executables).

For users consider to use systemd-homed which offers per-user encrypted home “areas”, backed by LUKS encrypted loopback files.

Discuss...

Discuss...

I started playing around with secure boot, with the ultimately goal of setting it up on my laptop. I experimented in a libvirt/qemu VM and to my surprise a custom secure boot setup is rather easy (the Secure Boot page on the Arch Wiki suggests quite the contrary), thanks to dracut and a fairly recent tool named sbctl which just recently had it’s first release.

VM Setup

We start with a fresh libvirt VM (you’ll qemu, libvirt, and edk2-ovmf) of a recent Arch Linux ISO using the EFI secure boot firmware provided by the edk2-ovmf package at /usr/share/edk2-ovmf/x64/OVMF_CODE.secboot.fd; when using virt-manager be sure to edit the configuration before starting the installation and make sure to select this firmware (otherwise you’ll end up in a BIOS-based VM which doesn’t really get far in terms of secure boot). Go through the standard installation process (I have a custom bootstrap script for a quick fresh Arch install with some standard settings); do make sure to install dracut for initrd and kernel image generation and setup systemd-boot as the EFI bootloader. Install the linux-lts kernel in addition to the standard linux kernel; this allows to leave one kernel unsigned after enabling secure boot to verify that booting the unsigned kernel is really forbidden.

Also build unified images right away with dracut --uefi --kver; together with systemd partition auto-discovery this avoids the need for dedicated boot loader configuration and already prepares for secure boot (which requires unified EFI binaries).

Prerequisites

After rebooting check the secure boot state with bootctl first to make sure that the firmware supports secure boot:

# bootctl | head
System:
     Firmware: UEFI 2.70 (EDK II 1.00)
  Secure Boot: disabled
   Setup Mode: setup
 Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 247.4-2-arch
     Features: ✓ Boot counting
               ✓ Menu timeout control

Now install sbctl to generate and enroll secure boot keys and sign EFI binaries (pacman -S sbctl); then check how sbctl sees the secure boot state:

# sbctl  status
==> WARNING: Setup Mode: Enabled
==> WARNING: Secure Boot: Disabled

Key generation

Now we can generate our set of secure boot keys with sbctl:

# sbctl create-keys
==> Creating secure boot keys...
  -> Created UUID bb88de62-623a-4450-b256-7c9ffc924f64...
==> Create EFI signature list /usr/share/secureboot/keys/PK/PK.der.esl...
==> Signing /usr/share/secureboot/keys/PK/PK.der.esl with /usr/share/secureboot/keys/PK/PK.key...
==> Create EFI signature list /usr/share/secureboot/keys/KEK/KEK.der.esl...
==> Signing /usr/share/secureboot/keys/KEK/KEK.der.esl with /usr/share/secureboot/keys/PK/PK.key...
==> Create EFI signature list /usr/share/secureboot/keys/db/db.der.esl...
==> Signing /usr/share/secureboot/keys/db/db.der.esl with /usr/share/secureboot/keys/KEK/KEK.key...

This command creates all required keys in /usr/share/secureboot; on a physical installation it’s probably very advisable to copy the entire contents of the directory to a secure off-site location for backup.

sbctl verify now lists all EFI binaries as unsigned:

# sbctl verify
==> Verifying file database and EFI images in /efi...
  -> WARNING: /efi/EFI/BOOT/BOOTX64.EFI is not signed
  -> WARNING: /efi/EFI/Linux/linux-5.10.27-1-lts-b2f521553ef8449289122ae8d4c2cffe-rolling.efi is not signed
  -> WARNING: /efi/EFI/Linux/linux-5.11.11-arch1-1-b2f521553ef8449289122ae8d4c2cffe-rolling.efi is not signed
  -> WARNING: /efi/EFI/systemd/systemd-bootx64.efi is not signed

Boot loader signatures

Sign the boot loader first:

# sbctl sign -s /efi/EFI/BOOT/BOOTX64.EFI
  -> Signing /efi/EFI/BOOT/BOOTX64.EFI...
# sbctl sign -s /efi/EFI/systemd/systemd-bootx64.efi
  -> Signing /efi/EFI/systemd/systemd-bootx64.efi...

Now the boot loader is properly signed:

# sbctl verify
==> Verifying file database and EFI images in /efi...
  -> /efi/EFI/systemd/systemd-bootx64.efi is signed
  -> /efi/EFI/BOOT/BOOTX64.EFI is signed
  -> WARNING: /efi/EFI/Linux/linux-5.10.27-1-lts-b2f521553ef8449289122ae8d4c2cffe-rolling.efi is not signed
  -> WARNING: /efi/EFI/Linux/linux-5.11.11-arch1-1-b2f521553ef8449289122ae8d4c2cffe-rolling.efi is not signed

The -s flag stores these paths in an internal sbctl database which keeps track of files sbsign signed; sbctl uses this database in sbctl sign-all to refresh the signatures of all files it ever signed. This helps with boot loader updates:

# bootctl update
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/efi/EFI/systemd/systemd-bootx64.efi".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/efi/EFI/BOOT/BOOTX64.EFI".
# sbctl verify
==> Verifying file database and EFI images in /efi...
  -> WARNING: /efi/EFI/BOOT/BOOTX64.EFI is not signed
  -> WARNING: /efi/EFI/systemd/systemd-bootx64.efi is not signed
  -> WARNING: /efi/EFI/Linux/linux-5.10.27-1-lts-b2f521553ef8449289122ae8d4c2cffe-rolling.efi is not signed
  -> WARNING: /efi/EFI/Linux/linux-5.11.11-arch1-1-b2f521553ef8449289122ae8d4c2cffe-rolling.efi is not signed
# sbctl sign-all
  -> Signing /efi/EFI/systemd/systemd-bootx64.efi...
  -> Signing /efi/EFI/BOOT/BOOTX64.EFI...
# sbctl verify
==> Verifying file database and EFI images in /efi...
  -> /efi/EFI/BOOT/BOOTX64.EFI is signed
  -> /efi/EFI/systemd/systemd-bootx64.efi is signed
  -> WARNING: /efi/EFI/Linux/linux-5.10.27-1-lts-b2f521553ef8449289122ae8d4c2cffe-rolling.efi is not signed
  -> WARNING: /efi/EFI/Linux/linux-5.11.11-arch1-1-b2f521553ef8449289122ae8d4c2cffe-rolling.efi is not signed

Signed unified kernel images

To sign the kernel tell dracut about the secure boot keys:

# cat > /etc/dracut.conf.d/50-secure-boot.conf <<EOF
uefi_secureboot_cert="/usr/share/secureboot/keys/db/db.pem"
uefi_secureboot_key="/usr/share/secureboot/keys/db/db.key"
EOF

While at it also configure a few other non-essential but still very useful dracut options, to silence the boot process and reduce the size of the images:

# cat > /etc/dracut.conf.d/40-options.conf <<EOF
kernel_cmdline="quiet"
compress="zstd"
hostonly="yes"
EOF

With secure boot systemd-boot can no longer set a kernel command line: In this mode systemd-boot uses EFI interfaces to start binaries, to avoid bypassing the signature requirement; this interface does not support for kernel command line arguments. For this reason the desired command line as well as all required initrds must be embedded into a single signed EFI binary, and any command line flags like “quiet” must be set through dracut with the kernel_cmdline setting.

Now generate a unified UEFI binary for the LTS kernel:

# dracut --force --uefi --kver 5.10.27-1-lts
dracut: Executing: /usr/bin/dracut --force --uefi --kver 5.10.27-1-lts
…
dracut: *** Creating image file '/efi/EFI/Linux/linux-5.10.27-1-lts-b2f521553ef8449289122ae8d4c2cffe-rolling.efi' ***
dracut: Using UEFI kernel cmdline:
dracut: quiet
warning: data remaining[25025536 vs 25035138]: gaps between PE/COFF sections?
warning: data remaining[25025536 vs 25035144]: gaps between PE/COFF sections?
Signing Unsigned original image
dracut: *** Creating signed UEFI image file '/efi/EFI/Linux/linux-5.10.27-1-lts-b2f521553ef8449289122ae8d4c2cffe-rolling.efi' done ***

Note the last line: dracut bundled everything into a single EFI file and signed it. sbctl verify confirms the new signature:

# sbctl verify
==> Verifying file database and EFI images in /efi...
  -> /efi/EFI/BOOT/BOOTX64.EFI is signed
  -> /efi/EFI/systemd/systemd-bootx64.efi is signed
  -> /efi/EFI/Linux/linux-5.10.27-1-lts-b2f521553ef8449289122ae8d4c2cffe-rolling.efi is signed

Secure boot activation

Now enroll the new secure boot keys into the EFI firmware, check that the firmware left secure boot setup mode:

# sbctl enroll-keys
==> Syncing /usr/share/secureboot/keys to EFI variables...
==> Synced keys!
# sbctl status
==> Setup Mode: Disabled
==> WARNING: Secure Boot: Disabled

Now enable the boot loader menu to be able to select a kernel at boot and reboot:

# echo 'timeout 10' >> /efi/loader/loader.conf
# reboot

The firmware now prohibits booting the unsigned kernel, but allows the signed kernel:

Open points

Dracut automates signing kernel images (dracut-hook-uefi automatically invokes dracut when installing or updating kernel images through pacman), but ensuring proper signatures on the bootloader itself even across updates presents an open issue; ideally there should be some way to call sbctl sign-all automatically after bootctl.

sbctl is also a rather new project, which published a first 0.1 only recently; it remains to be seen how sustainable the project is (I dearly hope it is since it provides a huge improvement over the state of the art secure-boot tooling).

Discuss...