attestos

用于测试反作弊供应商可以验证什么（而不是依赖发行版名称白名单）的实验性 Linux 启动证明（boot-attestation）镜像与证据测试平台。

该机制、威胁模型和供应商规范见 plunder707/attested-gaming。本仓库生成产生证据的镜像。

状态：源机制预览。不可安装，也不受生产信任。

GitHub Actions 运行 31157890393 和 31159951490 构建了一个 Bazzite 衍生的 QCOW2，在 QEMU/OVMF + swtpm 下启动，无客户机网络，配置了持久的 EK/AK 句柄，并在客户机内部验证了基于 SHA-256 PCR 7、11、12 和 15 的原始引用（quote）。其有限收据的 SHA-256 为 ad5ef12592cb5f4d1dfa8f0da88148931d48f0e6018924b2de4c766e1523ddaf。 一个独立的验证器工作流 31160003873 针对隔离的软件 TPM 行使了本仓库的最终代理提交 b918392，并通过了 AK 注册、原始引用验证、重放拒绝、签名篡改拒绝以及 QEMU/OVMF TPM 接线。

启动结果还证实了 Bazzite 策略阻塞器：不存在 UKI 文件或 systemd-stub 信号，预期的锁定参数缺失，PCR 11 和 15 保持为零。PCR 12 也为零，但这并非独立失败：嵌入式 UKI 命令行属于 PCR 11，而 PCR 12 记录外部命令行输入，在没有提供任何输入时保持为零可能是正确的。安全启动密钥注册、UKI 支持的命令行度量、硬件来源、事件日志重放、传输绑定和启动策略准入仍未解决。两次“绿色”运行都未建立可正常工作的生产证明系统。

一个独立的 Fedora 密封镜像阳性对照在 run 31218059725 中通过了两次，并在合并后的源头部再次通过 run 31219745053。 它证明该测试平台可以启动不可变的上游签名 UKI，将固件选择的路径和已加载文件哈希并入启动前检查，观察非零 PCR 11，并拒绝未签名的 .cmdline 变更。这仅是测试平台对照：所有制造商、策略和生产信任标志仍为 false，并且它不会使 Bazzite 预览版可安装。

单独的签名 PCR 12 策略附加通道随后在 run 31234464516 上通过了两次。 上游 UKI 和 PCR 11 保持逐字节相同；两次签名启动都恰好一次应用了 lockdown=confidentiality module.sig_enforce=1，并重现了 PCR 12 ca62dd5f...a8f5；签名后篡改被拒绝，并返回零 PCR-12 基线。这证明的是一种有限机制，而不是可部署的密钥层次结构或操作系统信任策略。

本源码可供审查和可重现的模拟。未发布 GHCR 镜像，也不是可安装的受信任发行版。

已完成的 Bazzite 实验在 BOOTED_IMAGE_CANARY.md 中说明。重现和源码构建说明见 BUILDING.md。UKI 基础证据及其独立准入标准记录在 UKI_BASE_DECISION.md。签名 PCR 12 策略附加实验在 FEDORA_PCR12_ADDON_CANARY.md 中单独说明。里程碑顺序和停止规则在 ROADMAP.md 中跟踪。单独的已加载 UKI 测试平台对照在 FEDORA_SEALED_POSITIVE_CONTROL.md 中说明。

这为 Bazzite 增加了什么

没有任何删除，也没有任何修补。在其上添加了四样东西：

1. tpm2-tools 和 tpm2-tss，代理运行时需要它们。
2. 内核命令行，位于 /usr/lib/attestos/cmdline，包含 lockdown=confidentiality 和 module.sig_enforce=1。
3. attestos-provision，一个一次性单元，在 TPM 内创建独立的持久 RSA EK 和 AK 身份，并在存在时从 NV 存储中读取背书证书。
4. attestos-agent，在回环接口上通过套接字激活，响应严格的 attestos.tpm/v1 身份、激活或引用挑战，并返回原始 TPM 证据。代理从不返回信任裁决。

为什么基础镜像是 Bazzite

Bazzite 源于 Fedora，而 Fedora 系列正是反作弊白名单当前阻止的对象。在这里证明证明（attestation）有效，是值得证明的案例。基于 SteamOS 构建则证明不了任何东西，因为 SteamOS 已被允许通过，因此在那里做成功演示只是获得它本已拥有的访问权限。

Bazzite 也设计为可分层。它是一个 OCI 镜像，因此本仓库是一个 Containerfile 和一个 GitHub Action，而不是一个带镜像源和安装程序的发行版。

策略必须在内核启动之前经过认证和度量

这是决定这一切是否有效的关键部分。lockdown=confidentiality 会阻止 /dev/mem、针对运行中内核的 kprobes 以及未签名模块加载。如果该策略只存在于用户可编辑的引导加载程序配置中，那么这一保证就毫无价值。否则，用户可以删除这些参数，启动相同的内核度量，并提交一个完全未提及缺失策略的引用。

