Le résultat démarré confirme également le blocage de la politique Bazzite : aucun fichier UKI ni signal systemd-stub n'était présent, les arguments de confinement prévus étaient absents, et les PCR 11 et 15 sont restées à zéro. La PCR 12 était également à zéro, mais ce n'est pas un échec indépendant : la ligne de commande UKI intégrée appartient à la PCR 11, tandis que la PCR 12 enregistre les entrées externes de ligne de commande et peut rester correctement à zéro lorsqu'aucune n'est fournie. L'enrôlement des clés Secure Boot, la mesure de ligne de commande adossée à l'UKI, la provenance matérielle, le rejeu du journal des événements, la liaison de transport et l'admission de la politique de démarrage restent non résolus. Aucune des deux exécutions vertes n'établit un système d'attestation de production fonctionnel.

Un contrôle positif séparé d'image Fedora scellée a réussi deux fois dans run 31218059725 et de nouveau sur la tête de source fusionnée dans run 31219745053. Il prouve que le harnais peut démarrer une UKI immuable signée en amont, joindre le chemin sélectionné par le firmware et le hash du fichier chargé à l'inspection pré-démarrage, observer une PCR 11 non nulle et rejeter une mutation .cmdline non signée. C'est uniquement un contrôle du harnais : tous les indicateurs de confiance fabricant, politique et production restent faux, et cela ne rend pas l'aperçu Bazzite installable.

Le volet séparé d'ajout de politique PCR 12 signé a ensuite réussi deux fois sur run 31234464516. L'UKI amont et la PCR 11 sont restées octet pour octet identiques ; les deux démarrages signés ont appliqué lockdown=confidentiality module.sig_enforce=1 exactement une fois et reproduit la PCR 12 ca62dd5f...a8f5 ; la falsification après signature a été rejetée et le système est revenu à la ligne de base PCR 12 à zéro. Cela prouve un mécanisme borné, et non une hiérarchie de clés déployable ni une politique de confiance du système d'exploitation.

Ce code source est disponible pour examen et émulation reproductible. Aucune image GHCR n'est publiée et il ne s'agit pas d'une distribution de confiance installable.

L'expérience Bazzite terminée est spécifiée dans BOOTED_IMAGE_CANARY.md. Les instructions de reproduction et de construction depuis les sources sont dans BUILDING.md. Les preuves de base UKI et ses critères d'admission indépendants sont consignés dans UKI_BASE_DECISION.md. L'expérience d'ajout de politique PCR 12 signé est spécifiée séparément dans FEDORA_PCR12_ADDON_CANARY.md. L'ordre des jalons et les règles d'arrêt sont suivis dans ROADMAP.md. Le contrôle séparé du harnais UKI chargé est spécifié dans FEDORA_SEALED_POSITIVE_CONTROL.md.

Ce que cela ajoute à Bazzite

Rien n'est supprimé et rien n'est patché. Quatre éléments s'ajoutent par-dessus :

1. tpm2-tools et tpm2-tss, dont l'agent a besoin à l'exécution.
2. Une ligne de commande noyau dans /usr/lib/attestos/cmdline portant lockdown=confidentiality et module.sig_enforce=1.
3. attestos-provision, une unité one-shot qui crée des identités RSA EK et AK persistantes distinctes dans le TPM et lit le certificat d'attestation depuis le stockage NV lorsqu'il existe.
4. attestos-agent, activé par socket sur loopback, qui répond à un défi strict attestos.tpm/v1 d'identité, d'activation ou de citation avec des preuves TPM brutes. L'agent ne rend jamais de verdict de confiance.

Pourquoi la base est Bazzite

Bazzite est dérivée de Fedora, et la famille Fedora est ce que les listes blanches anti-triche bloquent actuellement. Prouver que l'attestation fonctionne ici est le cas qui vaut la peine d'être prouvé. Construire sur SteamOS ne démontrerait rien, car SteamOS est déjà autorisé ; une démonstration réussie là-bas n'obtiendrait donc qu'un accès qu'il possède déjà.

Bazzite est également conçue pour être superposée. C'est une image OCI, donc ce dépôt est un Containerfile et une GitHub Action plutôt qu'une distribution avec des miroirs et des installateurs derrière elle.

La politique doit être authentifiée et mesurée avant le noyau

C'est la partie qui décide si tout cela signifie quelque chose. lockdown=confidentiality bloque /dev/mem, les kprobes contre un noyau en cours d'exécution et le chargement de modules non signés. Cette garantie ne vaut rien si la politique ne réside que dans une configuration de bootloader que l'utilisateur peut modifier. Sinon, un utilisateur peut supprimer les arguments, démarrer avec la même mesure de noyau et présenter une citation qui ne dit rien de la politique manquante.

Une Unified Kernel Image lie le noyau, l'initrd et sa ligne de commande intégrée dans un seul binaire PE signé mesuré dans la PCR 11. Un add-on de ligne de commande systemd signé séparément peut étendre une politique supplémentaire dans la PCR 12 tout en laissant cette UKI amont inchangée. Chaque voie doit être reliée à l'artefact exactement chargé et rejouée par le vérificateur ; la présence d'un fichier ou une PCR non nulle ne suffit pas.

