2.3 核心服务模型

2.3 核心服务模型

本节摘要：核心服务模型是固件世界的"内核"——BIOS 时代它是一堆以中断调用为通道的碎片化黑盒，UEFI 把它重造成以显式接口为契约、函数指针表为载体、生命周期管理为纪律的结构化服务内核。本节讲 Boot 与 Runtime 的双域分权、句柄与协议的对象模型、事件驱动的反应式引擎，以及内存与变量两大服务支柱。

本节地图

读完后你应当能：用"能力使能者"而非"启动工具"给核心服务下定义；讲清 Boot Services 与 Runtime Services 在内存语义、所有权、持久性三轴上的分野；复述 ExitBootServices 的三重不可逆承诺；为句柄、协议、事件、变量四类原语各举一个典型用法。

一、何谓核心服务：先纠正一个窄化理解

还是拿城市打比方：CPU 是神经中枢，操作系统是市政厅。可在地基更深处还藏着一间"地下控制室"：它不等磁盘来装载，不靠内存保护环撑腰，在操作系统吸到第一口气之前就已点亮指示灯、核对电路、清点设备、划好地址空间。BIOS 与 UEFI 合力搭起来的，正是这间控制室。

"核心服务"四个字最容易被读窄成"开机那会儿用的服务"或"Shell 里能敲的函数"。规范的本意却是"使能"二字——它自己不做的事，它替别人铺路：它不执行 OS 装载，却提供加载与启动镜像的服务；它不做图形渲染，却借图形输出协议把帧缓冲抽象交出去；它不负责磁盘加密，却给 TPM 驱动提供时间锚点，让度量链拿到可验证的时间戳。

所以核心服务的本质是一组平台无关性契约：把芯片组寄存器布局、PCI 配置空间的访问时序、ACPI 表的解析细节统统挡在身后，向上只交出语义统一的接口。这份契约精神与 POSIX 在 Unix 世界扮演的角色如出一辙——不管内核怎么调度进程，但进程创建必须返回标识、打开文件必须返回描述符。UEFI 的核心服务，就是固件圈的 POSIX。

这一定位也解释了服务为何劈成两大域。两域不是按时间先后切西瓜，而是沿内存语义、所有权转移、持久性保障三根轴做的制度性拆分。BIOS 的短板恰在于它只有一副执行上下文：所有服务共用一段堆栈与一张中断向量表，OS 一接管便全体作废——16 位代码段与 32/64 位保护模式天生不兼容，那是一种"用完即焚"的一次性模型。UEFI 反过来用明确的周期契约做主权分割：启动服务握"初始化主权"，可被 OS 安全回收；运行时服务握"存续主权"，OS 必须郑重接手。

二、ExitBootServices：一场固件与操作系统的加冕礼

退出启动服务远非普通调用，它是 UEFI 世界里最郑重的仪式，承载三重不可逆承诺。

其一，句柄宇宙坍缩。经安装协议接口而生的全部句柄对象，连同绑定的协议实例，被从句柄数据库里永久删除，此后一切句柄查询都答"未找到"。OS 若还要用某个协议，必须在退出之前完成驱动原生化与上下文迁移。

其二，内存疆域割让。固件向 OS 递交一份精确到页的内存映射，标明哪些页帧属于启动服务类型，OS 依此释放或并入自己的伙伴分配器。从这一刻起固件无权再碰这些地址——越界读一个字节都会吃保护异常。

其三，事件系统静默。定时器、I/O 完成、协议安装通知等所有事件，等待队列被清空、回调登记表被销毁，固件不再应答任何触发。OS 要异步能力，就得自己搭中断框架和任务队列。

这一过程的严肃程度，Linux 内核给出了最直白的注脚：退出启动服务的例程返回后立刻执行内存块释放并核对内存映射一致性，任何偏差直接触发致命断言——因为那已经不是普通缺陷，而是主权交接失败的宪政危机。

三、四根支柱：句柄、事件、内存、变量

核心服务模型不悬空，它踩在四根技术支柱上。

