自建Secure Boot密钥体系：从密钥生成到引导器签名完整指南

如果你只装过一次系统，Secure Boot 对你来说大概率只是 BIOS 里一个默认开启、从来没动过的开关。但当你开始自己装 Linux、折腾双系统、换定制内核，或者干脆自己组了一台没有预装系统的主机，这个选项就会变成绕不过去的坎：不关，引导器可能直接被拒之门外；关了，又总觉得安全防线少了一层。更麻烦的是，网上关于 Secure Boot 的中文资料大多停留在“BIOS 里选 Enabled 还是 Disabled”，真正涉及到自建密钥、自己签名引导器和内核的内容少得可怜。

这篇文章是我把一套完整流程跑通之后的记录，包含从密钥生成、固件写入、引导器与内核签名，到系统验证的每个环节，以及在真实环境中踩过的各种坑。适合三种人看：一是想在纯 Linux 机器上把 Secure Boot 从默认关闭改为自主掌控的；二是 Windows/Linux 双系统用户想在不失微软兼容性的前提下加入自己的信任链；三是对 UEFI 固件工作原理好奇、想彻底搞懂这套机制的人。

1. 为什么需要自己配置Secure Boot密钥体系

1.1 Secure Boot到底在防什么

Secure Boot 是 UEFI 固件在启动阶段的一道验证关卡。固件在执行任何 EFI 可执行文件之前，都会检查这个文件的数字签名是否由受信任的证书签发，或者它的哈希值是否在白名单里。只有通过验证的引导器才会被加载，之后的引导链由引导器继续往下验证内核，内核再验证驱动和模块，形成一条完整的信任链。

用生活里的话说，固件就是个门卫，手里有一份“允许进入的访客名单”（就是 db 白名单）和一份“禁止进入的黑名单”（也就是 dbx）。凡是名单上没有名字的，一律不让进。传统 BIOS/MBR 启动没有这套检查，所以才有 bootkit（引导区病毒）这类能在操作系统加载前就劫持整个系统的恶意程序。Secure Boot 要防的正是这个环节——固件、引导器、内核之间的信任空白。

很多人把 Secure Boot 和 TPM 混为一谈。实际上这是两个独立的功能：TPM 是硬件可信根，负责把启动过程的状态告诉系统，而 Secure Boot 是在固件阶段直接拦截未授权的引导文件。虽然它们经常出现在 BIOS 设置的同一页，但不要搞混。

1.2 哪些人需要自建密钥而不是用微软默认方案

预装 Windows 的机器，固件里出厂就有微软的 PK、KEK 和 db。这种情况下 Secure Boot 是“微软说了算”：只有微软签名的引导器（Windows Boot Manager、各大发行版的 shim）才能启动。对多数用户来说，这没什么问题。

但如果你要走定制路线，比如自己编译内核、用 systemd-boot 而不是 shim + GRUB、或者希望整个平台由自己掌控，那微软的 db 里就没有你的证书。你的内核如果没签名，Secure Boot 一开启就直接拒绝启动。很多人遇到“开启 Secure Boot 后 Linux 起不来”就是这种情况。

自建密钥体系，就是把你自己的证书加入到固件的 PK/KEK/db 里，让固件信任你的签名。做完之后，Secure Boot 可以保持开启，而你的引导链完全由自己签发，不再依赖第三方。简单说，就是从“租别人的门禁卡”变成“自己发门禁卡”。

1.3 动手前先检查：你的机器真的支持UEFI Secure Boot吗

这一步容易忽略。Secure Boot 不是所有 UEFI 设备都支持，更不是开了就生效。动手之前先确认三件事：

