zbm-openwrt-clevis
Un ambiente di avvio basato su OpenWrt, compilato come un’unica UKI, che sblocca una root ZFS con cifratura nativa tramite clevis e il TPM e poi avvia il sistema Linux di destinazione attraverso un ambiente ZFSBootMenu donatore.
- OpenWrt
- ZFS
- TPM 2.0
- Clevis
- Stato
- Release con tag 0.90–0.95. La catena di avvio è validata in un laboratorio QEMU con OVMF e swtpm, avviando Ubuntu da ZFS cifrato.
- Licenza
- Non indicata: il repository non contiene un file di licenza.
- Piattaforme
- Macchine UEFI x86-64 con TPM 2.0 e rEFInd; OpenWrt 25.12 all’interno della UKI.
Quale problema risolve
ZFSBootMenu avvia bene ZFS cifrato, ma si aspetta che una persona digiti la chiave. Su un server remoto o su una macchina non presidiata questo non basta: l’operatore non può sapere se la richiesta appartiene all’ambiente di avvio di cui si fidava in precedenza. Qui la chiave viene rilasciata automaticamente solo finché le misure del TPM corrispondono allo stato approvato dall’operatore all’ultima risigillatura. Altrimenti l’avvio automatico si ferma, l’operatore riceve una notifica e un sistema OpenWrt protetto da password attende una decisione manuale.
Funzionalità principali
- Sblocco automatico legato ai PCR del TPM tramite
clevis; la policy validataclevis.pcr_ids=1,4,5,7,9copre anche la riga di comando del kernel passata da rEFInd. - Ripiego su un sistema OpenWrt completo con accesso tramite password o chiave SSH, non su una shell senza password;
rootè bloccato nell’immagine di base. - Sblocco manuale e risigillatura per un nuovo stato misurato da console o via SSH, anche tramite Wi-Fi o con due uplink WAN.
- Tre backend di archiviazione per il JWE sigillato: proprietà ZFS, variabili EFI o un file su una partizione VFAT.
- L’aggiornamento del kernel e dell’initramfs di destinazione non richiede un nuovo sblocco manuale: risiedono nel pool cifrato, fuori dall’ambiente misurato.
- Messaggio Telegram facoltativo quando lo sblocco automatico fallisce; strumenti di riparazione per dischi e rete nell’immagine.
Come funziona
rEFInd carica un’unica UKI OpenWrt e le passa la policy sulla riga di comando del kernel. All’avvio zbm-auto-boot esegue zbm-start; l’hook load-key chiede a clevis di recuperare la chiave e la consegna all’ambiente ZFSBootMenu donatore, che legge il kernel e l’initramfs di destinazione dalla root cifrata e li avvia con kexec. L’accesso automatico e quello manuale seguono lo stesso percorso e condividono un unico lock. Il pool viene importato in sola lettura, tranne una breve scrittura quando una risigillatura salva il risultato nelle proprietà ZFS.
UEFI → rEFInd → OpenWrt UKI → zbm-auto-boot → zbm-start
→ load-key hook / clevis → ZFSBootMenu → kexec → Ubuntu (ZFS)
Requisiti
- Un sistema di destinazione con root ZFS a cifratura nativa e chiave in un file (
keylocation=file://…). - UEFI, rEFInd come boot manager e un TPM 2.0; la policy si trova nella riga delle opzioni di rEFInd.
- Host di build: il flusso con OpenWrt ImageBuilder del repository,
ukify,refinde i consueti strumenti di build. - Laboratorio:
qemu-system-x86_64, OVMF eswtpm; la destinazione validata è Ubuntu su ZFS cifrato.
Questa pagina riassume il README e la documentazione del repository a ottobre 2026. La fonte di riferimento è il repository stesso.