UEFI Secure Boot开发实战工程 - 第2节
2. UEFI 基础架构
UEFI（Unified Extensible Firmware Interface，统一可扩展固件接口）是传统 BIOS 的现代替代方案，定义了操作系统与平台固件之间的标准接口。UEFI 规范由 UEFI 论坛维护，当前主流版本为 2.x 系列。与 Legacy BIOS 相比，UEFI 在架构、可扩展性、安全性和用户体验上均有本质提升。
2.1.1 UEFI 与 Legacy BIOS 核心差异
| 对比维度 | Legacy BIOS | UEFI |
|---|---|---|
| 接口标准 | 16 位实模式，中断调用 | 32/64 位保护模式/长模式，函数表协议 |
| 磁盘分区 | MBR（主引导记录），最大 2TB | GPT（GUID 分区表），最大 9.4ZB |
| 启动方式 | 引导扇区 + 链式加载 | EFI 应用程序直接加载（.efi 文件） |
| 安全机制 | 无内置安全启动 | Secure Boot 签名验证链 |
| 网络支持 | 需额外 PXE ROM | 内置 UEFI 网络协议栈 |
| 驱动模型 | Option ROM，16 位代码 | EFI 驱动，跨架构兼容 |
| 用户界面 | 文本菜单，键盘操作 | 支持图形界面、鼠标、触摸 |
关键认知：UEFI 本质上是一个微型操作系统运行环境，拥有自己的内存管理、协议注册、事件处理和驱动模型，而不仅仅是"启动代码"。
2.1.2 UEFI 规范核心组件
- EFI 系统表（EFI System Table）：固件与 OS Loader 之间的主通信结构，包含启动服务、运行时服务、配置表等指针。
- 启动服务（Boot Services）：仅在启动阶段可用，提供内存分配、协议接口、事件、定时器、镜像加载等功能。
- 运行时服务（Runtime Services）：在 OS 运行期间仍可调用，包括时间、变量、复位、虚拟内存映射等。
- 协议（Protocols）：UEFI 的核心抽象机制，通过 GUID 标识的接口实现设备访问、文件系统、网络、安全等能力。
- EFI 镜像格式：基于 PE32+（COFF）格式，支持 .efi 扩展名的可执行文件，包含签名信息。
2.2 UEFI 启动流程
UEFI 启动流程分为七个主要阶段，从平台上电到 OS 接管，每个阶段都有明确的职责和状态转换。理解启动流程是进行 Secure Boot 开发和调试的基础。
2.2.1 启动阶段总览
| 阶段 | 缩写 | 主要职责 | 内存状态 |
|---|---|---|---|
| 安全验证 | SEC | CPU 初始化、Cache-as-RAM、验证可信根 | 临时 RAM（Cache） |
| EFI 前期初始化 | PEI | 内存初始化、平台早期配置、PEIM 调度 | 临时 RAM → 主存 |
| 驱动执行环境 | DXE | 加载 EFI 驱动、枚举设备、创建系统表 | 主存可用 |
| 启动设备选择 | BDS | 枚举启动选项、加载 OS Loader | 主存可用 |
| 运行时阶段 | RT | OS 接管、关闭启动服务、保留运行时服务 | OS 管理 |
| 系统准备 | SAL | （IA64 架构特有）系统抽象层 | — |
实战提示：在 UEFI Secure Boot 开发中，DXE 阶段是签名验证策略加载的关键窗口，BDS 阶段是 Secure Boot 策略生效的检查点。大部分 Secure Boot 调试工作集中在这两个阶段。
2.2.2 各阶段详细流程
- SEC（Security Phase）：CPU 从复位向量开始执行，建立临时内存（Cache-as-RAM），验证 PEI 阶段的可信根（如果有硬件信任根）。
- PEI（Pre-EFI Initialization）：PEI 内核（PEI Core）调度 PEIM（PEI Module），完成内存控制器初始化，将临时 RAM 切换至主存，传递 HOB（Hand-Off Block）给下一阶段。
- DXE（Driver Execution Environment）：DXE 调度器加载 DXE 驱动，初始化 PCI、USB、SATA 等设备，创建 EFI 系统表、启动服务和协议数据库。
- BDS（Boot Device Selection）：读取 NVRAM 中的启动选项（BootOrder/Boot####），按优先级尝试加载 OS Loader（如 bootx64.efi），执行 Secure Boot 验证。
- TSL（Transient System Load）：OS Loader 执行，加载操作系统内核，调用 ExitBootServices() 关闭启动服务。
- RT（Runtime）：OS 完全接管硬件，仅保留运行时服务（变量、时间、复位等）。
2.3 UEFI 固件分区
UEFI 固件使用 GPT（GUID Partition Table）磁盘布局，包含多个具有特定 GUID 和用途的系统分区。这些分区在启动、更新、恢复和安全验证中扮演关键角色。
2.3.1 主要系统分区
| 分区名称 | GUID | 文件系统 | 主要用途 |
|---|---|---|---|
| ESP（EFI System Partition） | C12A7328-F81F-11D2-BA4B-00A0C93EC93B | FAT12/16/32 | 存储 OS Loader、驱动、UEFI 应用程序 |
| MSR（Microsoft Reserved Partition） | E3C9E316-0B5C-4DB8-817D-F92DF00215AE | 无（保留空间） | Windows 磁盘管理元数据预留 |
| 恢复分区 | DE94BBA4-06D1-4D40-A16A-BFD50179D6AC | NTFS 或 FAT | 系统恢复环境（WinRE） |
| OEM 分区 | EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 | 厂商自定义 | OEM 恢复镜像、诊断工具 |
2.3.2 ESP 分区详解
ESP 是 UEFI 启动的核心分区，必须使用 FAT 文件系统（FAT12/16/32），分区类型 GUID 固定。ESP 通常位于磁盘起始区域，大小建议 100MB~512MB。
ESP 标准目录结构：
ESP (EFI System Partition)
├── EFI/
│ ├── BOOT/
│ │ └── BOOTx64.EFI # 默认启动加载器（x64 架构）
│ ├── Microsoft/
│ │ ├── BOOT/
│ │ │ ├── bootmgfw.efi # Windows Boot Manager
│ │ │ ├── bootmgr.efi # 旧版 Windows 启动管理器
│ │ │ └── memtest.efi # 内存诊断工具
│ │ └── Recovery/
│ │ └── bootrec.efi # 启动恢复工具
│ ├── Ubuntu/
│ │ ├── shimx64.efi # Shim 引导（Secure Boot 兼容）
│ │ ├── grubx64.efi # GRUB2 引导加载器
│ │ └── fbx64.efi # Fallback 引导
│ └── tools/
│ ├── Shell.efi # UEFI Shell
│ └── Sct.efi # UEFI 自我一致性测试
└── .vscode/ # （可选）调试配置
安全注意事项：ESP 分区中的 .efi 文件是 Secure Boot 验证的直接目标。任何未签名的或签名失效的加载器放置在 ESP 中都会导致启动失败。在开发调试阶段，建议将测试用的 .efi 放入 ESP 的独立子目录，并确保平台处于 Setup Mode 或关闭 Secure Boot。
2.3.3 MSR 分区说明
MSR（Microsoft Reserved Partition）是 Windows 操作系统预留的分区，用于存储磁盘管理元数据。MSR 没有文件系统格式，操作系统直接管理其内容。在 UEFI 开发中，MSR 通常不直接参与启动流程，但了解其存在有助于正确规划磁盘布局。
- 大小：通常为 16MB（GPT 磁盘）或 32MB（MBR 磁盘）。
- 位置：紧跟在 ESP 分区之后。
- 作用：用于 BitLocker 加密、动态磁盘转换、分区对齐等场景。
- 开发影响：在编写磁盘操作工具或固件更新程序时，应跳过 MSR 分区，避免误写。
2.3.4 分区布局示例（GPT 磁盘）
2.4 本章小结
- UEFI 规范定义了从 SEC 到 RT 的完整启动阶段，每个阶段有明确的内存状态和服务能力。
- ESP 分区是 UEFI 启动的存储核心，所有 OS Loader 和 UEFI 应用程序必须存放在 ESP 中。
- Secure Boot 验证在 BDS 阶段触发，验证对象是 ESP 分区中的 .efi 镜像文件。
- MSR 分区为 Windows 专用，UEFI 开发中通常不涉及，但需注意避免误操作。
- 理解启动流程和分区结构是后续进行 Secure Boot 策略定制、签名验证和调试的基础。