• 固件界面里能找到 Secure Boot 选项。大多数 2012 年之后的主板都有，但部分低端板或某些定制机可能把它藏得比较深，甚至直接去掉。
• 当前引导模式必须是 UEFI 而不是 Legacy/CSM。Secure Boot 只在纯 UEFI 引导下参与；如果你的磁盘是 MBR 分区表、通过 CSM 模式启动，Secure Boot 实际处于未启用状态。这也是很多人发现“BIOS 里明明开了 Secure Boot，进系统查却是关闭”的原因。
• 显卡需要有 GOP 支持。老显卡（比如没有 UEFI GOP 的 HD 6450 一类）在纯 UEFI 模式下可能根本没有显示输出，更别提进固件设置。这个问题的根源在 VBIOS 而非 Secure Boot，但也属于纯 UEFI 改造的常见拦路虎。

检测方法可以进操作系统后看：Linux 下执行mokutil --sb-state，输出SecureBoot enabled才是真的生效；Windows 下用msinfo32查看“安全启动状态”，或者在 PowerShell 里执行Confirm-SecureBootUEFI。另外，像 fbinsttool 这类工具做出来的传统启动盘，默认是 Legacy 风格，在开启 Secure Boot 的纯 UEFI 机器上根本无法启动。想在这种机器上做系统维护，启动盘也得换成支持 UEFI 的版本。

2. 密钥体系与工具链：先把原理啃透再动手

2.1 PK、KEK、db、dbx的信任关系

UEFI 的 Secure Boot 依靠固件里的四个 EFI 变量维护信任关系：

• PK（Platform Key）：平台密钥，整个体系的根。一个平台只能有一个有效的 PK，用来授予修改 KEK 和 db/dbx 的权利。可以把它理解成“公司法人章”。
• KEK（Key Exchange Key）：密钥交换密钥，由 PK 签名授权，用来更新 db 和 dbx。相当于“部门公章”。
• db（Signature Database）：允许的签名数据库，存放可信的证书、签名或哈希值。凡是 db 里有的，固件就允许执行。
• dbx（Forbidden Signature Database）：禁止的签名数据库，存放被吊销的证书或已知恶意软件的哈希。db 和 dbx 冲突时，dbx 优先。

信任关系是一层套一层的：固件信任 PK，PK 授权 KEK，KEK 授权 db，db 决定哪些引导器能运行。一旦 PK 被设置，固件就从 Setup Mode 进入 User Mode，后续所有变量更新都必须带合法的数字签名，否则固件直接拒绝。这就是为什么有些人先把密钥写坏后，想在系统里用普通命令把变量改回去是不可能的——因为在 User Mode 下，改 PK 本身也需要 PK 授权。

2.2 ESL和.auth文件到底是个什么东西

固件里的 db、KEK 等变量不是简单的证书文件，而是符合 UEFI 规范的数据结构，叫 EFI Signature List（ESL）。它把证书、哈希等签名条目打包成一个或多个“签名列表”。用 OpenSSL 生成的是 X.509 证书，不能直接扔给固件，必须先转换成 ESL 格式。

要向固件写入变量，光有 ESL 还不够，还要有授权认证文件（.auth）。.auth 文件 = 待写入的变量数据 + 被相应密钥签名的头部信息。固件收到 .auth 后，先验证签名是否合法、授权链条是否正确，再决定是否接受这次写入。

所以完整的生成链路是：X.509 证书 → ESL → 签名 → .auth → 写入固件。很多人失败在中间某一步，比如直接把.crt文件拿去 KeyTool 里加载，固件根本不认，就是这个原因。流程不复杂，但少一步都不行。

2.3 工具选型：efitools + sbsigntools + OpenSSL

我建议用三件套：

• openssl：生成 RSA 密钥对和 X.509 证书。
• efitools：提供cert-to-efi-sig-list（证书转 ESL）、sign-efi-sig-list（给 ESL 签名）、efi-updatevar（在 Linux 里直接改固件变量）、KeyTool.efi（固件层的图形化密钥管理工具）。
• sbsigntools：提供sbsign（给 EFI 可执行文件签名）、sbverify（验证签名）、sbattach等。

Debian/Ubuntu 上执行：

sudo apt install efitools sbsigntools openssl

Arch 上执行：

