O resultado inicializado também confirma o bloqueio de política do Bazzite: nenhum arquivo UKI ou sinal de systemd-stub estava presente, os argumentos de lockdown pretendidos estavam ausentes e os PCRs 11 e 15 permaneceram zerados. O PCR 12 também estava zerado, mas isso não é uma falha independente: a linha de comando UKI embutida pertence ao PCR 11, enquanto o PCR 12 registra entradas externas de linha de comando e pode, corretamente, permanecer zerado quando nenhuma é fornecida. O registro de chaves do Secure Boot, a medição de linha de comando baseada em UKI, a proveniência de hardware, o replay do event log, a vinculação de transporte e a admissão de política de inicialização continuam sem solução. Nenhuma das execuções verdes estabelece um sistema de atestação de produção funcional.

Um controle positivo separado com imagem selada do Fedora passou duas vezes em execução 31218059725 e novamente no head do código-fonte mesclado em execução 31219745053. Ele prova que o harness consegue inicializar uma UKI imutável assinada pela upstream, unir o caminho selecionado pelo firmware e o hash do arquivo carregado à inspeção de pré-inicialização, observar PCR 11 não zerado e rejeitar uma mutação não assinada do .cmdline. Isso é apenas um controle do harness: todas as flags de confiança de fabricante, de política e de produção permanecem falsas, e isso não torna a prévia do Bazzite instalável.

O lane separado do add-on de política PCR 12 assinado passou duas vezes em execução 31234464516. O UKI da upstream e o PCR 11 permaneceram byte-idênticos; ambas as inicializações assinadas aplicaram lockdown=confidentiality module.sig_enforce=1 exatamente uma vez e reproduziram o PCR 12 ca62dd5f...a8f5; a adulteração pós-assinatura foi rejeitada e o sistema retornou à linha de base de PCR 12 zerado. Isso prova um mecanismo delimitado, não uma hierarquia de chaves implantável ou uma política de confiança de sistema operacional.

Este código-fonte está disponível para revisão e emulação reproduzível. Nenhuma imagem GHCR é publicada e ele não é uma distribuição confiável instalável.

O experimento Bazzite concluído está especificado em BOOTED_IMAGE_CANARY.md. As instruções de reprodução e de construção a partir do código-fonte estão em BUILDING.md. As evidências base do UKI e seus critérios independentes de admissão estão registradas em UKI_BASE_DECISION.md. O experimento assinado de add-on de política PCR 12 está especificado separadamente em FEDORA_PCR12_ADDON_CANARY.md. A ordem dos marcos e as regras de parada são acompanhadas em ROADMAP.md. O controle separado do harness de UKI carregado está especificado em FEDORA_SEALED_POSITIVE_CONTROL.md.

O que isto adiciona ao Bazzite

Nada é removido e nada recebe patch. Quatro coisas entram por cima:

1. tpm2-tools e tpm2-tss, que o agente precisa em tempo de execução.
2. Uma linha de comando do kernel em /usr/lib/attestos/cmdline contendo lockdown=confidentiality e module.sig_enforce=1.
3. attestos-provision, uma unit one-shot que cria identidades RSA persistentes distintas de EK e AK dentro do TPM e lê o certificado de endosso do armazenamento NV quando um existe.
4. attestos-agent, ativado por socket em loopback, que responde a um desafio estrito de identidade, ativação ou quote attestos.tpm/v1 com evidências TPM brutas. O agente nunca retorna um veredito de confiança.

Por que a base é o Bazzite

O Bazzite é derivado do Fedora, e a família Fedora é o que as whitelists de anti-cheat bloqueiam atualmente. Provar que a atestação funciona aqui é o caso que vale a pena provar. Construir sobre o SteamOS não demonstraria nada, porque o SteamOS já é permitido; portanto, uma demonstração bem-sucedida lá conquistaria um acesso que ele já tem.

O Bazzite também é projetado para ser usado em camadas (layered). É uma imagem OCI, então este repositório é um Containerfile e uma GitHub Action, em vez de uma distribuição com mirrors e instaladores por trás.

A política precisa ser autenticada e medida antes do kernel

Esta é a parte que decide se tudo isso significa alguma coisa. lockdown=confidentiality bloqueia /dev/mem, kprobes contra um kernel em execução e o carregamento de módulos não assinados. Essa garantia não vale nada se a política existir apenas em uma configuração do bootloader que o usuário pode editar. Caso contrário, um usuário pode remover os argumentos, inicializar com a mesma medição de kernel e apresentar uma quote que não diz nada sobre a política ausente.

