3.2 协议与驱动模型

3.2 协议与驱动模型

本节摘要：协议与驱动模型是 UEFI 生态的神经与肌肉——协议是带 GUID 标识、含函数指针集、守二进制兼容规则的运行时接口契约；驱动模型是融合分层、状态机与安全策略的治理框架。本节拆开协议从安装到被发现的一生、驱动绑定三元组的状态机、四大协议族的分工，以及标准化、碎片化、安全博弈三股拉扯的张力。

本节导航

读完后你应当能：讲出协议"只谈契约、不设实现"的设计哲学；描述协议安装与按 GUID 检索的运行时流程；分清总线驱动、设备驱动、服务驱动三者的职责；说明绑定三元组各方法的纪律与状态机语义；举一个协议沦为攻击面的真实案例。

一、为什么需要协议：告别硬编码寻址

在传统 BIOS 里，硬件初始化全凭直奔固定的 I/O 端口、映射寄存器或中断向量表。程序员必须精确背下：显卡控制器占哪个端口区间、IDE 主通道基地址在哪、USB 主控配置空间的哪个偏移放着基地址。这些知识被硬编码进汇编或 C 代码，硬件拓扑一动、厂商一换芯片组，整条初始化链随时断裂。更伤的是无法支撑多厂商设备并存时的能力协商——一块 NVMe 盘和一块 UFS 存储控制器同时挂上 PCIe，谁来决定谁提供块设备抽象？谁裁启动设备优先级？谁保证 UEFI Shell 能用同一套命令挂载两者而不必为每种介质单独写代码？

UEFI 的回答只有三句：只约契约、不设实现；只发接口、不绑地址；只声明依赖、不强制顺序。

协议正是这套思想的落地。它不是 C 结构体定义，也不是某些驱动模型里的请求包，而是一份带唯一 GUID、带明确定义函数指针集、守严格二进制兼容规则的运行时接口契约。每个协议等于一项能力承诺：块设备协议承诺"我能以扇区为单位读写一段连续地址"；设备路径协议承诺"我能把任意物理逻辑设备路径序列化为可移植的二进制描述"；已加载镜像协议承诺"我能告诉你当前镜像装在内存何处、入口在哪"。

要点在于协议从不追问实现者身份——可以是主板厂的 SATA 驱动，可以是第三方塞进来的 NVMe Option ROM，也可以是 Shell 临时装载的 USB 存储驱动。只要块设备协议安装正确，上层消费者（启动管理器、系统加载器、诊断工具）就能无视实现细节，凭 GUID 检索并调用其读写方法。BIOS 时代"驱动与固件焊死、厂商与平台互锁"的镣铐就此解开。

可以拿城市交通作比：BIOS 时代的设备驱动像每辆车自带一册道路图纸并握着红绿灯控制权；UEFI 协议则像道路交通安全法——不指定哪辆车走哪条道，但统一规定转向灯、让行与速度分级的逻辑。协议是法典，驱动是守法公民，固件框架是交警与信号系统。

契约精神孵化出 UEFI 最有生命力的机制：协议的安装与重装。驱动装载后第一件事，就是经安装接口把协议实例登记进全局协议数据库；别的模块要用块设备时，按 GUID 搜句柄缓冲、打开协议拿接口指针、直接调方法。全程无需包含头文件、无需链接期解析、无需事先静态配置——一切运行时按需完成。

二、驱动模型：重点不在装载，在治理

如果说协议回答"能做什么"，驱动模型回答"如何被组织、何时被激活、受谁监管"。它绝不是一个简单的文件加载器，而是揉合分层架构、状态机控制、依赖注入与安全策略的运行时治理框架。

先分两大类：UEFI 应用是瞬态执行体（Shell、内存测试工具），跑完就走；UEFI 驱动是常驻服务者，存在意义就是安装协议、应答事件、维护设备状态。驱动再细三种：总线驱动枚举管辖总线下所有设备，给每台设备建句柄并装设备路径等基础协议，搭起设备树骨架（PCI 根桥驱动、USB 总线驱动即是）；设备驱动针对具体物理设备做功能实现，装块设备、网络标识等业务协议，通常依赖总线驱动给的底层 I/O；服务驱动不直接碰硬件，提供跨平台通用服务（TPM 物理存在管理一类），常当别的驱动的依赖项。

驱动装载不是乱堆，而是沿依赖图与执行顺序策略展开。规范定义了驱动绑定协议——驱动的"身份证"加"行为说明书"，每个驱动必须实现三个核心方法：支持探测方法声明本驱动能否接管某句柄，只做轻量探测（读个 PCI 厂商与设备号之类），绝不带副作用；启动方法在探测通过后被框架调用，做真正的初始化——分配资源、映射内存、装业务协议；停止方法在卸载或系统重置前打扫——放掉 DMA 缓冲、给设备断电、注销协议。