sudo pacman -S efitools sbsigntools openssl

Windows 上也可以做完整的密钥管理，但工具生态比较乱，我后面主要讲 Linux 方案，这也是社区里最成熟的路线。另外提醒一句，操作时不要用 WSL 直接操作宿主机固件变量，WSL 的 efivarfs 支持不完整，容易出怪问题。

2.4 动手前的安全底线：备份密钥和恢复路径

开始之前，先把三件事做好，不然一旦失误就是手忙脚乱的局面：

• 备份当前固件的 Secure Boot 状态。很多主板 BIOS 里有 “Restore Factory Keys” 或 “Reset Secure Boot Keys” 选项，默认是你最后的救命稻草，先确认你的主板有这个选项。UEFI 变量本身也可以通过工具导出备份（KeyTool 的 “Save keys” 功能，或者 Linux 下直接备份/sys/firmware/efi/efivars/里 PK、KEK、db、dbx 的文件）。
• 导出 Windows 的 BitLocker 恢复密钥。如果 Windows 分区启用了 BitLocker，改变 Secure Boot 状态、更新固件、改动磁盘布局都可能导致 BitLocker 触发恢复流程。没有恢复密钥就只能看数据干瞪眼。
• 准备一台可以随时上网的备用环境。最坏情况下需要清空 CMOS 或重刷 BIOS，这些都要另外一台能联网的电脑下载固件更新、制作启动盘。

以我的习惯，还会在上手前把重要数据备份一次，并把当前的引导器、内核文件拷贝到 U 盘留底。Secure Boot 折腾失败最常见的后果不是数据损坏，而是进不了系统。

3. 实操：从密钥生成到固件写入

3.1 用OpenSSL生成GUID和三对密钥证书

先建一个工作目录，生成一个 UUID 作为本次平台密钥的唯一标识：

mkdir ~/secureboot && cd ~/secureboot uuidgen > GUID.txt cat GUID.txt

然后生成三对密钥和证书。这里的关键点是：PK、KEK、db 各自是一对独立的 RSA 密钥，不要图省事三把都用同一把，否则它们之间的授权关系就形同虚设。命令如下：

# PK openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" \ -keyout PK.key -out PK.crt -days 3650 -nodes # KEK openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" \ -keyout KEK.key -out KEK.crt -days 3650 -nodes # db openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature Database/" \ -keyout db.key -out db.crt -days 3650 -nodes

参数说明：rsa:2048是目前兼容性和安全性都均衡的选择，大部分固件对 RSA 4096 也没问题，但没有必要；-days 3650是有效期十年，到期后需要轮换；-nodes表示私钥不加密，方便脚本化操作，如果你希望更安全，去掉它之后每次签名都要输密码，看个人取舍。

实际上我会建议：PK 和 KEK 的私钥放离线存储（加密 U 盘或密码管理器），db 的私钥留在签名机上日常使用。因为 db 用于引导器和内核签名，使用频率高，而 PK 和 KEK 只在密钥轮换时用一次。签名操作完成了，顺手把.key文件从日常目录挪走，减少风险面。

3.2 生成EFI签名列表并签名成.auth文件

有了证书之后，生成 ESL 并对 ESL 签名：

GUID=$(cat GUID.txt) cert-to-efi-sig-list -g "$GUID" PK.crt PK.esl cert-to-efi-sig-list -g "$GUID" KEK.crt KEK.esl cert-to-efi-sig-list -g "$GUID" db.crt db.esl sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth sign-efi-sig-list -k PK.key -c PK.crt KEK KEK.esl KEK.auth sign-efi-sig-list -k KEK.key -c KEK.crt db db.esl db.auth

注意第二和第三步的区别：KEK.auth 是用 PK 签名的，因为只有 PK 才有权限修改 KEK；db.auth 是用 KEK 签名的，对应 KEK 修改数据库的权限。这个授权链条一定不能搞反，否则固件会拒绝写入。

