ADR-014 — Catalogue de matériel « Air long-term »

Statut : Accepté — document fondateur. Édition directe autorisée en phase de design pré-ouverture publique ; immuable après ouverture publique (toute évolution via RFC, ADR-015). Catégorie : Méthode (support matériel, garantie de longévité).

Contexte

Promettre qu’un système « fonctionne sur Linux » n’engage à rien : le parc est trop vaste pour être testé, et l’affirmation se vérifie rarement.

Air revendique la durabilité. Pour que cette revendication soit autre chose qu’un slogan, il faut nommer les machines sur lesquelles elle est tenue, et s’y tenir.

Décision

Air maintient un catalogue de machines explicitement testées et garanties supportées pour au moins 10 ans à partir de leur sortie commerciale ou de leur abandon par le fabricant d’origine, le plus tardif des deux. Tests automatisés en CI sur chaque machine du catalogue à chaque version.

Première version du catalogue (Phase 0) :

• Raspberry Pi 4 Model B 4 Go (ARM64) — référence air-base.
• Raspberry Pi 4 Model B 8 Go (ARM64) — référence air-desktop.
• Mac mini Intel i5 8 Go (x86_64, GPU Intel intégré) — référence air-desktop bureautique.
• MacBook Pro 17“ Intel i7 16 Go (x86_64, GPU Intel + discret) — référence air-desktop laptop.

Diversité couverte : ARM64 + x86_64, profils mémoire 4 à 16 Go, GPU variés, écrans externes et intégrés, classes SBC à laptop puissant.

Versions ultérieures candidates : MacBook Pro Intel (2015, 2017, 2019), ThinkPad T-series, Framework Laptop, Intel NUC, Dell XPS, Raspberry Pi 5.

Conséquences

Critères d’inclusion : disponibilité raisonnable, support kernel mainline, contributeur engagé pour maintenir les tests.

Engagement : machine entrée ne sort qu’en cas de force majeure, avec préavis 2 ans et décision motivée.

Alternatives rejetées

Aucune alternative n’a été consignée lors de l’instruction.

Amendement — confiance matérielle : hiérarchie, refus de l’OTP Raspberry Pi, information de l’utilisateur (2026-08-02)

Statut : Accepté (2026-08-02, décision BDFL). Complète la Décision ci-dessus d’une dimension qu’elle ne portait pas — le catalogue nommait les machines supportées sans rien dire du niveau de confiance matérielle qu’elles permettent. Ne retire aucune machine du catalogue, et ne modifie ni les critères d’inclusion, ni l’engagement de dix ans, ni le statut tier-1 d’aarch64 (ADR-004, « Linux tier-1 exclusif »).

Contexte

Le modèle de mise à jour système envisagé pour Air — image A/B montée en lecture seule et protégée par dm-verity, chargeur de démarrage vérifiant un emplacement avant de le démarrer — repose entièrement sur l’existence d’une racine de confiance ancrée dans le matériel. Le catalogue ne disait pas laquelle de ses machines en fournit une. L’étude « Démarrage vérifié sur Raspberry Pi » a instruit la question pour la plateforme aarch64 du catalogue.

Décision

1. Trois niveaux de confiance matérielle, à déclarer pour chaque machine du catalogue :

2. Air ne programme jamais les fusibles OTP d’un Raspberry Pi. Le mécanisme officiel existe (RSA 2048, empreinte de clé publique en OTP), mais son activation est irréversible et la clé n’est ni rotative ni révocable — la documentation Raspberry Pi ne décrit aucun mécanisme de rotation. Une clé compromise lierait définitivement un parc à cette clé. Incompatible avec un projet qui promet dix ans de stabilité contractuelle. Le Raspberry Pi est donc, et restera, au niveau non ancré.

3. Le Pi reste au catalogue, à double titre : cible de validation aarch64 du projet, et cible sur laquelle un utilisateur final peut choisir d’installer Air. Dans ce second cas, le projet ne garantit aucune protection contre un adversaire disposant d’un accès physique au support de démarrage.

