seL4 证明边界 CI
ARM 固件集成 seL4 时，持续核对每次实际构建是否仍处于安全证明覆盖范围内。
seL4 是一类经过形式化证明的操作系统内核。它完成 AArch64 架构证明后，嵌入式团队终于能把这项结论带进 ARM 设备。难点随即落到实际工程：新加的驱动、板卡配置或构建参数，可能已经越出了证明所覆盖的范围。
开发者把固件构建接入服务，并提交内核版本、驱动清单、设备树和编译选项。每次构建完成后，产品将实际产物与证明所要求的前提逐项比对，画出已证明内核、外部可信组件和未验证代码之间的边界。评审者能直接看到某个串口驱动或内存映射为何被归到边界外。
若一次提交关闭了隔离配置，或让未验证组件取得了原本不该拥有的权限，发布流水线会停在对应变更上。开发者得到的是具体配置差异和修复建议，不是一句笼统的安全告警。通过检查的产物会附带版本、配置哈希和依赖关系，审计人员可追溯到实际刷进设备的固件。
首版支持采用 seL4 的 AArch64 固件项目，围绕构建期配置和组件边界生成证据包。它不声称替驱动自动完成形式化验证，重点是防止团队把已经获得的证明在集成阶段悄悄用掉。
为什么是现在
8月21日至24日，Proofcraft 与 seL4 Foundation 先后宣布 AArch64 保密性证明完成，补齐该架构的安全隔离证明。S1S2 截至8月25日，这条消息在 Hacker News 位列第11，获169 points 和37条评论；ARM 团队此时更可能重新核对实际固件是否仍满足证明前提。S3
目标用户
面向已采用 seL4 的安全关键嵌入式团队，尤其是负责 AArch64 板卡落地的系统工程师。最需要它的是换板、升级内核、接入驱动或准备发布评审时。此时证明结论要落到一份真实固件，而配置差异往往散在构建文件、设备树和组件描述中。审核人与开发者需要共同确认，哪些隔离属性仍成立，哪些代码已进入可信边界。
最小切入点
接入点放在构建产物落盘后。采集内核提交号、CMakeCache 与 `_verified.cmake`。另取系统描述、DTB 和组件 ELF。先映射官方已验证组合，再用 pyelftools 与 libfdt 提取产物事实。Microkit 的 `report.txt` 只作附录，因为官方说明其格式不固定。S4 规则只判断版本、配置、权限和硬件前提，不尝试证明驱动。通过后输出带固件哈希的 JSON 证据包，并以 CI 失败码阻断越界构建。
以小博大
首批用户应从 seL4 生态的工程协作渠道寻找。发布开源 CLI 和可复现的 AArch64 示例，把合规与越界结果直接呈现在拉取请求中。再到 seL4 论坛、开发者聊天和相关 GitHub 仓库发布兼容说明。需要认证交付的集成商可从免费扫描中获得一份可带进评审会的证据包。
竞品与缝隙
怎么赚钱
按私有固件项目收取年费，包含 CI 检查、证据包留存和验证基线更新。自托管部署作为同一方案的高价档位。
反方视角
边界规则一旦写错，CI 可能把未覆盖构建标成安全，后果比普通误报严重。规则过严又会频繁阻断发布，团队很快会选择绕过检查。设备树与构建参数只能描述部分硬件前提，无法证明外设实际行为。若项目基于 Microkit，当前 MCS 配置仍在验证中，不能套用新完成的结论。S4 不同版本、板卡和配置的映射也要持续维护。若构建不可复现，证据包只能证明元数据一致，无法证明设备运行的就是该产物。