如果你希望保留微软的默认密钥（双系统用户强烈建议），就不要用 PK.auth 直接覆盖全部，而是改用 append 模式，或者干脆把整个流程改为：先进入 Setup Mode，然后追加 Microsoft 证书 + 你的证书。具体取舍我在第 6 节避坑里展开。

3.3 用KeyTool.efi在固件层安装密钥

KeyTool.efi 是 efitools 自带的图形化工具，运行在 UEFI 环境里，可以在不进入操作系统的情况下修改固件变量。它适合固件本身不支持通过操作系统写入变量（有些锁死变量写入的主板）或者你想可视化确认每一步情况的时候。

准备步骤：

# 找一个 FAT32 格式的 U 盘，挂载后执行 sudo mount /dev/sdX1 /mnt cp /usr/share/efitools/efi/KeyTool.efi /mnt/ cp ~/secureboot/*.auth /mnt/ sudo umount /mnt

注意 KeyTool.efi 只有在固件处于 Setup Mode 时才能运行。如果当前 Secure Boot 处于 User Mode，固件会拒绝执行 KeyTool.efi。所以正确的顺序是：

1. 重启进入 BIOS，找到 Secure Boot 选项，选择 “Clear All Secure Boot Keys” 或 “Restore Factory Keys” 之类的入口，让固件进入 Setup Mode（此时 Secure Boot 会显示 Disabled / Setup Mode）。
2. 从 U 盘启动 KeyTool.efi。在固件启动菜单里选择这个 U 盘，或者先从 UEFI Shell 进入，再切到 fs0: 运行 KeyTool.efi。
3. 在 KeyTool 界面选择 “Edit Keys”，然后依次加载 PK.auth、KEK.auth、db.auth。加载 PK.auth 之后，KeyTool 会询问是否将这把 PK 设为平台所有者，选 Yes。设置完成后固件会自动进入 User Mode。
4. 退出 KeyTool，重启进 BIOS，确认 Secure Boot 状态变为 Enabled / User Mode。

这里要提醒一点：KeyTool 加载 PK 时如果选 No，后续某些固件会要求所有变量更新都要额外通过该 PK 签名，流程会麻烦不少。我测试过的主板基本都是选 Yes 更顺畅。选 Yes 后 KeyTool 会把该证书同时追加到 KEK 里，让这枚 PK 私钥可以直接管理后续变量更新。

3.4 免U盘方案：用efi-updatevar/sbkeysync直接写入

如果你的 Linux 环境能挂载 efivarfs，并且固件没有锁死变量写入，也可以直接在系统里用efi-updatevar写入，省去 U 盘和 KeyTool 的步骤。前提同样是先让固件进入 Setup Mode（清空密钥后启动到 Linux）。

sudo efi-updatevar -f PK.auth PK sudo efi-updatevar -f KEK.auth KEK sudo efi-updatevar -f db.auth db

写入顺序不能乱：先 PK，再 KEK，最后 db。因为写 PK 这个动作本身就是固件从 Setup Mode 切换到 User Mode 的触发点，一旦 PK 写入成功，后续 KEK 和 db 的写入就要靠签名授权了。

另一个工具是sbkeysync，来自 sbsigntools，支持从本地目录同步密钥到固件：

sudo mkdir -p /etc/secureboot/keys sudo cp PK.auth /etc/secureboot/keys/PK/ sudo cp KEK.auth /etc/secureboot/keys/KEK/ sudo cp db.auth /etc/secureboot/keys/db/ sudo sbkeysync

sbkeysync的优点是支持增量同步，还带了--keystore参数可以指定密钥目录，适合做成脚本在安装密钥的同时留一份备份。不过它要求本地目录里的密钥文件正好对应固件当前需要的变更，如果目录里同时有新旧两套密钥，处理逻辑容易让人迷惑，第一次用建议先执行sbkeysync --list看看它会做什么。

4. 给引导器和内核签名：Secure Boot才真正生效

