Libreboot 26.10 发布：支持UEFI与Chromebook

开源固件项目 Libreboot 发布了 26.10 版本，代号 "Ominous Olive"。这一版本在社区中引发了不小的讨论，因为它带来了两项此前难以想象的支持：UEFI 引导与 Chromebook 设备兼容。对于长期关注自由固件的人来说，这几乎是一次路线级别的调整——Libreboot 过去以"绝对纯净、拒绝专有代码"著称，而 UEFI 和 Chromebook 都曾是它明确排斥的对象。

从"纯净固件"到兼容现实

Libreboot 的定位一直很清晰：为特定主板提供完全自由的 BIOS/UEFI 替代方案，除去一切专有二进制。它的前身是 GNU Libreboot，后来因理念分歧从 GNU 项目中独立。这样的背景决定了它的用户群体相当小众，但黏性极高。

26.10 版本加入 UEFI 支持，意味着它开始能够对接主流的操作系统引导链。UEFI 本身并不"邪恶"，问题在于多数实现包含专有模块。Libreboot 的做法应该是提供自己的一套 UEFI 实现路径，而非直接封装厂商固件。这一步如果走得稳，会大幅降低新用户的上手门槛。

要理解 Libreboot 与 UEFI 之间的张力，需要区分 UEFI 规范与 UEFI 实现。UEFI 是由 UEFI Forum 制定的引导接口规范，本身是公开、开放的文档，它定义了固件如何初始化硬件、如何向操作系统移交控制权、如何提供运行时服务。真正引发自由软件社区警惕的，是各家厂商在这个规范之上堆叠的实现：它们往往包含未公开的闭源模块、网络栈、驱动甚至远程管理组件，且大多要求经过数字签名才能加载引导程序。Libreboot 若推出自有的 UEFI 实现路径，实质上是用开源代码覆盖规范所要求的那层接口，从而在不引入厂商二进制的前提下让现代操作系统识别并正常引导。这对长期只能依赖传统 BIOS 引导链的自由固件而言，是一次接口层面的补课。

固件中的数字签名机制也值得说明。传统 BIOS 不做引导程序校验，而 UEFI 引入了签名验证，初衷是抵御引导区病毒和底层持久化攻击，但客观上把引导链的控制权部分交给了平台厂商。自由固件社区对此的典型应对，是提供可由用户自行导入密钥的签名方案，或直接关闭强制校验。Libreboot 如何在保持自由的前提下处理这一机制，将直接影响它在主流发行版上的实际体验。

Chromebook 支持意味着什么

Chromebook 搭载的 Coreboot 本身就是开源固件的常见基础。Libreboot 基于 Coreboot 构建，理论上向 Chromebook 延伸是顺理成章的。但 Chromebook 的固件锁、写保护机制以及与 Google 生态的绑定，让这件事远比桌面主板复杂。

对用户而言，最直接的价值是：手头闲置的 Chromebook 有了第二条命——刷入自由固件后安装常规 Linux 发行版。这对二手设备市场和电子垃圾问题都是一个正面信号。

Coreboot 是 Libreboot 的技术底座，因此有必要单独说明它的角色。Coreboot 是一个开源的固件框架，负责最基础的硬件初始化，也就是把内存控制器、芯片组和基本外设从冷启动状态带到可以执行后续代码的状态。它刻意保持精简，真正的引导逻辑交给 payload 处理，常见的 payload 包括 GRUB、SeaBIOS 以及 UEFI 实现。Libreboot 正是在 Coreboot 之上打包了经过挑选的 payload 与配置，形成一个开箱可用、且剔除了专有二进制的发行版。这也解释了为什么 Libreboot 的扩展能力高度依赖 Coreboot 已经支持的平台：只要上游有对应主板的移植代码，向下延伸就有了技术基础。

Chromebook 的写保护机制是另一个常被低估的环节。为了阻止固件被篡改，Chromebook 通常使用硬件写保护，通过主板上的螺丝、屏蔽片或专用跳线让固件芯片进入只读状态，软件层面则配合只读的固件区域与验证启动。解除写保护一般需要拆机并改动硬件，部分型号还要求先进入开发者模式、清除固件中保存的启动状态标志。这类操作不可逆风险较高，一旦过程中断电或操作失误，设备可能无法再启动到恢复模式。这也是社区对 Chromebook 可刷写性存疑的主要技术原因。

争议与质疑

Hacker News 上的讨论（原帖）并不全是掌声。核心争议集中在两点：一是 UEFI 支持是否违背了项目初衷；二是 Chromebook 的硬件兼容性是否真的达到了可用程度。

这种质疑在自由软件社区并不罕见。每一次向主流妥协，都会有人担心"滑坡效应"。但反过来看，一个只服务于极少数旧主板的项目，其影响力终究有限。适度扩展兼容范围，可能是让理念活下去的方式。

自由软件社区常说的滑坡效应，指的是一个以纯净性为核心价值的项目，在引入第一项妥协后，后续的界限会越来越模糊，最终与普通开源项目无异。这种担忧并非空穴来风：历史上确有项目在加入二进制固件支持后，逐步接受更多专有组件，导致最初的自由承诺被稀释。但滑坡论的批评者指出，原则的价值在于能否被持续实践，如果严格的纯净标准把绝大多数用户挡在门外，理念就只能停留在小圈子里。围绕 Libreboot 26.10 的争论，本质上是这两种取向的又一次碰撞。

值得注意的是，GNU 项目对固件的判定标准常与直觉不同。GNU 关注的并非固件是否预装在设备中，而是用户能否替换、修改并重新烧录它。一块可以自由刷写的网卡，即使出厂自带专有固件，也可能被视为可接受；反之，一块固化了不可替换固件的设备，即便运行开源驱动，也不符合标准。Libreboot 早期对主板的挑剔，很大程度上就是在执行这套判定逻辑，这也是它支持机型稀少的根本原因。

对普通用户的意义

如果你从未接触过 Libreboot，这个版本或许是一个值得留意的入口。它不再要求你必须拥有一块特定型号的老旧主板，也不再需要你完全绕开现代引导流程。

当然，刷写固件始终有风险，Chromebook 的写保护解除尤其需要谨慎操作。建议先查阅官方文档和社区教程，确认自己的设备型号在支持列表内再动手。

Libreboot 26.10 是一次方向性的试探。它能否在"自由"与"可用"之间找到平衡点，还要看后续版本的迭代和社区反馈。

刷写固件前，使用 Coreboot 或 Libreboot 的官方支持列表核对设备型号是最基本的一步，同一产品线中不同批次的主板可能使用完全不同的芯片组。外部编程器是最稳妥的恢复手段，常见工具包括基于 CH341A 芯片的廉价编程器配合夹子或探针，能在设备完全无法启动时直接读写固件芯片，因此建议在动手前就准备好并确认能读取原厂固件备份。

风险还来自电源与固件镜像本身。刷写过程中断电可能让芯片停留在半写入状态，而校验和不匹配的镜像同样会导致无法启动。稳妥做法是先完整备份原始固件、在稳定供电环境下操作，并优先选择有活跃社区支持、已被他人验证过的机型。对于 Chromebook，还要额外确认开发者模式、写保护解除方式以及是否涉及固件启动标志重置，避免在解除写保护后无法回到可恢复状态。