三元组构成一台可验证的状态机：驱动只可能停在未启动、已启动、正在停止三态之一，转换全由框架管。可观测性与可测试性因此前所未有——固件工程师可以在模拟环境注故障，看启动失败时是否干净回滚了探测阶段的动作；安全审计员可以静态审探测逻辑，确认没留侧信道（比如避免靠时序猜设备是否存在）。

依赖表达也很讲究。UEFI 不用内核式的编译配置宏，也不靠构建脚本的隐式链接顺序，而是走协议依赖声明：NVMe 驱动的探测方法内部必然要打开 PCI I/O 协议——协议没就绪，探测返回找不到，驱动自动跳过。框架据此织出一张以协议为边、以驱动为节点的有向无环图，保证所有前置依赖先于目标驱动就位。这种运行时能力求解，比编译期链接灵活，也更贴近硬件真实的协作逻辑。

多实例并发也是天生支持：主板上两颗独立 NVMe 盘由同一驱动的两个实例分别打理，各有句柄、协议实例与 DMA 缓冲池。对比 BIOS 时代全局变量打天下的写法——一颗盘掉线不会把另一颗的请求拖进死锁。

三、四大协议族：可信执行基座的骨架

UEFI 协议过百，真正撑起系统的只有四族。

设备抽象协议族：UEFI 的"地理信息系统"。设备路径协议把物理世界的连接关系（PCIe 拓扑、USB 层级、SATA 端口号）编码成可序列化、平台无关的二进制结构——一段典型的 NVMe 设备路径由多个节点串成，每节点带类型码与数据字段。启动管理器据此生成启动选项，加载器据此重建设备树；句柄则是这条路径在内存里的运行时化身，两者合璧完成设备身份在逻辑与物理间的双向映射。

I/O 访问协议族：UEFI 的"肌肉群"。它们不给业务语义，只给原子级硬件操作：PCI I/O 协议包揽配置空间读写、内存与 I/O 空间映射、DMA 缓冲分配；USB I/O 协议抽象事务调度、端点管理与包收发；SATA 直通协议允许上层直发 ATA 指令。设计哲学是最小完备——只暴露硬件必需的控制面，缓存一致性、中断合并这些高级特性一概留给操作系统，固件因此保持轻量与确定。

块与网络协议族：UEFI 的"感官系统"。块设备协议给扇区级读写，是一切存储启动的地基；磁盘 I/O 协议在其上补字节级随机访问，用来读文件系统元数据；网络协议族撑起 PXE——基础代码协议管 DHCP/TFTP，简单网络协议给帧收发原语。新版规范又添 HTTP 启动协议，固件可直接经加密通道拉启动镜像，固件网络栈由此迈入现代通信纪元。

安全与平台协议族：UEFI 的"免疫系统"。TCG2 协议是 TPM 2.0 的官方接口，支持度量寄存器扩展、密钥密封、远程证明；DXE 服务表提供内存空间管理接口，固件可把安全内存区主动标成不可执行或只读，为安全启动铺好物理地基；安全架构协议定义"安全策略执行点"，允许平台厂商注入自定义验证逻辑——比如装载 Option ROM 前验签、启动前查策略是否被动过。

四族从不孤立。一次典型的安全启动横跨全部四类：总线驱动枚举设备、装设备路径协议；NVMe 驱动经 PCI I/O 协议初始化控制器、装块设备协议；启动管理器用设备路径定位 ESP、用块设备协议读引导文件；安全架构协议介入，调 TCG2 协议对镜像哈希做度量扩展，并查签名库核验；全部过关才交出控制权。

⚠️ 常见坑：协议给了契约，却担保不了实现质量。个别厂商的块设备实现在复位方法里会悄悄丢掉未完成的 DMA 请求，RAID 卡热插拔即数据损坏；另有厂商的 USB 驱动在停止方法中没放干净中断，后续枚举跟着失败。这些"合规但不可靠"的实现逼得加载器写下一堆兼容代码——开源内核里针对特定主板的 NVMe 复位兼容补丁已有十来处。选型别只看"过没过认证"，要翻厂商的兼容性修复史。

四、演化张力：标准化、碎片化与安全博弈

协议与驱动模型的落地，始终被三股力拉着走。

标准化之力。 UEFI 论坛持续扩编协议族：近年新增人机接口配置访问协议，改善固件设置界面的可访问性；草案里还出现了让固件原生生成并导出 ACPI 表的协议，意在省掉系统的重复解析。每一次增补，都是对硬件能力抽象边界的重新划线。

碎片化之压。 规范统一，实现参差。"合规但不可靠"前文已经见过。法条再完善，也要靠司法实践来校准。

安全博弈之潮。 协议本身已成攻防焦点。研究者披露过的攻击包括：某厂商固件中已加载镜像协议的镜像基址字段缺范围检查，攻击者构造恶意句柄即可越界读；多家厂商驱动打开协议时不验调用者权限，低特权应用得以窃取高敏感协议句柄。协议不是银弹而是双刃剑——它既撑起安全启动，也放大实现缺陷的波及半径。

