从零写OS内核 | Windows GPT+UEFI 启动：ESP 分区、NVRAM 启动项与 Secure Boot 完整解析
上一章讲了 MBR+BIOS 模式下的 Windows 启动链路，System Reserved 分区是整个链路的核心锚点——BOOTMGR 和 BCD 都在那个 100MB 的 FAT32 分区里，BIOS 通过 MBR 的活动分区标记找到它。
但如果你买的是 2014 年后出厂的品牌机（ThinkPad、戴尔、惠普台式机），大概率已经不在 MBR 模式下了——它用的是 GPT+UEFI ，System Reserved 分区消失了，取而代之的是一个 ESP（EFI System Partition） ，启动项不再靠”活动分区标记”，而是由 NVRAM（非易失性内存） 里的启动条目管理。
这两个模式不只是”分区表格式不同”，是 完全不同的启动哲学 ：
| MBR+BIOS | GPT+UEFI | |
|---|---|---|
| 分区表位置 | LBA 0（512 字节混在一起） | LBA 1（GPT Header）+ LBA 2-33（分区表） |
| 启动标记 | MBR 分区表 0x80 活动位 | NVRAM 的 BootOrder（闪存，不在磁盘上） |
| 引导管理器位置 | System Reserved（FAT32，100MB） | ESP（FAT32，≥100MB） |
| 启动文件格式 | BOOTMGR（16 位实模式） | bootmgfw.efi（64 位 PE/COFF） |
| 安全启动 | 无（BIOS 模式无签名验证） | Secure Boot（签名链验证） |
| 多系统共存 | GRUB 写 MBR + 链式加载 | GRUB 写 ESP + NVRAM 条目 |
| 磁盘容量限制 | 2TB（32 位 LBA） | 8ZB（64 位 LBA，无上限） |
这一章，我们来把 Windows GPT+UEFI 启动链路 彻底拆解——ESP 分区里装了什么，NVRAM 的 BootOrder 是怎么工作的，Secure Boot 签名链是怎么回事，以及所有相关的工具怎么用。
启动链路：完整的 10 步流程
GPT+UEFI 模式下，Windows 的启动链路比 MBR+BIOS 更长，但每一步都更清晰：
ESP 分区：UEFI 模式下的”System Reserved”
ESP 的标准位置和大小
ESP（EFI System Partition）是一个 FAT32 文件系统的小分区 ，最小 100MB，推荐 260MB 以上（给 GRUB 未来升级留空间）。
为什么是 FAT32？ 因为 UEFI 规范要求所有 UEFI 固件必须支持 FAT32（对 ESP 是强制要求）。NTFS、ext4、APFS 都不在 UEFI 规范里，所以 ESP 必须是 FAT32。
ESP 里到底装了什么
bootmgfw.efi vs bootmgr.exe
| 文件 | 模式 | 字长 | 格式 |
|---|---|---|---|
| bootmgfw.efi | UEFI | 64 位 | PE/COFF（和 .exe 相同，.efi 扩展名） |
| bootmgr.exe | BIOS | 16/32 位 | Windows PE 可执行程序（NTFS 压缩） |
| bootmgr.efi | UEFI | 64 位 | bootmgfw.efi 的备用名（部分机器用这个文件名） |
bootmgfw.efi 是 UEFI 规范下的”UEFI 应用”，它和 Windows 里普通的 .exe 一样是 PE/COFF 格式，但扩展名 .efi 让固件知道”这是一个 UEFI 应用，固件可以直接执行它”。
NVRAM：启动项的”数据库”
NVRAM 是什么
NVRAM（Non-Volatile RAM，非易失性内存）是 UEFI 固件的一部分，通常是 Flash 芯片（或 EEPROM）的一小块区域， 即使关机也不会丢失数据 。它存储了：
BootOrder
：启动优先级列表（按顺序尝试每个启动项）
BootXXXX
：每个启动项的详细信息（名字、路径、参数）
DriverOrder
：UEFI 驱动加载顺序（不常见）
PlatformLang
：首选语言
KeyPad/Timeout
：启动菜单超时时间
NVRAM 的工作原理
NVRAM 存储在 UEFI 固件的 Flash 芯片里，不是磁盘上。这意味着：
格式化磁盘不会影响启动项
（和 MBR 模式不同）
重装 Windows 会重新写入 NVRAM
（覆盖 GRUB 的条目）
BIOS 设置被清除/恢复可能导致 NVRAM 丢失
（某些型号）
NVRAM 损坏的症状： – 按 F12/Del 进入启动菜单时，选项全部消失 – 或者启动顺序变成空的，BIOS 提示 “No bootable device”
efibootmgr：Linux 下操作 NVRAM
bcdedit：Windows 下操作 NVRAM
Secure Boot：签名验证的完整链
什么是 Secure Boot
Secure Boot 是 UEFI 规范里的可选安全特性，它要求所有启动代码（bootloader、驱动、内核）必须被 可信的公钥签名 ，才能执行。这防止了”插入恶意 USB，重写 bootloader”的攻击。
签名数据库
UEFI 固件的 Flash 里存储了签名数据库：
微软的 KEK 是全球大多数 UEFI 固件里预置的，所以微软签名的 .efi（shimx64.efi）可以在大多数机器上启动。
Windows 的签名链
Windows 10/11 的启动链在 UEFI 下是：
所有 .efi 和 .sys 文件都必须有微软签名才能在 Secure Boot 开启时运行。这就是为什么”禁用了驱动签名强制”的测试模式（TestSigning）在 Secure Boot 关闭时才能用。
检查 Secure Boot 状态
Linux：
Windows：
shim：绕过签名限制的垫片
shim（ shimx64.efi ）是 Linux 发行版提供的”签名垫片”，它有微软签名（能在 Secure Boot 开启时运行），内部包含了发行版自己的公钥。
禁用 Secure Boot（开发用）
开发环境需要加载未签名的内核或 bootloader 时，禁用 Secure Boot：
BCD 在 UEFI 模式下的新内容
和 MBR 模式相比，GPT+UEFI 模式的 BCD 内容增加了一些 UEFI 特定的字段：
BCD 里用 GPT 分区 GUID 而不是驱动器字母来标识分区：
bcdboot：从 ESP 重新创建 BCD 和启动文件
bcdboot.exe 是 Windows 里重建整个 UEFI 启动环境的工具，比 bcdedit 更”一键化”：
工具：Linux 下操作 ESP 和 BCD
挂载 ESP（读写模式）
挂载 ESP（只读，防止误改）
用 hexdump / xxd 查看 GPT 分区表
用 sgdisk 操作 GPT 分区
efivar：操作 UEFI 变量（NVRAM 里的东西）
实战修复：UEFI 模式下 Windows 启动损坏
场景 1：bootmgfw.efi 损坏导致黑屏
症状：开机后屏幕黑，无任何输出，UEFI 设置可以进入。
场景 2：NVRAM 启动项全部消失
症状：UEFI 设置里启动项为空，BIOS 提示 “No bootable device found”。
场景 3：重装 Windows 后 GRUB 消失
症状：UEFI 模式下重装 Windows，GRUB 被覆盖，Linux 无法启动。
场景 4：Secure Boot 开启但 GRUB 无法启动
症状：启用 Secure Boot 后，GRUB 菜单不出现，直接进入 Windows。
WinRE 在 UEFI 模式下的管理
UEFI 模式下，WinRE 的配置方式略有不同：
UEFI 模式下，WinRE 镜像默认存在 RecoveryWindowsRE （在 Windows 系统分区里），不是 ESP。
踩坑与注意事项
坑 1：UEFI 模式下 ESP 被删导致”无启动设备”
现象：磁盘管理里误删了 ESP 分区（通常最小、最前面的 FAT32 分区），开机报 “Reboot and Select proper Boot device”。
原因：ESP 包含了 bootmgfw.efi 和 BCD，没有它 UEFI 固件找不到任何可启动的 .efi 文件。
解决：用 Windows 安装U盘 → 修复计算机 → 命令提示符：
坑 2：重装 Windows 后 BootOrder 被 Windows 覆盖
现象：UEFI 模式下重装 Windows，GRUB 的启动项从 NVRAM 消失，直接进 Windows。
原因：Windows 安装程序会重置 NVRAM BootOrder，把 Windows Boot Manager 放在最前面。
解决：进入 Linux Live USB，手动用 efibootmgr -o 调整顺序：
坑 3：bcdedit 在普通 CMD 里权限不足
现象：普通用户运行 bcdedit 报错”拒绝访问”。
原因：BCD 是受保护的系统配置，需要管理员权限。
解决：用管理员权限打开 CMD：
坑 4：UEFI 设置里 Secure Boot 和 CSM 混用导致启动混乱
现象：开启了 Secure Boot 但禁用了 CSM（Compatibility Support Module），某些启动盘找不到（只支持 Legacy USB）。
解决：在 UEFI 设置里明确选择”UEFI Only”，不要同时开 Secure Boot 和 Legacy Support。
坑 5：bcdboot 用错盘符导致”Windows 没有正确安装”
现象：执行 bcdboot C:Windows /s D: /f UEFI 后，启动报错”你的电脑尚未正确设置”。
原因：D: 盘符不是 ESP，而是另一个 FAT32 分区，或者 ESP 和 Windows 不在同一个磁盘上。
解决：用 diskpart 确认 ESP 和 Windows 分区的实际盘符，再重建：
写在最后
Windows GPT+UEFI 启动链路，相比 MBR+BIOS，是一次彻底的架构升级：
关键变化： – System Reserved → ESP ：启动文件从隐藏分区移到了专用 FAT32 分区 – 活动分区标记 → NVRAM ：启动顺序不再依赖磁盘分区表，而存在固件 Flash 里 – 0x55AA → CRC32 ：启动标志从简单的 2 字节变成了 GPT 的校验机制 – BOOTMGR → bootmgfw.efi ：从 16 位实模式变成了 64 位 UEFI 应用 – 无 Secure Boot → Secure Boot ：签名链验证从无到有（微软签名 + 发行版签名）
修复工具的核心也变了： – bootrec 几乎不用了（MBR 代码不再使用） – bcdedit + bcdboot 是主要工具 – efibootmgr （Linux）和 bcdedit （Windows）是管理 NVRAM 启动项的两把钥匙
wandos 目前没有 UEFI 启动支持。如果要做，需要实现 UEFI 应用入口点（PE/COFF 格式），支持 GPT 分区解析（读取 LBA 2-33 的分区表），实现 FAT32 文件系统读写，然后通过 NVRAM 注册自己的 .efi 文件。这比 MBR+BIOS 复杂很多，但也是工业级 OS 的必经之路。
下篇预告（366） ：候选方向—— ext2 文件系统：inode、块组与目录项 ，或者 第一个用户态进程：从内核启动到 /sbin/init 的完整链路 。你选哪个？
仓库 ：https://github.com/golang12306/os-kernel-from-scratch
相关阅读
UEFI Spec 2.8+：
https://uefi.org/specifications
（GPT、Secure Boot、NVRAM 规范）
Microsoft Docs: “BCD Store Format” — BCD 注册表 hive 的二进制结构
Microsoft Docs: “Secure Boot” — 签名数据库和签名链
Linux Kernel:
arch/x86/boot/header.S
（Linux 的 UEFI 入口点）
efibootmgr 源码：
https://github.com/rhboot/efibootmgr
https://github.com/zhangfuwen/wandos — Linux 内核教程
动手环节
想深入理解本文内容？动手实践是最好的方式：
今天的目标 ：在你的 UEFI 机器上操作 ESP、NVRAM 和 Secure Boot。
- 查看你的 ESP 分区和启动项
： -
备份 ESP 内容 ： bash mkdir -p ~/esp-backup sudo mount -t fat /dev/sda1 /mnt/esp -o ro rsync -av /mnt/esp/ ~/esp-backup/ ls -la ~/esp-backup/
- 在虚拟机里模拟 UEFI 启动修复 ： bash # 创建 UEFI 模式的虚拟机（QEMU） qemu-img create -f qcow2 win10-uefi.qcow2 50G # 安装时确保选择 UEFI（不是 BIOS/MBR） # 安装完成后，模拟 ESP 损坏，练习用 bcdboot 重建
-
操作 NVRAM 启动项 ：
-
检查 Secure Boot 状态和签名
：bash
mokutil –sb-state如果是 enabled，查看签名数据库
mokutil –list-enrolled
提示 ：操作 NVRAM（efibootmgr）是安全的——它只是修改 Flash 芯片里的数据，不会破坏磁盘内容。但误删重要的启动项（如 Windows Boot Manager）会导致该 OS 无法启动，需要重新注册。
仓库：https://github.com/golang12306/os-kernel-from-scratch
评论