Bazzite ne fait pas d'UKI, et c'est désormais confirmé plutôt que soupçonné. Son Containerfile exclut activement les paquets noyau UKI :

systemd-ukify n'apparaît nulle part dans le dépôt. Le fichier cmdline fourni par cette image n'est donc actuellement qu'une déclaration d'intention et rien de plus : sans UKI, rien ne le scelle, un utilisateur peut le modifier au bootloader, et la PCR 11 ne mesure pas ce que la conception suppose qu'elle mesure.

Corriger Bazzite n'est pas une ligne dans build.sh. Cela nécessite un chemin de mesure pré-noyau de confiance, que ce soit en changeant la façon dont l'image démarre ou en adoptant une base qui démarre déjà via systemd-stub.

Les expériences réduisent les choix pratiques :

1. Faire le travail UKI sur Bazzite quand même et accepter la divergence par rapport à la base.
2. Utiliser une UKI Fedora scellée en amont et ajouter la politique attestos via un add-on systemd signé séparément et mesuré dans la PCR 12.
3. Trouver un autre chemin de mesure pré-noyau authentifié. Une mesure effectuée seulement après le démarrage du noyau est une classe de preuve plus faible et ne doit pas être présentée comme équivalente.

Le problème d'admission des clés, non résolu

Une UKI Fedora amont peut conserver sa signature de distribution, mais un add-on de politique attestos séparé a toujours besoin d'une clé de signature admise par le firmware, Shim ou MOK. Un noyau tiers a la version plus grande du même problème. Les options de déploiement sont :

• Enrôlement MOK, où l'utilisateur enrôle une Machine Owner Key via un écran de firmware bleu au premier démarrage. Universal Blue le fait déjà pour les modules noyau hors arbre, donc la mécanique existe, mais cela change la revendication de « Microsoft se porte garant de ce noyau » à « l'utilisateur fait explicitement confiance à cette clé », et un éditeur doit décider si cela est acceptable.
• Un shim signé par Microsoft, qui est la voie qu'emprunte une vraie distribution et qui est un processus de revue plutôt qu'un formulaire.
• PK et KEK appartenant à l'utilisateur, ce qui donne un contrôle total et presque aucune adoption.

Le harnais Fedora jetable enrôle un certificat local à l'exécution dans une base UEFI DB copiée et prouve le mécanisme sans revendiquer de modèle de déploiement. Il n'existe toujours pas de contrat accepté d'enrôlement, de révocation ou de récupération de clé pour l'utilisateur final. C'est une question de partie de confiance autant qu'une question d'ingénierie.

Installation

Il n'existe pas encore de commande d'installation prise en charge. En particulier, ghcr.io/plunder707/attestos:latest n'est pas publiée. L'aperçu actuel est réservé à l'examen des sources et à la reproduction isolée sous QEMU/swtpm uniquement. Voir BUILDING.md.

Structure

Tout ce qui se trouve en dehors de build_files/ et system_files/ provient de ublue-os/image-template et est leur travail.

Ce qui reste à résoudre

• L'image se construit-elle seulement. Confirmé pour le commit 14e3a21 par l'exécution GitHub Actions 31143048491 ; la construction a émis deux avertissements de lint d'état DNF non fatals.
• Comment un vérificateur transforme la revendication de déploiement bootc status de l'agent à l'exécution en identité d'image vérifiée. La revendication est des métadonnées, pas une autorité signée ; sur les systèmes sans bootc, elle vaut explicitement unavailable.
• La QCOW2 dérivée de Bazzite passe le canari des mécanismes isolés, mais ses observations négatives d'UKI et de confinement la retiennent de l'admission de politique.
• Si l'add-on de politique PCR 12 signé séparément reste reproductible sous les mises à jour, les rollbacks, l'ordonnancement alterné et un cycle de vie de clé de production. Le harnais figé à politique unique passe désormais ; ces cas de cycle de vie ne passent pas.
• Comment construire l'agent et la politique dans un candidat scellé, vérifier une citation signée hors de l'invité et rejouer les journaux d'événements pertinents.
• La PCR 15 est-elle peuplée comme la conception le suppose sur une racine bootc.
• L'enrôlement MOK produit-il une valeur de PCR 7 suffisamment stable pour écrire une politique basée dessus.
• Un éditeur accepterait-il une hiérarchie de clés enrôlées via MOK.

Les questions de mesure à l'exécution nécessitent QEMU avec OVMF et swtpm, ce qui ne requiert aucun matériel supplémentaire. Le câblage et les mécanismes du protocole TPM brut y sont désormais validés, mais démarrer l'image construite et valider son journal des événements et sa politique restent des expériences distinctes. L'acceptation par un éditeur nécessite une conversation avec l'éditeur concerné.

Licence

Apache-2.0, conforme au modèle sur lequel ceci est construit.