Nous venons de lancer le service. Le site et le service sont encore en cours de finition : nous vous prions d’excuser d’avance d’éventuelles imprécisions ou maladresses. Vous avez repéré une erreur ou quelque chose ne fonctionne pas comme prévu ? Écrivez-nous, nous corrigerons rapidement.

← Tous les projets
FR
Au-delà de TAKT

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ée clevis.pcr_ids=1,4,5,7,9 couvre 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 ; root est 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, refind et les outils de build habituels.
  • Laboratoire : qemu-system-x86_64, OVMF et swtpm ; 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.