Uma Unified Kernel Image (UKI) une kernel, initrd e sua linha de comando embutida em um único binário PE assinado, medido no PCR 11. Um add-on de linha de comando do systemd assinado separadamente pode estender política adicional ao PCR 12, deixando a UKI da upstream inalterada. Qualquer um dos caminhos precisa ser vinculado ao artefato exato carregado e reproduzido (replay) pelo verificador; a presença do arquivo ou um PCR não zerado não é suficiente.

O Bazzite não usa UKI, e isto agora é confirmado em vez de suspeitado. Seu Containerfile exclui ativamente os pacotes de kernel UKI:

systemd-ukify não aparece em lugar nenhum do repositório. Portanto, o arquivo cmdline que esta imagem entrega é, atualmente, uma declaração de intenção e nada mais: sem uma UKI não há nada o selando, um usuário pode editá-lo no bootloader, e o PCR 11 não mede o que o design presume que ele mede.

Corrigir o Bazzite não é uma linha em build.sh. Exige um caminho confiável de medição pré-kernel, seja mudando como a imagem inicializa ou adotando uma base que já inicializa por meio do systemd-stub.

Os experimentos restringem as escolhas práticas:

1. Fazer o trabalho de UKI no Bazzite mesmo assim e aceitar a divergência em relação à base.
2. Usar uma UKI selada do Fedora da upstream e adicionar a política do attestos por meio de um add-on do systemd assinado separadamente, medido no PCR 12.
3. Encontrar outro caminho autenticado de medição pré-kernel. Uma medição feita apenas depois que o kernel inicia é uma classe de evidência mais fraca e não deve ser apresentada como equivalente.

O problema de admissão de chaves, sem solução

Uma UKI Fedora da upstream pode manter sua assinatura de distribuição, mas um add-on de política do attestos ainda precisa de uma chave de assinatura admitida pelo firmware, Shim ou MOK. Um kernel de terceiros tem a versão maior do mesmo problema. As opções de implantação são:

• Registro de MOK (MOK enrollment), em que o usuário registra uma Machine Owner Key por meio de uma tela azul do firmware no primeiro boot. A Universal Blue já faz isso para módulos de kernel fora da árvore, então a maquinaria existe, mas isso muda a afirmação de “a Microsoft garante este kernel” para “o usuário confia explicitamente nesta chave”, e um fornecedor precisa decidir se isso é aceitável.
• Um shim assinado pela Microsoft, que é o caminho que uma distribuição real toma e é um processo de revisão, em vez de um formulário.
• PK e KEK de propriedade do usuário, o que dá controle total e quase nenhuma adoção.

O harness Fedora descartável registra um certificado local à execução em uma UEFI DB copiada e prova o mecanismo sem reivindicar um modelo de implantação. Ainda não há um contrato aceito de registro, revogação ou recuperação de chaves para o usuário final. Isso é tanto uma questão de parte confiante (relying party) quanto de engenharia.

Instalando

Ainda não existe um comando de instalação suportado. Em particular, ghcr.io/plunder707/attestos:latest não é publicada. A prévia atual é apenas para revisão do código-fonte e reprodução isolada com QEMU/swtpm. Consulte BUILDING.md.

Layout

Tudo fora de build_files/ e system_files/ veio de ublue-os/image-template e é trabalho deles.

O que ainda precisa ser respondido

• Se a imagem é construída de fato. Confirmado para o commit 14e3a21 pela execução 31143048491 do GitHub Actions; a construção emitiu dois avisos de lint não fatais do estado do DNF.
• Como um verificador transforma a afirmação de implantação bootc status em tempo de execução do agente em identidade de imagem verificada. A afirmação é metadado, não autoridade assinada; em sistemas sem bootc, ela é explicitamente unavailable.
• O QCOW2 derivado do Bazzite passa no canário de mecânica isolada, mas suas observações negativas de UKI e lockdown o impedem de ser admitido pela política.
• Se o add-on de política PCR 12 assinado separadamente permanece reproduzível sob atualizações, rollback, ordenação alternativa e um ciclo de vida de chaves de produção. O harness congelado de política única passa agora; esses casos de ciclo de vida não passam.
• Como construir o agente e a política em um candidato selado, verificar uma quote assinada fora da VM convidada e reproduzir (replay) os event logs relevantes.
• Se o PCR 15 é populado da forma que o design presume em uma raiz bootc.
• Se o registro de MOK produz um valor de PCR 7 estável o suficiente para se escrever uma política com base nele.
• Se um fornecedor aceitaria uma hierarquia de chaves registrada via MOK.

As questões de medição em tempo de execução exigem QEMU com OVMF e swtpm, o que não requer hardware adicional. A conexão e a mecânica do protocolo TPM bruto já passaram lá, mas inicializar a imagem construída e validar seu event log e política continuam sendo experimentos separados. A aceitação pelo fornecedor exige uma conversa com o fornecedor.

Licença

Apache-2.0, em conformidade com o template a partir do qual isto é construído.