blog.6admin.io
guest@6admin.io:~$
boot, foreman, kernel, pxe, secure-boot, security, tpm

The boot chain, from GRUB to UKI

Locking down the boot process and the editing of kernel parameters is not a new problem, it predates GRUB2, GRUB and even LILO. What’s changing today is that the ecosystem is turning the page on an entire generation of tooling and Canonical’s announcement for Ubuntu 26.10 is a good marker of it.

What Canonical is announcing for 26.10

In substance, Canonical is trimming signed GRUB for 26.10, which reduces the attack surface along the way, in order to prepare its phase-out. GRUB is becoming obsolete against UKI (Unified Kernel Image) combined with systemd-boot.

Concretely this means the end of encrypted /boot, with /boot now mandatorily on ext4. The official source is the “Streamlining secure boot for 26.10” discussion on the Ubuntu forum, for anyone who wants the detail.

GRUB-encrypted /boot, a false friend

Let’s be clear, GRUB-encrypted /boot was a false friend anyway. The LUKS parser embedded in GRUB runs pre-OS, with no memory protection whatsoever : no ASLR, no sandboxing, nothing resembling the guardrails that even the humblest process enjoys once the system is up.

That’s exactly the context that produced BootHole (CVE-2020-10713). The LUKS code in GRUB wasn’t a rampart, it was itself an attack vector. People thought they were hardening the machine by encrypting /boot at that level, when in fact they were widening the exposed surface before the kernel even took over.

What is dropped rightly and what wrongly

Reducing signed GRUB makes sense, since you remove privileged code that runs in the pre-OS blind spot. The btrfs drop, on the other hand, strikes me as a bit much. It’s read-only in GRUB, maintained upstream and needed for boot-to-snapshot, that is for rolling back to a known-good state from the boot menu. Sacrificing it means losing a useful resilience feature for a reason that owes more to simplification than to security.

The modern answer to Evil Maid

On the Evil Maid front, meaning the attacker with brief physical access to a powered-off machine, the modern answer no longer runs through encrypting /boot inside GRUB. It rests on three pieces working together.

UKI first, which bundles kernel, initramfs and command line into a single signed binary, hence measurable as one block. Measured Boot with the TPM next, which records each stage’s measurements into the PCRs and lets you seal secrets that only unseal if the chain stayed intact. dm-verity last, on the system partitions, which guarantees filesystem integrity in read-only mode.

This model is nothing experimental : it’s the one already shipped by Android, ChromeOS, Flatcar and Talos. It moves trust from a fragile pre-OS parser to a chain measured and sealed by the hardware.

Where the ecosystem is heading

The trajectory is now clear : UKI, systemd-boot and TPM Measured Boot. GRUB stays around for legacy BIOS and it will for a while yet, but for everything under modern UEFI it is end-of-life. Arch, Fedora, Debian and Talos Linux are already there, or well into the transition.

For anyone wanting to tie this to the rest of the chain, I’ve detailed Secure Boot applied to PXE elsewhere (see secureboot-pxe ), the Foreman-managed GRUB password (see foreman-grub-pass ) and filesystem hardening (see hardening-filesystem ), which dovetail naturally with what I describe here.

From GRUB to the UKI, no magic

  • Locking down boot-parameter editing is an old problem, but the tooling to solve it has just changed generation.
  • GRUB-encrypted /boot was a false friend : its pre-OS LUKS parser, with no ASLR or sandboxing, gave us BootHole.
  • Dropping btrfs from GRUB is debatable, since it remains useful for boot-to-snapshot.
  • The modern answer to Evil Maid is UKI plus Measured Boot/TPM plus dm-verity.
  • The direction of the UEFI ecosystem is settled, GRUB only lingers for legacy BIOS.