作文的动机来自许久前一次例行电脑维护，清灰重涂硅脂贴导热垫，三回又三回仍然观察到诡异的显卡掉功耗，于是决定拉起 Windows 跑甜甜圈。朋友拿出了闪存盘插上，笔者以为是 Windows To Go 便没有在意。屏幕再次亮起时大写的 Ventoy 赫然出现，正要提醒他关 Secure Boot，小手一动居然进了系统。

MOK #

观察 Ventoy 的 操作说明，不难发现是利用了微软签名的 shim 作为 1st-stage bootloader，随后 MokManager 导入了 Ventoy 的 Machine Owner Key，重启后顺利进入其选单界面。

要准确认识这件事，需要回答三个科学问题（不是）

• MOK (Machine Owner Key) 是什么？
• 这份微软签名的 shim 是从哪里拾来的？
• 既然事实上能够自由引导未知来源镜像，Secure Boot 能否真正保护启动链安全？

Secure Boot like it’s 2020 #

在笔者因更换笔电重做系统而发现 sbctl 之前，配置 Secure Boot 分为

• 使用 openssl 生成三对公私钥（PK、KEK、DB）
• 使用 KeyTool.efi 录入公钥
• 编写灵车签名脚本并将其和私钥一起藏进 /root
• 设置 pacman hook 在更新内核、microcode 或重制 initramfs 时生成新的可引导镜像

等四个步骤，详见 Matthew Bentley 的教程。所以虽然原理完全一致，但 sbctl 作为一个用户友好的前端，其出现（2021）仍然使得安全启动变得前所未有的易于配置。

UEFI spec 中上述 key store 的角色参见 The Meaning of all the UEFI Keys 一文。不难注意到，MOK 并非 UEFI 标准的实现。

$99 shim bootloader #

人们总是倾向调和、折中的，世上的事物莫过如此；譬如要求微软一道分发自由软件的证书，一定要到倒闭之后。但如果你主张让微软吃 antitrust 大调查，那小小地开个口子自然要比保护用户系统安全要好商量多了。

折中之法就是 Red Hat 来开发一个 shim，除了验签和拉起真正的 bootloader 之外什么也不做，同时保证 reproducible 便于核验。准备 $99 特价 code signing 证书一份，公钥塞进去，然后微软来给这个 shim 签名，详见 Microsoft UEFI Signing Requirements 文档。这个流程在后来转移至 FDo/Red Hat，由社区 shim review board 负责审核，并向微软建议是否签名该引导文件。

回到一开始的问题，MOK 是 SUSE 的发明，在 shim 0.3 版本后被集成，允许在 user mode 下通过 MokManager 写入用户自行准备的公钥到 UEFI NVRAM，保护用户不受任何形式的 vendor lock-in，即使在不开放 setup mode 的设备上也能加载自定义引导程序。特别地，微软留了一手，用于签名 shim 的证书是 Microsoft Corporation UEFI CA 2011（及之后的 2023 版本），在部分设备上默认禁用，如 ThinkPad Z13 等预装微软 Pluton “安全处理器”的型号。此外，前文提到的 UEFI keys 包括了 db 和 dbx，即黑白名单的签名数据库，微软和 LVFS 可以随时推送更新以吊销不安全的 (vulnerable / compromised) 引导文件，见列表。

kernel lockdown #

最后的问题：Secure Boot 真的能保证启动链安全吗？

对于滥用 DRM 甚至 remote attestation，防用户甚于防贼、恨不得锁定其硬件设备的在线服务商，自然是不安全的。所幸桌面计算生态暂且还算开放，系统供应商和用户侧都有充分的保全措施。

从用户角度，作为 Machine Owner，关键点在于拒绝导入不可信的 MOK：考虑到后者由 shim 实现，必须在 MokManager 下手动选择或输入预先设置的密码才能导入，恶意载荷在零接触的情况下很难释放。对于本文在开头提出的例子，enroll 时不应保留任何供应商证书，将启动权控制在自己手中。

微软掌握预装在用户设备中的安全启动根证书，自然保留随时吊销的权利；对于微软生态下的第三方操作系统（如 Linux、Oracle Solaris 等），往往出于安全启动 self protection 的原始目的，构建 lockdown lsm 并在 secure boot 启用时 enforce lockdown mode 以保护内存中的内核镜像不受篡改。这也是为什么对于 Debian/Fedora 等发行版，在安装依赖 dkms 的树外模块时（如闭源 NVIDIA 驱动）需要 enroll MOK，经过正确签名这些代码才能被内核加载。

Resources #

如需详尽了解 UEFI Secure Boot 的历史，可以参见以下阅读材料：

• Managing EFI Boot Loaders for Linux 系列教程
• mjg59 | Implementing UEFI Secure Boot in Fedora
• UEFI Secure Boot | James Bottomley’s random Pages
• 反Secure Boot垄断：兼谈如何在Windows 8电脑上安装Linux - 阮一峰的网络日志

这些文章距今已有十余年，均发布于 2012 年前后，时值微软发布 Windows 8 及 硬件认证 配套标准，正式将 UEFI Secure Boot 引入个人电脑。时至今日，考古当年的记录，仍可一窥前人为捍卫硬件控制权、拒绝平台锁定、保有运行修改版软件的自由等诸多方面所付出的努力。