统一内核镜像（Unified Kernel Image）将内核、initrd 及其嵌入的命令行绑定到一个签名的 PE 二进制文件中，并度量到 PCR 11。一个单独签名的 systemd 命令行附加组件可以将额外策略扩展到 PCR 12，同时保持该上游 UKI 不变。这两条路由都必须与确切加载的工件绑定，并由验证器重放；仅凭文件存在或非零 PCR 是不够的。

Bazzite 不使用 UKI，而这现已得到确认，而不再是猜测。 它的 Containerfile 主动排除了 UKI 内核包：

dnf5 -y config-manager setopt "*fedora*".exclude="mesa-* kernel-core-* \
    kernel-modules-* kernel-uki-virt-* steam"

systemd-ukify 在仓库中没有任何出现。因此，此镜像附带的 cmdline 文件目前只是一份意图声明，仅此而已：没有 UKI，就没有任何东西对其密封，用户可以在引导加载程序中编辑它，而 PCR 11 度量的内容并不符合设计假设。

修复 Bazzite 不是 build.sh 中的一行。它需要一条受信任的内核前度量路径，无论是通过改变镜像引导方式，还是采用一个已经通过 systemd-stub 引导的基础镜像。

实验缩小了实际可选方案：

1. 仍然在 Bazzite 上做 UKI 工作，并接受与基础镜像的偏差。
2. 使用上游密封的 Fedora UKI，并通过一个单独签名、度量到 PCR 12 的 systemd 附加组件来添加 attestos 策略。
3. 寻找另一条经过认证的内核前度量路径。仅在核心启动后进行的度量是较弱的证据类别，绝不能作为等价物呈现。

密钥准入问题，尚未解决

上游 Fedora UKI 可以保留其分发签名，但单独的 attestos 策略附加组件仍然需要由固件、Shim 或 MOK 准入的签名密钥。第三方内核面临同一问题的更大版本。部署选项包括：

• MOK 注册：用户在首次启动时通过蓝色固件屏幕注册机器所有者密钥（Machine Owner Key）。Universal Blue 已经为此对树外内核模块执行了此操作，因此相关机制已经存在，但这将声明从“微软为这个内核背书”变为“用户明确信任这个密钥”，供应商必须决定这是否可接受。
• Microsoft 签名的 shim：这是真正的发行版所走的路径，是一个审查过程，而不是一份表格。
• 用户所有的 PK 和 KEK：提供完全控制权，但几乎无人采用。

一次性的 Fedora 测试平台将运行本地证书注册到复制的 UEFI DB 中，证明该机制可行，而不声称拥有部署模型。仍然没有被接受的最终用户密钥注册、撤销或恢复契约。这既是依赖方问题，也是工程问题。

安装它

目前还没有受支持的安装命令。特别是，ghcr.io/plunder707/attestos:latest 未发布。当前预览仅用于源码审查和隔离的 QEMU/swtpm 重现。参见 BUILDING.md。

布局

Containerfile            base image and the single RUN that calls build.sh
build_files/build.sh     the attestation layer
system_files/            agent, provisioning script, systemd units
image-template.env       image name and registry organisation
.github/workflows/       build-only and isolated evidence canaries
Justfile                 local build and test targets

build_files/ 和 system_files/ 之外的所有内容都来自 ublue-os/image-template，属于他们的工作。

仍待回答的问题

• 镜像到底能否构建。已由 GitHub Actions 运行 31143048491 针对提交 14e3a21 确认；构建发出了两个非致命的 DNF 状态 lint 警告。
• 验证器如何将代理运行时的 bootc status 部署声明转化为已验证的镜像身份。该声明是元数据，而非签名权威；在没有 bootc 的系统上，它显式为 unavailable。
• Bazzite 衍生的 QCOW2 通过了隔离机制金丝雀测试，但其 UKI 和锁定的负面观察阻止其进入策略准入。
• 单独签名的 PCR 12 策略附加组件在更新、回滚、替代排序和生产密钥生命周期下是否仍可重现。冻结的单策略测试平台现在通过；这些生命周期情形尚未通过。
• 如何将代理和策略构建到密封候选项中，在客户机之外验证签名引用，并重放相关事件日志。
• PCR 15 在 bootc 根上是否按设计假设被填充。
• MOK 注册是否会产生足够稳定的 PCR 7 值，以据此编写策略。
• 供应商是否会接受 MOK 注册的密钥层次结构。

运行时度量问题需要带 OVMF 和 swtpm 的 QEMU，这不需要额外硬件。接线和原始 TPM 协议机制现已在那里通过，但启动构建的镜像并验证其事件日志和策略仍然是独立实验。供应商接受需要与供应商进行对话。

许可证

Apache-2.0，与构建所基于的模板一致。