密钥写入固件只是第一步。Secure Boot 开启后，固件只认 db 里的证书，而你的引导器和内核必须包含由 db 对应私钥签名的签名，否则依然无法启动。这一步的顺序千万不能搞反：先准备好签名后的文件，再开启 Secure Boot。

4.1 systemd-boot与内核的签名流程

以 Arch 装的 systemd-boot 为例，引导器本体和内核是两个独立的 EFI 文件，都需要签名。

先装引导器：

sudo bootctl install

然后找到 systemd-boot 的实际文件路径。不同发行版不一样，Arch 在/usr/lib/systemd/boot/efi/systemd-bootx64.efi，装好之后 ESP 里会有一份拷贝。签名前先确认拷过去再签，或者签完再拷，两种方式都可以，只要保证最终 ESP 里的文件是带签名的：

# 方式一：先 bootctl install，再对 ESP 里的文件签名覆盖 sudo cp /usr/lib/systemd/boot/efi/systemd-bootx64.efi /boot/EFI/systemd/systemd-bootx64.efi sudo sbsign --key db.key --cert db.crt \ --output /boot/EFI/systemd/systemd-bootx64.efi \ /boot/EFI/systemd/systemd-bootx64.efi

内核也是类似：

sudo sbsign --key db.key --cert db.crt \ --output /boot/vmlinuz-linux /boot/vmlinuz-linux

如果你的发行版在每次升级内核时会自动跑 mkinitcpio / update-grub 并且可能覆盖签名文件，那还需要挂接一个 pacman hook 或者把签名步骤写进更新脚本。Arch 社区常用的做法是搞一个 pacman hook，在内核更新后自动重新签名。

4.2 GRUB的模块签名问题

GRUB 和 systemd-boot 不同，它把大部分功能拆成了独立模块（.mod 文件），真正运行时才从/boot/grub/目录加载。如果你只给 grubx64.efi 签名，模块没签名，Secure Boot 开启后 GRUB 还是会报错甚至拒绝加载。

解决方案有三个，按推荐程度排序：

• 用发行版官方签名好的 shim + GRUB。Debian/Ubuntu/Fedora 的 shim 由微软签名，shim 再通过 MOK（Machine Owner Key）机制信任你自己签名的内核。这条路适合不想太折腾、又希望内核由自己掌控的用户，也是大部分发行版默认方案。
• 自签 shim。把 shim 用你自己的 db 证书签名，同时把 GRUB 和内核都签名。shim 的签名验证比较绕，但一旦配好，后续用 MokManager 管理密钥很方便。
• 用grub-mkstandalone把所有模块打进一个 EFI 文件里，然后只签这个文件。这个方案模块都内嵌了，签名一次覆盖全部，缺点是生成的文件体积大，启动会慢一点点。

我个人在自由定制时更倾向于 systemd-boot 而非 GRUB，因为 systemd-boot 把所有逻辑集中在一个 EFI 文件里，配合 UKI 后签名粒度最干净，没有模块遗漏的问题。

4.3 更完整的方案：Unified Kernel Image

前面签了内核，但如果内核和 initramfs 分开两个文件，initramfs 其实是作为数据文件被引导器加载的，固件并不会单独校验它的签名。攻击者如果篡改了 initramfs，理论上可能影响启动流程。这属于 Secure Boot 链路里的一个“薄环节”。

完整的解法是 Unified Kernel Image（UKI）：把内核、initramfs、命令行参数、splash 图等打包成一个单一的 EFI 可执行文件（.efi），由 systemd-stub 提供引导逻辑。这样一个文件里什么都有，签名一次，固件验证一次，整个启动链就闭环了。

Arch 上用 mkinitcpio 生成 UKI 的配置大致是：

# /etc/mkinitcpio.d/linux.preset 里设置 # default_uki="/boot/EFI/Linux/arch-linux.efi" # 然后执行 sudo mkinitcpio -P # 生成后签名 sudo sbsign --key db.key --cert db.crt \ --output /boot/EFI/Linux/arch-linux.efi \ /boot/EFI/Linux/arch-linux.efi