4. L’utilisateur est informé deux fois — au téléchargement de l’image, et à l’installation. L’avertissement doit être précis : « aucune garantie de sécurité » serait inexact et contre-productif, puisque l’essentiel du modèle de sécurité d’Air continue de fonctionner (cf. Conséquences). Libellé de référence :

Air protège votre machine contre les logiciels malveillants qui s’y exécutent. Sur Raspberry Pi, il ne peut pas vous protéger contre quelqu’un qui a un accès physique à la carte SD, ni chiffrer vos données.

5. L’accès physique n’est pas dans le modèle de menace du Raspberry Pi, et Air ne fournit pas de chiffrement de disque sur cette plateforme.

6. La partition de démarrage fait partie du système, pas des données. Sur Pi, c’est une FAT en clair non vérifiée, et elle porte le noyau et sa ligne de commande — donc la racine dm-verity. Quiconque peut y écrire défait dm-verity sans toucher au système. Le gestionnaire de paquets ne doit en aucun cas pouvoir y écrire ; le mécanisme (non montée, montée en lecture seule, ou interdite par Landlock) reste à choisir.

7. Si le projet revenait un jour sur le point 2, la mise au point se ferait sur Pi 4 ou CM4 — seules plateformes où la chaîne se teste sans programmer l’OTP.

Constat : aucune machine du catalogue n’est aujourd’hui au niveau ancré

Il faut l’écrire, sous peine de laisser croire à une garantie qui n’existe pas. Les deux entrées x86_64 du catalogue sont du matériel Apple Intel, dont la chaîne de démarrage n’offre pas de racine de confiance exploitable pour Linux : les Mac Intel antérieurs à la puce T2 n’ont aucune implémentation de démarrage vérifié pour un système tiers, et sur les modèles à T2, démarrer Linux exige précisément de désactiver la sécurité de démarrage. Les deux entrées aarch64 sont des Raspberry Pi, délibérément non provisionnés par le point 2.

Conséquence : atteindre le niveau ancré exigera d’ajouter au catalogue une machine disposant d’un UEFI Secure Boot utilisable — plusieurs des candidats déjà listés (ThinkPad T-series, Framework Laptop, Intel NUC, Dell XPS) conviennent. C’est un prérequis de toute promesse de chaîne de démarrage vérifiée, et ce n’est pas tranché ici.

Conséquences

Un chantier entier sort du plan. Le point 2 supprime : l’outillage OTP, le provisionnement machine par machine, l’infrastructure de signature d’images de démarrage Pi, et la contre-signature exigée par le Pi 5.

Ce qui tient malgré tout sur une machine non ancrée — l’essentiel, car le modèle de sécurité d’Air repose sur le noyau et non sur la chaîne de démarrage :

La propriété visée par la séparation « gestionnaire de paquets / mise à jour système » — un attaquant corrompt des applications, jamais le système — tient donc sur une machine non ancrée, à condition que le point 6 soit respecté.

La confiance matérielle est une dimension distincte du support. Une machine non ancrée reste pleinement supportée, testée en CI et couverte par l’engagement de dix ans. Elle n’offre simplement pas la même garantie d’intégrité au démarrage.

Alternatives rejetées

• Programmer les fusibles OTP du Pi pour obtenir le niveau ancré contraint. Rejeté : irréversible, clé non rotative sur dix ans, et l’accès physique n’est pas dans le modèle de menace de cette plateforme — on paierait un mécanisme définitif pour une menace hors périmètre.
• Un portage UEFI (EDK2) ou un GRUB aarch64 sur Pi. Rejeté : ce firmware est chargé depuis la carte SD par la chaîne native du Pi ; sans ancrage OTP, on le remplace, avec son Secure Boot. Du logiciel qui vérifie du logiciel ne fait que déplacer la question.
• Un TPM externe en substitut du démarrage vérifié. Rejeté comme substitut : un TPM fait du démarrage mesuré (on constate l’altération après coup), pas vérifié (on refuse d’exécuter). Il reste pertinent, mais pour une autre propriété — le scellement de secrets —, écartée ici par le point 5.

Licence du document : MPL 2.0