第一根：句柄与协议——面向对象的硬件抽象。 UEFI 丢弃了按物理地址与端口 I/O 硬编码找设备的旧路，改用基于句柄的设备对象模型。每个硬件实体（PCI 设备、USB 控制器、硬盘、显卡）都被抽象成一根不透明的句柄指针，内部牵着记录设备属性、父子关系、驱动绑定状态的结构。协议则是声明设备能力的契约接口：块设备协议规定读写块方法，让 SATA、NVMe、USB 存储被同一种方式访问；图形输出协议把各家 GPU 的寄存器编程收拢为统一的帧缓冲操作；设备路径协议用可序列化的二进制结构描述设备位置，是设备发现与定位的通用语。于是固件驱动开发从"写寄存器"升格为"实现接口"：NVMe 驱动只要把块设备协议实现正确，Shell 的列表命令就能认出它；虚拟显卡只要导出图形协议，就能在虚拟机里画出固件标志。句柄加协议，织成一张松耦合、高内聚、可插拔的硬件抽象网。

第二根：事件与通知——反应式引擎。 固件世界不是单线程阻塞的天堂：PCI 设备热插拔、USB 插入、定时器到点、网络包抵达，都得有人接住。UEFI 的事件模型就是应答：事件是固件级同步原语，本质是一枚支持多生产者多消费者、带优先级队列的信号量，创建、触发、检查、等待四类操作凑齐完整语义。更妙的是通知回调——某个协议一旦装上某个句柄，所有登记过对应通知事件的驱动自动被回调，"驱动即插即用"由此落地。这套机制是驱动模型的神经中枢，把固件从 BIOS 时代的轮询里解放出来。现代 UEFI 固件里，七成以上的驱动初始化流程都从监听镜像装载或驱动绑定协议的安装事件起步——名副其实的反应式固件。

第三根：内存管理——从实模式堆到内存池。 UEFI 的内存管理精细度远超 BIOS：按页分配支持多种策略（任意地址、限最大地址、指定地址）；池分配在启动服务堆里处理变长块；取内存图接口返回完整物理内存布局，含类型、属性、页数。更关键的是属性标记：给特定区域设写穿透、写回、写保护等属性，直接左右 CPU 缓存行为与一致性。安全上也靠它——把系统管理内存区标成写保护，恶意软件就改不动度量日志。

第四根：变量服务——跨重启的固件级键值存储。 读写变量这对服务是 UEFI 最具战略分量的一件武器：一块跨操作系统、跨电源周期、受固件保护的持久空间。变量有严格的命名空间（厂商 GUID）、属性位（非易失、启动服务可访问、运行时可访问）与访问控制。用途远不止"存启动顺序"：Secure Boot 的四类密钥（PK、KEK、db、dbx）全以变量形态存放，固件装载镜像前强制核对；度量启动把 TPM 度量值经相关变量交给系统做远程证明；OEM 拿私有 GUID 变量装 SKU 信息、校准参数、保修状态。变量服务的安全性立在硬件信任根之上——现代平台把变量放在 SPI Flash 受保护区，写入要过签名验证，使它成为整条可信链最底层的持久化信任锚。

⚠️ 常见坑：变量区不是无底洞。NVRAM 一般只有几百 KB，双系统多启动项加上反复装系统就能塞满；写满之后轻则启动项失踪，重则固件进恢复模式。排障先删不再用的启动项变量，别急着刷固件。

四、从原语到系统级能力

核心服务的价值，最终在三种上层范式中兑现。

模块化驱动架构。 UEFI 驱动不再是嵌死在固件 ROM 里的静态代码，而是遵守驱动绑定协议的可执行模块。固件启动时找出全部驱动绑定实例，按优先级排队，依次走支持判断、启动加载、停止卸载——全自动、可审计、可替换。OEM 可以单独升级 NVMe 驱动而不刷整机固件；云厂商可以往虚拟机固件里动态注入虚拟网卡驱动。这是核心服务送的"固件敏捷性"。

安全启动与度量链。 退出启动服务不只是交权，也是可信链的节点宣告：度量信任根（CPU 内部微码）量固件初始代码；固件量所有装载的驱动、应用、协议；退出前固件把最终度量值写入变量并锁死关键变量。链条的每一环都靠核心服务的原语撑着——没有这套结构化保障，可信计算永远停在纸面。

运行时系统管理。 现代服务器的智能功耗管理深度绑定运行时服务：取时间为热管理供精确时间戳；复位服务分出冷重启、热重启、关机三种语义，支撑优雅关机与故障自愈；带时间戳的签名变量更新属性，让 OS 以"时间戳加数字签名"的方式安全改写固件变量，实现带时效的策略下发。这些能力让 UEFI 从单纯的引导器，长成贯穿系统全生命周期的嵌入式管理协处理器。