最后在 systemd-boot 配置里直接指向这个 .efi 文件即可。签名后的 UKI 可以通过固件的 LoadImage 认证，也可以直接被 UEFI 固件当作启动项注册，效果等同于一次签名覆盖整个用户空间之前的启动阶段。如果你同时在意 Secure Boot 和完整性，UKI 是目前主流的推荐路线。

5. 系统验证与日常维护

5.1 固件端和系统端的双重确认方法

密钥装好、引导器签名完成后，重启进 BIOS，确认 Secure Boot 显示 Enabled，Secure Boot Mode 显示 Custom 或 User Mode（不同主板叫法不同）。这是固件端最直接的确认。

进系统后再做一层软件验证：

mokutil --sb-state # 应该输出 SecureBoot enabled bootctl status # 看 "Secure Boot: enabled" 和 "Setup Mode: user" 字样 dmesg | grep -i lockdown # 如果输出 lockdown 相关信息，说明内核已经进入 lockdown 模式

Windows 下则用 msinfo32 或 PowerShell：

Confirm-SecureBootUEFI # 返回 True 表示 Secure Boot 已启用

注意，Linux 下这些命令显示的是内核启动时检测到的状态，如果固件设置和内核检测不一致，通常是因为 CSM/Legacy 模式没关干净，或者引导介质走的是传统 BIOS 路径。之前热词里提到的“win11 的 uefi 引导修复”，很多也是同一个问题：系统装成了 MBR+Legacy，后来固件改成 UEFI 就找不到引导了，本质上是启动模式不匹配，和 Secure Boot 本身无关。

5.2 签名与证书链的验证命令

验证引导器和内核的签名是否与 db 证书匹配：

sbverify --cert db.crt /boot/vmlinuz-linux sbverify --cert db.crt /boot/EFI/systemd/systemd-bootx64.efi

如果输出Signature verification OK，说明签名证书在 db.crt 覆盖的信任范围内。如果报错，常见原因是签名用的是 KEK 或 PK 的密钥，而不是 db 密钥。Secure Boot 验证引导器时用的是 db 数据库，不是 PK 也不是 KEK。

也可以查看固件当前实际保存了哪些密钥：

efi-readvar -v PK efi-readvar -v KEK efi-readvar -v db

输出里能看到当前所有被固件信任的证书信息。这一步在排查“签名明明验签成功但固件还是不认”的问题时特别有用，很多时候是因为 db 里根本没有你的证书，或者你的证书只是加进了 KEK 而没加进 db。

5.3 密钥轮换、dbx更新与升级后自动签名

Secure Boot 不是配一次就一劳永逸。日常维护要关注三件事：

• 证书到期。密钥生成时设置的 3650 天到期后，固件可能拒绝信任过期证书。轮换流程是：生成新 db 密钥，用 KEK 签名新 db.esl，追加写入固件，然后用新 db 重新签名引导器和内核。
• dbx 更新。UEFI 规范允许固件或操作系统更新 dbx 来封禁已知漏洞引导器。很多发行版的 fwupd 支持通过 LVFS 更新 UEFI dbx，直接执行fwupdmgr update即可。这个一般不会影响你自己的签名文件，除非你的引导器恰好被列入了黑名单。
• 系统升级后重新签名。内核升级、引导器升级后，新文件不会自动带签名，一定要在更新流程里挂接重新签名的步骤。Arch 可以用 pacman hook，Debian 可以用 dpkg postinst 脚本或者自己写 systemd 服务。

以我自己的环境为例，我写了一个 pacman hook，打包后触发/usr/local/bin/sign-boot.sh，脚本里统一对 systemd-boot、内核、UKI 做 sbsign 和 sbverify，再调用 bootctl 更新。每次升级完开机能少很多麻烦。脚本逻辑其实很简单，核心就是把 sbsign 命令串起来，但有没有它，体验完全是两个世界。