正因如此，新一代设计正悄悄转向协议沙箱化与驱动强制签名：机密计算的硬件虚拟化尝试给每个驱动划独立内存保护域；操作系统认证体系已要求全部 UEFI 驱动经签名工具签署、并在安全架构协议里强制核验。协议与驱动，正从"能力开放"走向"能力授信"。

💡 关键直觉：调试一块认不出的 PCIe 设备，先在 Shell 里枚举该句柄上已装的协议清单——连设备路径协议都没有，问题在总线枚举；有设备路径没业务协议，问题在设备驱动的探测或启动；协议齐全而上层不认，问题在消费端。协议清单是固件世界的"设备能力透明宣言"，比反复插拔硬件省事得多。

核心回顾

• 契约哲学：只约契约不设实现、只发接口不绑地址、只声明依赖不强制顺序。
• 运行时发现：安装接口登记 GUID 与函数指针，消费者按 GUID 搜句柄再开协议，编译期零绑定。
• 三类驱动：总线（骨架）、设备（功能）、服务（依赖项），依赖经协议声明解成有向无环图。
• 绑定三元组：探测（无副作用）、启动（真初始化）、停止（清扫），合成可验证状态机。
• 四大协议族：设备抽象（地理信息）、I/O 访问（肌肉）、块与网络（感官）、安全平台（免疫）。
• 攻防现实：镜像基址未校验、打开协议未验权——协议放大实现缺陷，签名与沙箱是收敛方向。

下一节看固件递给操作系统的最后一份大礼：ACPI 表——用数据声明取代指令探测的硬件宪法。

四、协议模型的三张契约与一条命令

驱动模型的核心是 EFI_DRIVER_BINDING_PROTOCOL，三个函数 Supported/Start/Stop 构成"认领—接管—放手"契约。EDK2 里最小的实现长这样：

/* EFI_DRIVER_BINDING_PROTOCOL 的标准填法（节选自 MdeModulePkg 的编驱动骨架） */
EFI_DRIVER_BINDING_PROTOCOL gMyNvmeDriverBinding = {
    MyNvmeDriverBindingSupported,   /* 只认领 class=01(存储) subclass=08(NVMe) */
    MyNvmeDriverBindingStart,       /* 配 BAR、发 Admin 命令、InstallProtocolInterface */
    MyNvmeDriverBindingStop,        /* 撤协议、关控制器，允许热拔 */
    0x10,                           /* Version：数字越大越优先被调 Supported */
    NULL, NULL                      /* ImageHandle/DriverBindingHandle 由框架回填 */
};

STATIC EFI_STATUS EFIAPI MyNvmeDriverBindingSupported (
    IN EFI_DRIVER_BINDING_PROTOCOL *This,
    IN EFI_HANDLE                  ControllerHandle,
    IN EFI_DEVICE_PATH_PROTOCOL   *RemainingDevicePath OPTIONAL)
{
    /* 经典三查：能否打开 PciIo？class code 对不对？ */
    Status = gBS->OpenProtocol (ControllerHandle, &gEfiPciIoProtocolGuid,
        (VOID **)&PciIo, This->DriverBindingHandle, ControllerHandle,
        EFI_OPEN_PROTOCOL_BY_DRIVER);
    if (EFI_ERROR (Status)) return Status;
    PciIo->Pci.Read (PciIo, EfiPciIoWidthUint8, PCI_CLASSCODE_OFFSET, 3, &ClassCode);
    gBS->CloseProtocol (ControllerHandle, &gEfiPciIoProtocolGuid, ...);
    return (ClassCode[2] == 0x01 && ClassCode[1] == 0x08) ? EFI_SUCCESS : EFI_UNSUPPORTED;
}
​

Supported 必须做到无副作用——总线驱动会对每个句柄反复试探，写寄存器就闯祸了。

整套模型运行时的样子，UEFI Shell 的 drivers 命令直接可见，比文字描述直观得多：

Shell> drivers
           T   D
           Y C I
           P R A
DriverVer  e g F          Driver Name                              Version
========== = = = ======================================== ========
     1 Bug? X -   PcBus (PCI Host Bridge Driver)               0000000A
     3 ...  X X   Serial Terminal Driver                       0000000A
     7 ...  X     English Keyboard Driver                      0000000A
    12 ...  X X   PS/2 Keyboard Driver                         0000000A
    30 ...  R X   Management Mode Interface Driver             0000000A
    44 ...  R X   NvmExpressDxe (NVMe Host Controller)         0000000A
    51 ...  B X   FAT File System Driver                       0000000A
    61 ...  ? ?   IsoInteractiveShell                         0000000A
     T(ype): B=Boot R=Runtime S=Standard? Y?
     C(ontrolling): X=Controlling driver B=Bus? D=Diagnostic D?
     I(Framework): F=EFI 1.10 U=UEFI 2.x ?=Unknown
​

44 号 NVMe 驱动处于 Controlling 状态——它已认领了 NVMe 控制器并装出了 BlockIo 协议；51 号 FAT 驱动再认领磁盘分区装出 SimpleFileSystem。协议一级级接力，正是本章"消费者/生产者"链条的实景。