💡 关键直觉：判断一个"固件功能"归哪个域，问一句话就够——系统跑起来之后还用不用它？用（时间、变量、复位）就是 Runtime；不用（枚举、分配、事件）就是 Boot。这个判断同时决定它的内存落哪个类型区、退出启动服务后还活不活。

温故知新

• 使能者定位：核心服务是平台无关性契约，相当于固件圈的 POSIX。
• 双域分权：Boot 是初始化主权（可回收），Runtime 是存续主权（必须继承），三轴解耦。
• 加冕礼三承诺：句柄坍缩、疆域割让、事件静默，皆不可逆。
• 四支柱：句柄协议（对象抽象）、事件通知（反应式引擎）、内存管理（页/池/属性）、变量服务（跨重启信任锚）。
• 变量战略价值：密钥、度量值、OEM 数据皆住变量区，硬件信任根把守写入。
• 三范式升维：模块化驱动、可信度量链、运行时系统管理，全部由服务原语孵化。

本章沿时间、空间、服务三根正交轴拆完了固件架构。下一章进入规范层，看 UEFI 用怎样的文件系统、驱动协议与 ACPI 表，把这些架构能力铸成可互操作的行业标准。

四、服务模型的最小可运行样本

三个服务层的分工，用一段真实的 EDK2 驱动代码最能讲清。下面是 DXE 驱动里调用 gBS（启动服务）安装一个协议接口的完整写法，事件通知用 gBS->CreateEventEx 注册到 EFI_EVENT_GROUP_READY_TO_BOOT——这条服务横跨了 DXE 与 BDS：

/* MdePkg 提供的原型；这是每个 DXE 驱动的标准动作 */
STATIC EFI_EVENT mReadyToBootEvent;

EFI_STATUS EFIAPI MyDriverEntry (
    IN EFI_HANDLE        ImageHandle,
    IN EFI_SYSTEM_TABLE *SystemTable
    )
{
    EFI_STATUS Status;
    VOID      *Interface = (VOID *)0xDEADBEEF;  /* 假装是我们的私有协议 */

    /* 启动服务：把驱动挂到镜像上 */
    Status = gBS->InstallProtocolInterface (
        &ImageHandle,
        &gEfiMyDriverProtocolGuid,     /* 128 位 GUID 标识 */
        EFI_NATIVE_INTERFACE,
        Interface);
    if (EFI_ERROR (Status)) return Status;

    /* 启动服务：注册"准备启动"事件组回调 */
    Status = gBS->CreateEventEx (
        EVT_NOTIFY_SIGNAL,
        TPL_CALLBACK,
        OnReadyToBoot,                 /* 系统每次准备交权前被回调 */
        NULL,
        &gEfiEventReadyToBootGuid,
        &mReadyToBootEvent);
    return Status;
}
​

运行时服务则是另一张表，字段更少、约束更狠。对照 gRT 的 C 结构定义与固件日志，可以看出它在 ExitBootServices 之后"只剩四个动作"：

/* MdePkg/Uefi/UefiSpec/UefiSpec.h 中 EFI_RUNTIME_SERVICES 的核心字段 */
typedef struct {
    EFI_TABLE_HEADER                Hdr;
    EFI_GET_TIME                    GetTime;       /* 读 RTC */
    EFI_SET_TIME                    SetTime;
    EFI_GET_WAKEUP_TIME             GetWakeupTime;
    EFI_SET_VIRTUAL_ADDRESS_MAP     SetVirtualAddressMap; /* 物理→虚拟地址切换 */
    EFI_GET_VARIABLE                GetVariable;   /* NVRAM 变量读 */
    EFI_SET_VARIABLE                SetVariable;   /* 写，SecureBoot 策略就存这里 */
    EFI_GET_NEXT_HIGH_MONO_COUNT    GetNextHighMonotonicCount;
    EFI_RESET_SYSTEM                ResetSystem;   /* 冷/热复位 */
    EFI_UPDATE_CAPSULE              UpdateCapsule; /* 第 6 章固件更新的入口 */
    /* ... 共约 20 个函数指针，没有内存分配、没有协议安装 */
} EFI_RUNTIME_SERVICES;
​

注意函数指针表里找不到 AllocatePool、InstallProtocolInterface——它们属于启动服务，交权后表头 CRC 失效、调用即违例。服务模型的边界就画在"这张表里有没有"。