La chaîne de boot, de GRUB à UKI

La question du verrouillage du boot et de l’édition des paramètres du kernel n’est pas neuve, elle est même antérieure à GRUB2, à GRUB et jusqu’à LILO. Ce qui change aujourd’hui, c’est que l’écosystème est en train de tourner la page d’une génération entière d’outils et l’annonce de Canonical pour Ubuntu 26.10 en est un bon marqueur.

Ce que Canonical annonce pour 26.10

En substance, Canonical dégraisse le GRUB signé pour 26.10, ce qui réduit au passage la surface d’attaque, afin de préparer sa sortie. GRUB devient obsolète face à UKI (Unified Kernel Image) combiné à systemd-boot.

Concrètement, cela signifie la fin du /boot chiffré, avec un /boot désormais obligatoirement en ext4. La source officielle est la discussion “Streamlining secure boot for 26.10” sur le forum Ubuntu, pour qui veut le détail.

Le /boot chiffré via GRUB, un faux ami

Soyons clairs, le /boot chiffré via GRUB était un faux ami de toute façon. Le parser LUKS embarqué dans GRUB tourne en pré-OS, sans aucune protection mémoire : pas d’ASLR, pas de sandboxing, rien qui ressemble aux garde-fous dont bénéficie le moindre processus une fois le système démarré.

C’est exactement ce contexte qui a donné BootHole (CVE-2020-10713). Le code LUKS dans GRUB n’était pas un rempart, il était lui-même un vecteur d’attaque. On croyait durcir la machine en chiffrant /boot à ce niveau, alors qu’on élargissait la surface exposée avant même que le kernel ne prenne la main.

Ce qui est jeté à raison et ce qui l’est à tort

Réduire le GRUB signé a du sens, puisqu’on retire du code privilégié qui s’exécute dans l’angle mort du pré-OS. En revanche, le drop de btrfs me paraît un peu abusé. Il est read-only dans GRUB, maintenu upstream et nécessaire pour le boot-to-snapshot, autrement dit pour revenir à un état antérieur sain depuis le menu de démarrage. Le sacrifier, c’est perdre une fonctionnalité de résilience utile pour une raison qui tient davantage à la simplification qu’à la sécurité.

La réponse moderne à l’Evil Maid

Côté Evil Maid, c’est-à-dire l’attaquant qui a un accès physique bref à une machine éteinte, la réponse moderne ne passe plus par le chiffrement de /boot dans GRUB. Elle repose sur trois briques qui travaillent ensemble.

UKI d’abord, qui regroupe kernel, initramfs et ligne de commande dans un unique binaire signé, donc mesurable d’un bloc. Measured Boot avec le TPM ensuite, qui enregistre les mesures de chaque étape dans les PCR et permet de sceller des secrets qui ne se libèrent que si la chaîne est restée intègre. dm-verity enfin, sur les partitions système, qui garantit l’intégrité du filesystem en read-only.

Ce modèle n’a rien d’expérimental : c’est celui qu’embarquent déjà Android, ChromeOS, Flatcar et Talos. Il déplace la confiance depuis un parser fragile en pré-OS vers une chaîne mesurée et scellée par le matériel.

La direction de l’écosystème

La trajectoire est désormais claire : UKI, systemd-boot et TPM Measured Boot. GRUB reste là pour le legacy BIOS et il y restera encore un moment, mais pour tout ce qui relève de l’UEFI moderne il est en fin de vie. Arch, Fedora, Debian et Talos Linux y sont déjà ou en pleine transition.

Pour qui veut relier cela au reste de la chaîne, j’ai détaillé ailleurs le Secure Boot appliqué au PXE (voir secureboot-pxe ), le mot de passe GRUB géré par Foreman (voir foreman-grub-pass ) et le durcissement du filesystem (voir hardening-filesystem ), qui s’articulent naturellement avec ce que je décris ici.

De GRUB à l’UKI, sans magie

• Verrouiller l’édition des paramètres du boot est un vieux problème, mais l’outillage pour le résoudre vient de changer de génération.
• Le /boot chiffré via GRUB était un faux ami : son parser LUKS en pré-OS, sans ASLR ni sandboxing, a donné BootHole.
• Le drop de btrfs dans GRUB est discutable, car il reste utile au boot-to-snapshot.
• La réponse moderne à l’Evil Maid, c’est UKI plus Measured Boot/TPM plus dm-verity.
• La direction de l’écosystème UEFI est tranchée, GRUB ne subsiste que pour le legacy BIOS.