El resultado arrancado también confirma el bloqueo de política de Bazzite: no había ningún archivo UKI ni señal de systemd-stub, faltaban los argumentos de bloqueo previstos, y los PCR 11 y 15 seguían en cero. El PCR 12 también estaba en cero, pero eso no es un fallo independiente: la línea de comandos UKI integrada pertenece al PCR 11, mientras que el PCR 12 registra entradas de línea de comandos externas y puede permanecer correctamente en cero cuando no se suministra ninguna. La inscripción de claves de Secure Boot, la medición de línea de comandos respaldada por UKI, la procedencia del hardware, la reproducción del registro de eventos, la vinculación del transporte y la admisión por política de arranque siguen sin resolverse. Ninguna de las dos ejecuciones en verde establece un sistema de atestación de producción funcional.

Un control positivo separado de imagen sellada de Fedora pasó dos veces en run 31218059725 y de nuevo en la cabecera de la fuente fusionada en run 31219745053. Demuestra que el harness puede arrancar un UKI inmutable firmado por el proyecto ascendente, incorporar la ruta seleccionada por el firmware y el hash del archivo cargado a la inspección previa al arranque, observar un PCR 11 distinto de cero y rechazar una mutación de .cmdline sin firmar. Esto es solo un control del harness: todas las marcas de confianza de fabricante, política y producción siguen siendo falsas, y no hace instalable la vista previa de Bazzite.

El carril separado de complemento de política PCR 12 firmado pasó después dos veces en run 31234464516. El UKI ascendente y el PCR 11 permanecieron byte-idénticos; ambos arranques firmados aplicaron lockdown=confidentiality module.sig_enforce=1 exactamente una vez y reprodujeron el PCR 12 ca62dd5f...a8f5; la manipulación posterior a la firma fue rechazada y se volvió a la línea base de PCR 12 en cero. Esto prueba un mecanismo acotado, no una jerarquía de claves desplegable ni una política de confianza del sistema operativo.

Este código fuente está disponible para revisión y emulación reproducible. No se publica ninguna imagen GHCR y no es una distribución confiable instalable.

El experimento completado de Bazzite se especifica en BOOTED_IMAGE_CANARY.md. Las instrucciones de reproducción y construcción desde el código fuente están en BUILDING.md. La evidencia base del UKI y sus criterios independientes de admisión se registran en UKI_BASE_DECISION.md. El experimento firmado del complemento de política PCR 12 se especifica por separado en FEDORA_PCR12_ADDON_CANARY.md. El orden de hitos y las reglas de parada se controlan en ROADMAP.md. El control del harness de UKI cargado por separado se especifica en FEDORA_SEALED_POSITIVE_CONTROL.md.

Qué añade esto a Bazzite

No se elimina nada y no se parchea nada. Se añaden cuatro cosas encima:

1. tpm2-tools y tpm2-tss, que el agente necesita en tiempo de ejecución.
2. Una línea de comandos de kernel en /usr/lib/attestos/cmdline con lockdown=confidentiality y module.sig_enforce=1.
3. attestos-provision, una unidad de una sola pasada que crea identificadores persistentes distintos de EK y AK RSA dentro del TPM y lee el certificado de respaldo del almacenamiento NV cuando existe.
4. attestos-agent, activado por socket en bucle local, que responde a un desafío estricto de identidad, activación o cita attestos.tpm/v1 con evidencia TPM cruda. El agente nunca emite un veredicto de confianza.

Por qué la base es Bazzite

Bazzite se deriva de Fedora, y la familia Fedora es lo que las listas de permisos de anti-trampas bloquean actualmente. Demostrar que la atestación funciona aquí es el caso que vale la pena demostrar. Construir sobre SteamOS no demostraría nada, porque SteamOS ya está permitido, por lo que una demo exitosa allí conseguiría un acceso que ya tiene.

Bazzite también está diseñado para ser superpuesto en capas. Es una imagen OCI, así que este repositorio es un Containerfile y una Acción de GitHub en lugar de una distribución con espejos e instaladores detrás.

La política tiene que estar autenticada y medida antes del kernel

Esta es la parte que decide si todo esto significa algo. lockdown=confidentiality bloquea /dev/mem, los kprobes contra un kernel en ejecución y la carga de módulos sin firmar. Esa garantía no vale nada si la política vive solo en una configuración de cargador de arranque que el usuario puede editar. De lo contrario, un usuario puede eliminar los argumentos, arrancar la misma medición de kernel y presentar una cita que no dice nada sobre la política ausente.

