3、UEFI规范概览：UEFI论坛、规范版本、主要组件（固件、驱动、协议、应用）及与PI规范的关系

UEFI（Unified Extensible Firmware Interface，统一可扩展固件接口）并非某一家公司的私有标准，而是由UEFI论坛（UEFI Forum）维护的开放行业规范。理解UEFI规范的整体架构，是深入掌握系统引导流程的前提。本章将梳理UEFI论坛的组织职能、规范版本演进、核心组件（固件、驱动、协议、应用）的职责划分，并厘清UEFI规范与PI（Platform Initialization，平台初始化）规范之间的分工与协作关系。只有清晰把握这些基础概念，后续章节中关于安全启动、驱动加载、引导项选择等机制才能建立在一个坚实的知识框架之上。

上图展示了UEFI论坛下两大核心规范的总体框架。左侧为UEFI规范本身，右侧为PI规范，两者共同构成了现代固件开发的基石。下面我们将逐一展开分析。

3.1 UEFI论坛与规范版本演进

3.1.1 核心原理：从EFI到UEFI的标准化之路

UEFI论坛的前身是Intel在1998年发起的EFI（Extensible Firmware Interface）项目。当时Intel推出安腾（Itanium）处理器，传统BIOS的16位实模式与MBR分区方案已无法满足64位服务器的扩展需求。2005年，Intel将EFI规范移交给统一EFI论坛（UEFI Forum），由AMD、Microsoft、Apple、IBM、Lenovo、Dell等超过200家成员公司共同维护。论坛下设多个工作组，分别负责规范制定、测试认证、商标管理和市场推广。

UEFI规范版本演进的关键节点如下：

3.1.2 判断方法：如何确认平台UEFI版本

在实际开发与调试中，确认当前平台的UEFI版本是第一步。在UEFI Shell中执行 ver 命令，或在操作系统内通过 dmidecode -t 0（Linux）或 msinfo32（Windows）查看BIOS版本信息。对于固件开发者，更精确的方式是在DXE阶段通过 gST->FirmwareVendor 和 gST->FirmwareRevision 字段获取。

3.1.3 案例拆解：一次固件升级失败后的版本回退

某服务器厂商在升级固件至UEFI 2.8版本后，发现部分NVMe SSD在冷启动时无法识别。工程师通过串口日志定位到 NvmExpressDxe 驱动在 BindingStart 阶段返回 EFI_DEVICE_ERROR。进一步分析发现，新版本规范中增加了 EFI_NVM_EXPRESS_PASS_THRU 协议的扩展字段，而旧版SSD固件未正确填充该字段。最终解决方案是回退至UEFI 2.7版本，并等待SSD厂商更新固件。此案例说明，规范版本升级可能引入兼容性问题，生产环境升级前必须在测试平台完成全量验证。

3.2 UEFI主要组件：固件、驱动、协议、应用

3.2.1 核心原理：四类组件的职责边界

UEFI规范将系统固件划分为四个核心组件，它们通过GUID（Globally Unique Identifier）进行唯一标识和关联：

• 固件（Firmware）：指存储在Flash中的完整UEFI实现，包括SEC、PEI、DXE、BDS各阶段代码，以及运行时服务（Runtime Services）和启动服务（Boot Services）。固件是平台启动的“操作系统”。
• 驱动（Driver）：遵循UEFI驱动模型（Driver Model）编写的可加载模块，分为设备驱动（Device Driver）和总线驱动（Bus Driver）。驱动通过 EFI_DRIVER_BINDING_PROTOCOL 与设备控制器绑定，实现即插即用。
• 协议（Protocol）：UEFI中最核心的抽象机制，是一组函数指针和数据结构，通过GUID标识。例如 EFI_SIMPLE_FILE_SYSTEM_PROTOCOL 提供文件读写接口，EFI_LOADED_IMAGE_PROTOCOL 描述已加载镜像的信息。
• 应用（Application）：在UEFI Shell或启动管理器中运行的独立程序，如 Shell.efi、MemTest.efi、操作系统加载器（OS Loader）。应用在退出启动服务前运行，无法调用运行时服务。

