zbm-openwrt-clevis
Un environnement de démarrage basé sur OpenWrt, construit en un seul UKI, qui déverrouille une racine ZFS à chiffrement natif avec clevis et le TPM, puis démarre le système Linux cible via un environnement ZFSBootMenu donneur.
- OpenWrt
- ZFS
- TPM 2.0
- Clevis
- Statut
- Versions étiquetées 0.90–0.95. La chaîne de démarrage est validée dans un laboratoire QEMU avec OVMF et swtpm, en démarrant Ubuntu depuis un ZFS chiffré.
- Licence
- Non précisée : le dépôt ne contient pas de fichier de licence.
- Plateformes
- Machines UEFI x86-64 avec TPM 2.0 et rEFInd ; OpenWrt 25.12 dans l’UKI.
Le problème résolu
ZFSBootMenu démarre bien un ZFS chiffré, mais attend qu’une personne saisisse la clé. Pour un serveur distant ou une machine sans surveillance, cela ne suffit pas : l’opérateur ne peut pas savoir si l’invite appartient à l’environnement de démarrage auquel il faisait confiance auparavant. Ici, la clé n’est libérée automatiquement que tant que les mesures du TPM correspondent à l’état approuvé par l’opérateur lors du dernier rescellement. Sinon, le démarrage automatique s’arrête, l’opérateur est prévenu et un système OpenWrt protégé par mot de passe attend une décision manuelle.
Fonctionnalités principales
- Déverrouillage automatique lié aux PCR du TPM via
clevis; la politique validéeclevis.pcr_ids=1,4,5,7,9couvre aussi la ligne de commande du noyau transmise par rEFInd. - Repli sur un système OpenWrt complet avec connexion par mot de passe ou clé SSH, et non sur un shell sans mot de passe ;
rootest verrouillé dans l’image de base. - Déverrouillage manuel et rescellement pour un nouvel état mesuré via la console ou SSH, y compris en Wi-Fi ou avec deux liens WAN.
- Trois emplacements de stockage pour le JWE scellé : propriétés ZFS, variables EFI ou fichier sur une partition VFAT.
- Mettre à jour le noyau et l’initramfs du système cible ne demande pas de nouveau déverrouillage manuel : ils se trouvent dans le pool chiffré, hors de l’environnement mesuré.
- Message Telegram optionnel en cas d’échec du déverrouillage automatique ; outils de réparation des disques et du réseau dans l’image.
Fonctionnement
rEFInd charge un seul UKI OpenWrt et lui transmet la politique sur la ligne de commande du noyau. Au démarrage, zbm-auto-boot lance zbm-start ; le hook load-key demande à clevis de récupérer la clé et la remet à l’environnement ZFSBootMenu donneur, qui lit le noyau et l’initramfs cibles sur la racine chiffrée et les lance avec kexec. Les entrées automatique et manuelle suivent le même chemin et partagent un même verrou. Le pool est importé en lecture seule, sauf pour une courte écriture lorsqu’un rescellement enregistre son résultat dans les propriétés ZFS.
UEFI → rEFInd → OpenWrt UKI → zbm-auto-boot → zbm-start
→ load-key hook / clevis → ZFSBootMenu → kexec → Ubuntu (ZFS)
Prérequis
- Un système cible sur une racine ZFS à chiffrement natif, avec une clé lue depuis un fichier (
keylocation=file://…). - UEFI, rEFInd comme gestionnaire de démarrage et un TPM 2.0 ; la politique se trouve sur la ligne options de rEFInd.
- Hôte de build : le processus OpenWrt ImageBuilder du dépôt,
ukify,refindet les outils de build habituels. - Laboratoire :
qemu-system-x86_64, OVMF etswtpm; la cible validée est Ubuntu sur ZFS chiffré.
Cette page résume le README et la documentation du dépôt à la date d’octobre 2026. La référence reste le dépôt lui-même.