Una imagen de kernel unificada (UKI) vincula kernel, initrd y su línea de comandos integrada en un único binario PE firmado medido en el PCR 11. Un complemento de línea de comandos de systemd firmado por separado puede extender política adicional al PCR 12 dejando ese UKI ascendente sin cambios. Cualquiera de las dos rutas debe unirse al artefacto cargado exacto y ser reproducida por el verificador; la presencia de un archivo o un PCR distinto de cero no basta.

Bazzite no usa UKI, y esto ahora está confirmado en lugar de sospechado. Su Containerfile excluye activamente los paquetes de kernel UKI:

systemd-ukify no aparece en ningún lugar del repositorio. Así que el archivo cmdline que esta imagen incluye es actualmente una declaración de intención y nada más: sin un UKI no hay nada que lo selle, un usuario puede editarlo en el cargador de arranque, y el PCR 11 no mide lo que el diseño supone que mide.

Arreglar Bazzite no es una línea en build.sh. Requiere una ruta de medición pre-kernel confiable, ya sea cambiando cómo arranca la imagen o adoptando una base que ya arranca a través de systemd-stub.

Los experimentos reducen las opciones prácticas:

1. Hacer el trabajo UKI en Bazzite de todos modos y aceptar la divergencia con la base.
2. Usar un UKI sellado de Fedora ascendente y añadir política de attestos a través de un complemento de systemd firmado por separado y medido en el PCR 12.
3. Encontrar otra ruta autenticada de medición pre-kernel. Una medición hecha solo después de que el kernel arranque es una clase de evidencia más débil y no debe presentarse como equivalente.

El problema de la admisión de claves, sin resolver

Un UKI ascendente de Fedora puede conservar su firma de distribución, pero un complemento de política de attestos separado aún necesita una clave de firma admitida por el firmware, Shim o MOK. Un kernel de terceros tiene la versión más grande del mismo problema. Las opciones de despliegue son:

• Inscripción MOK, donde el usuario inscribe una Machine Owner Key a través de una pantalla azul de firmware en el primer arranque. Universal Blue ya hace esto para módulos de kernel fuera del árbol, así que la maquinaria existe, pero cambia la afirmación de "Microsoft avala este kernel" a "el usuario confía explícitamente en esta clave", y un proveedor tiene que decidir si eso es aceptable.
• Un shim firmado por Microsoft, que es el camino que toma una distribución real y es un proceso de revisión más que un formulario.
• PK y KEK propiedad del usuario, que da control total y casi ninguna adopción.

El harness desechable de Fedora inscribe un certificado local de la ejecución en una DB UEFI copiada y prueba el mecanismo sin reclamar un modelo de despliegue. Todavía no hay un contrato aceptado de inscripción, revocación o recuperación de claves para el usuario final. Es tanto una cuestión de la parte que confía como de ingeniería.

Instalarlo

Todavía no hay un comando de instalación soportado. En particular, ghcr.io/plunder707/attestos:latest no está publicado. La vista previa actual es solo para revisión del código fuente y reproducción aislada con QEMU/swtpm. Ver BUILDING.md.

Estructura

Todo lo que está fuera de build_files/ y system_files/ proviene de ublue-os/image-template y es su trabajo.

Lo que aún tiene que responderse

• Si la imagen construye en absoluto. Confirmado para el commit 14e3a21 por la ejecución 31143048491 de GitHub Actions; la construcción emitió dos advertencias no fatales de lint del estado de DNF.
• Cómo un verificador convierte la afirmación de despliegue de bootc status del agente en tiempo de ejecución en identidad de imagen verificada. La afirmación es metadatos, no autoridad firmada; en sistemas sin bootc es explícitamente unavailable.
• El QCOW2 derivado de Bazzite supera el canario de mecánica aislada, pero sus observaciones negativas de UKI y bloqueo lo retienen de la admisión por política.
• Si el complemento de política PCR 12 firmado por separado sigue siendo reproducible bajo actualizaciones, reversión, orden alternativo y un ciclo de vida de claves de producción. El harness congelado de política única ahora pasa; estos casos de ciclo de vida no.
• Cómo construir el agente y la política en un candidato sellado, verificar una cita firmada fuera del invitado y reproducir los registros de eventos relevantes.
• Si el PCR 15 está poblado como supone el diseño en una raíz bootc.
• Si la inscripción MOK produce un valor de PCR 7 lo suficientemente estable como para escribir una política contra él.
• Si un proveedor aceptaría una jerarquía de claves inscrita por MOK.

Las preguntas de medición en tiempo de ejecución requieren QEMU con OVMF y swtpm, lo que no necesita hardware adicional. El cableado y la mecánica del protocolo TPM crudo ya han pasado allí, pero arrancar la imagen construida y validar su registro de eventos y política siguen siendo experimentos separados. La aceptación del proveedor requiere una conversación con el proveedor.

Licencia

Apache-2.0, en correspondencia con la plantilla sobre la que está construido.