Heads:TAILS 的另一面

Heads 是一种针对笔记本电脑和服务器的配置,旨在为通用硬件 带来更多安全性。 其目标包括:
- 在启动路径上使用自由软件
- 将信任根移至硬件(或至少是 ROM 引导块)
- 测量并证明固件的状态
- 测量并验证所有文件系统

NOTE: 这是一个进行中的项目,尚未准备好供非技术用户使用。 如果您有兴趣参与贡献,请联系我们。 安装需要拆解您的笔记本电脑或服务器, 外部 SPI 闪存编程器,存在损坏风险以及 显著的挫败感。
更多信息可在 33C3 上关于构建“略微更安全的系统”的演讲 中获取。
文档
doc/ 目录包含 Heads 代码库的技术参考文档。从这里开始:
| 文档 | 涵盖内容 |
|---|---|
| doc/architecture.md | 组件概览:coreboot、Linux payload、initrd、构建系统、配置层 |
| doc/security-model.md | 信任层级、度量启动、TOTP/HOTP 认证、GPG 启动签名、LUKS DUK、故障关闭设计 |
| doc/boot-process.md | 逐步启动流程:/init → gui-init → kexec-select-boot → OS 交接 |
| doc/tpm.md | PCR 分配、密封策略、SRTM 链、特定于主板的 TPM 变体、开发者配置参考 |
| doc/ux-patterns.md | GUI/UX 约定:whiptail 封装、完整性报告、错误流程 |
| doc/config.md | 主板和用户配置系统 |
| doc/docker.md | 使用 Docker 的可复现构建工作流 |
| doc/circleci.md | CircleCI 管道布局、工作区流程及缓存行为 |
| doc/qemu.md | 用于开发和测试的 QEMU 主板目标 |
| doc/wp-notes.md | 各主板的闪存写保护状态 |
| doc/BOARDS_AND_TESTERS.md | 支持的主板及其维护者/测试者 |
| doc/prerequisites.md | USB 安全密钥(HOTP/TPMTOTP)、操作系统要求、刷写方法 |
| doc/faq.md | 常见问题:UEFI 与 coreboot、TPM、LUKS、威胁模型 |
| doc/keys.md | 所有密钥和秘密:TPM 所有者、GPG PIN、磁盘恢复密钥、LUKS DUK |
| doc/development.md | 提交约定、编码标准、测试清单 |
| doc/build-freshness.md | 调试陈旧构建:initrd.cpio.xz 的组成与验证 |
有关面向用户的文档和指南,请参阅 Heads-wiki。
贡献
我们欢迎对 Heads 项目的贡献!在贡献之前,请阅读我们的 贡献指南,以了解如何开始、提交问题以及提出更改建议。
构建 Heads
Heads 在版本化的 Docker 镜像中构建。受支持并经过测试的工作流使用 提供的 Docker 封装器——无需在主机上安装 QEMU 或 swtpm。
快速入门(需要 Docker CE):
./docker_repro.sh make BOARD=x230-hotp-maximized
./docker_repro.sh make BOARD=qemu-coreboot-fbwhiptail-tpm2 run
测试无需硬件 — Docker 提供了完整的构建栈
以及带有软件 TPM (swtpm) 和捆绑的 canokey-qemu
虚拟 OpenPGP 智能卡的 QEMU 运行时。在刷写真实硬件之前,完全在软件中构建和测试。
构建目标是 boards/ 下的目录名。对于当前已测试和维护的目标集合,请参阅 doc/BOARDS_AND_TESTERS.md。
有关完整详情 — 包装脚本、Nix 本地开发、可重现性验证以及 维护者工作流 — 请参阅 doc/docker.md。
有关 CI 缓存/工作区行为以及 CircleCI 作业图,请参阅 doc/circleci.md。
有关 QEMU 板级测试,请参阅 doc/qemu.md。
有关构建问题的故障排除,请参阅 doc/faq.md 和 doc/build-freshness.md。
关于可重现构建的一般说明
为了构建可重现的固件镜像,Heads 构建特定
版本的 gcc 并使用它来编译 Linux 内核以及
进入 initrd 的各种工具。 不幸的是,这意味着第一步
有点慢,因为它会克隆 musl-cross-make 树并构建 gcc...
完成后,顶层 Makefile 将处理大部分
剩余细节 -- 它下载各种软件包,验证
哈希值,应用 Heads 特定的补丁,使用交叉编译器配置并构建它们,
然后将必要的部分复制到
initrd 目录中。
构建系统核心工具(coreutils)在
/bin 和 /usr/bin/ 中仍存在依赖,但如果你最终得到的哈希值与官方构建不同,
任何问题都应可被检测到。
关键组件
Heads 构建了一组精选的软件包(来自 modules/)。大多数板级配置启用的关键组件包括:
- musl-cross-make — 交叉编译器工具链
- coreboot — 替代厂商 BIOS/UEFI 的最小固件
- Linux — 最小内核负载(无内置 initrd;使用外部 initrd 启动,例如
initrd.cpio.xz) - busybox — 核心工具集
- kexec — Linux 内核执行器(从启动分区、USB、网络加载内核)
- tpmtotp — 基于 TPM 的 TOTP/HOTP 一次性密码生成器
- cryptsetup — LUKS 磁盘加密
完整构建还包括:lvm2、tpm2-tools、flashrom/flashprog、dropbear (SSH)、
fbwhiptail (GUI)、qrencode 以及许多其他组件。请参阅各个 modules/* 文件和
板级配置以了解完整情况。
我们还建议安装 Qubes OS,
尽管 Heads 可以 kexec 到任何 Linux 或
multiboot
内核。
备注
- 构建 coreboot 的交叉编译器可能需要较长时间。 幸运的是,这只需执行一次。
- 构建最终是可复现的! reproduciblebuilds 标签 跟踪任何回归问题。
- 当前已测试和维护的板卡记录在 doc/BOARDS_AND_TESTERS.md 中。 板卡目标本身位于
boards/下。 - Xen 在 QEMU 中无法工作。 签名、HOTP 和 TOTP 可以工作;请参阅下文。
- Blob 要求因板卡或板卡系列而异。 请检查
blobs/下与您正在构建的目标相关的文档。 - Purism 板卡使用来自 Purism 分支的 Purism 管理的 coreboot blob 路径(例如
3rdparty/purism-blobs/...通过CONFIG_IFD_BIN_PATH和CONFIG_ME_BIN_PATH在config/coreboot-librem_*.config中)。 Heads 不应维护这些供应商 blob 负载。 Librem blob 监狱的运行时固件说明位于 blobs/librem_jail/README 中。 - 诸如 X220 和 X230 之类的 Lenovo xx20 板卡使用在 blobs/xx20/readme.md 中记录的共享 xx20 blob 流程。 X220 特定的说明位于 blobs/x220/readme.md 中。
- 其他板卡可以从
blobs/下的板卡系列目录获取 blob(例如 xx20/xx30/xx80, t420, t440p, w541)或从 coreboot 配置中设置的分支特定路径获取(例如使用3rdparty/dasharo-blobs/...的 Dasharo 板卡)。 供应商 blob 负载仍由其上游供应商/分支维护。 - T480 和 T480s 的 blob 要求记录在 blobs/xx80/README.md 中。 其他系列在
blobs/下有自己的文档,例如t420/、t440p/和w541/。
QEMU
可以使用软件 TPM 在 QEMU 中测试操作系统启动。 可以通过将 USB 令牌从主机转发到来宾系统来测试 HOTP。
有关更多信息和设置说明,请参阅 qemu 文档。
coreboot 控制台消息
coreboot 控制台消息存储在 CBMEM 区域中,
并可以使用 cbmem --console | less
命令由 Linux 负载读取。 其中包含大量关于系统状态的
有趣数据。