6. 避坑指南：真实踩坑记录与问题速查

6.1 常见问题速查表

6.2 几个让我差点翻车的细节

第一个坑是 ESL 的 GUID。cert-to-efi-sig-list里-g参数填的是 GUID 文件里的 UUID，如果你在生成 ESL 时随便写了一个 UUID，或者每次生成都用不同的 UUID，固件可能把同一条证书当成多个不同条目处理，导致后续追加或删除操作对不上号。用同一个 UUID 贯穿整个流程是个好习惯。

第二个坑是签名顺序。我最初在 BIOS 里先开启了 Secure Boot，然后才想起内核没签名，结果直接进不了系统，只能拿另一台机器做启动盘进去补签。后来养成的习惯是：所有签名操作完成并验证无误后，最后才在固件里开启 Secure Boot。顺序反过来一定要小心。

第三个坑是 Windows 双系统的微软证书。如果你在清空密钥后只导入了自己的 PK/KEK/db，Windows Boot Manager 会因为不在 db 里而无法启动。处理办法有两种：一是录入你自己的 db 后再追加微软的 Windows UEFI CA 证书；二是保留系统原有的全部密钥，只把你自己的证书追加进去。双系统用户请优先考虑第二种，风险小很多。需要追加的话，把微软的 KEK CA 2011 和 Windows UEFI CA 的 .crt 转成 ESL，再分别用对应的上层密钥签名后追加，具体步骤和自建密钥的生成流程类似，只是把 source 换成微软证书。

第四个坑比较隐蔽：不同主板的 Secure Boot 实现细节有差异。有些板子把 “Secure Boot” 和 “Secure Boot Mode” 分开设计，前者是总开关，后者是 Custom/Standard 二选一；有些板子清空密钥后直接变成 Disabled，但实际处于 Setup Mode；有些板子会要求你设置管理员密码之后才能改 Secure Boot。遇到界面选项都对不上号的情况，先翻主板手册而不是盲目操作。

6.3 被锁在系统外的兜底救援方案

最坏的情况是密钥安装完了，重启发现引导器签名有问题，系统起不来。这时候不要慌，救人的路径大概有三条：

• BIOS 里清空 Secure Boot 密钥。绝大多数主板都有 “Restore Factory Keys” 或 “Clear Secure Boot Keys” 之类的选项，执行后固件回到 Setup Mode，Secure Boot 变为 Disabled，系统可以正常启动。这是最常用的救援手段。
• 拔 CMOS 电池清空固件设置。如果主板没有快速清空 Secure Boot 的选项，或者清空后依然无法引导，断电、拔电池、等一分钟再装回去，固件设置基本会还原到出厂状态，Secure Boot 随之失能。
• 重刷 BIOS。极少数情况下密钥变量损坏导致连 BIOS 界面都异常，这时候只能通过主板厂商的 USB BIOS Flashback 或编程器重刷固件。概率很低，但备一个心理预期没坏处。

另外提前做一件事能省很多事：在工作目录里把 PK.key、KEK.key、db.key 之外的 .esl、.auth、.crt 文件全部打包存到加密分区和 U 盘。出了问题重装系统后，只要还有这些文件，就可以快速恢复密钥体系，不用从头再生成。

我把这套流程前前后后跑过好几台机器，最深的体会是：Secure Boot 本身并不复杂，复杂的是把它和你的发行版、引导器、Windows 双系统、固件实现这些变量组合在一起时产生的各种意外。但一旦你亲手把密钥体系搭起来，再回头看那些“Secure Boot 到底开不开”的纠结，就会很清楚地知道每一步该怎么判断了。

最后再分享一个小技巧：在正式对主力机下手之前，先拿虚拟机练一次手。VMware 或 VirtualBox 里新建虚拟机时选择 UEFI 固件，开启 Secure Boot，就能完整模拟从 Setup Mode 到 User Mode 的转换流程。很多坑在虚拟环境里发现，比在真机上发现划算得多。