3.2.2 操作流程：驱动与协议的绑定过程

UEFI驱动模型的核心是“连接-启动-停止”三阶段：

1. 驱动安装：驱动加载后，将其 EFI_DRIVER_BINDING_PROTOCOL 安装到句柄数据库（Handle Database）。
2. 驱动连接：系统调用 Supported() 检查驱动是否支持某个控制器，若支持则调用 Start() 建立控制器与驱动的绑定。
3. 协议安装：Start() 内部会创建子句柄并安装相应的I/O协议（如 EFI_BLOCK_IO_PROTOCOL），供上层应用调用。

3.2.3 实战场景：编写一个简单的UEFI应用

以下代码展示了一个最小UEFI应用的入口函数，它通过 gST->ConOut 输出字符串：

#include <Uefi.h>
EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE ImageHandle,
                           IN EFI_SYSTEM_TABLE *SystemTable)
{
    SystemTable->ConOut->OutputString(SystemTable->ConOut,
        L"Hello UEFI!\r\n");
    return EFI_SUCCESS;
}

编译后生成 .efi 文件，放入FAT32格式的U盘中，在UEFI Shell中执行即可看到输出。这个简单示例揭示了UEFI应用与固件交互的基本模式：通过系统表获取控制台输出协议，调用协议函数完成操作。

3.3 UEFI规范与PI规范的关系

3.3.1 核心原理：接口规范与实现规范的分离

UEFI规范与PI规范是“接口”与“实现”的关系。UEFI规范定义的是操作系统与固件之间的接口，包括启动服务、运行时服务、协议定义、数据结构等。而PI规范定义的是固件内部各阶段（SEC、PEI、DXE、BDS）的模块化实现框架，它规定了固件开发者如何组织代码、如何在阶段间传递数据（通过HOB，Hand-Off Block）、如何管理内存和I/O资源。

两者的关键区别与联系如下表：

3.3.2 判断方法：如何区分规范归属

在阅读固件代码或调试时，可通过以下特征判断某个概念属于哪部规范：

• 如果涉及 EFI_ 前缀的结构体、协议或服务，属于UEFI规范。
• 如果涉及 EFI_PEI_、EFI_DXE_、HOB、PPI 等概念，属于PI规范。
• 如果涉及 gBS->（Boot Services）或 gRT->（Runtime Services），属于UEFI规范。
• 如果涉及 PeiServices 或 DxeServices，属于PI规范。

3.3.3 案例拆解：从HOB到EFI System Table的数据流转

以内存信息传递为例，说明PI与UEFI的协作过程。在PEI阶段，内存初始化代码（MemoryInit PEIM）通过 BuildMemoryAllocationHob() 创建HOB，记录可用内存区域。当DXE阶段启动时，DXE Foundation解析HOB列表，将内存信息填充到 EFI_MEMORY_DESCRIPTOR 数组中。最终，操作系统通过 GetMemoryMap() 启动服务获取该数组。整个过程体现了PI规范负责“内部生成”，UEFI规范负责“外部呈现”的分工。

3.3.4 常见误区与总结复盘

初学者常将UEFI与PI混为一谈，或误以为UEFI规范包含了平台初始化细节。实际上，UEFI规范不关心固件如何初始化内存、如何枚举PCI设备，这些属于PI规范的范畴。另一个常见误区是认为UEFI应用可以调用所有固件服务。事实上，一旦调用 ExitBootServices()，启动服务即告失效，仅运行时服务可用。

总结本章要点：UEFI论坛是规范制定者，UEFI规范定义操作系统可见接口，PI规范定义固件内部实现框架。固件、驱动、协议、应用四类组件通过GUID和句柄机制协同工作。理解这些基础概念，是后续学习安全启动、驱动加载、引导流程等高级主题的前提。