Vue d’ensemble

OS immuable

Une seule image signée, bootée en A/B, mise à jour de façon atomique avec un verrou de santé et un rollback automatique.

SiHA n’exécute pas un Linux généraliste dans lequel vous vous connectez et que vous maintenez. Il exécute une unique image d’OS immuable : une racine squashfs en lecture seule, bootée sous UEFI SecureBoot appliqué, avec un minuscule superviseur en PID 1. Il n’y a ni SSH, ni systemd, ni cloud-init sur l’appliance — la surface d’attaque est délibérément réduite, et rien du système en exécution ne dérive.

A/B ATOMIC UPGRADESLOT Av1.4active · known-goodSLOT Bv1.5new image · stagedreboot → Bone-shot tryhealth gateprobe T=0 · T=2s✓ commitB becomes active↩ rollbackauto: back to AbootSIGNED BOOT CHAINUEFI SecureBoot›signed UKI›sd-boot›kernel · lockdown›squashfs · ro

Une image, deux emplacements

L’OS entier est livré comme un unique artefact versionné. Un nœud conserve deux emplacements d’image, A et B : l’un est actif et réputé sain, l’autre est libre. Vous ne patchez jamais le système en exécution en place — une mise à jour écrit une nouvelle image entière dans l’emplacement inactif. Parce que la racine est en lecture seule et adressée par contenu, deux nœuds sur la même version sont identiques octet pour octet, et « ce qui tourne » est toujours un unique numéro de version.

Mises à jour à verrou de santé, rollback automatique

Le changement de version est atomique et sûr par construction :

  1. La nouvelle image est écrite dans l’emplacement inactif (B).
  2. On demande au bootloader d’essayer B une seule fois — un boot one-shot, avec A toujours épinglé comme fallback par défaut.
  3. Le nœud redémarre sur B et le plan de contrôle exécute des sondes de santé.
  4. Sain → commit : B est marqué comme le nouveau défaut réputé sain. Non sain (ou aucune confirmation) → rollback automatique : le compteur de boot du bootloader expire et le nœud revient sur A, intact.

Le pire cas d’une mise à jour est donc un redémarrage supplémentaire pour revenir à la version que vous exécutiez déjà. Pas de jeux de paquets à moitié appliqués, pas de récupération manuelle.

La chaîne de boot signée

L’intégrité du chemin de boot est établie par des signatures, de bout en bout :

UEFI SecureBoot → signed UKI (noyau + initrd + cmdline dans une seule image signée) → sd-boot → kernel (en lockdown) → la racine squashfs en lecture seule.

Sous SecureBoot appliqué, le noyau entre en lockdown, ce qui explique aussi pourquoi le dataplane lie les cartes via l’IOMMU (vfio-pci) plutôt que via uio_pci_generic, bloqué par le lockdown — voir l’architecture et le billet DPDK.

Une variante de build de debug (SecureBoot désactivé) existe uniquement pour l’itération rapide — elle permet de hot-swapper un daemon sans reconstruire toute l’image. La variante release livrée est signée et appliquée.

Ce qui est livré aujourd’hui

Pour être précis sur le périmètre, la plateforme immuable fournit :

  • une chaîne de boot signée (UKI + sd-boot sous SecureBoot appliqué),
  • des mises à jour A/B atomiques à verrou de santé avec rollback automatique,
  • une surface d’attaque réduite : pas de SSH / systemd / cloud-init, racine en lecture seule.

L’intégrité du contenu racine par dm-verity et le chiffrement des données au repos par LUKS/TPM ne sont pas encore livrés — ils sont prévus pour un jalon ultérieur. Lisez le modèle actuel comme boot signé + mises à jour sûres + surface réduite, et non comme un boot-vérifié-du-contenu-racine ni un chiffrement au repos.