了解UEFI固件更新及其在确保计算系统安全方面的重要作用

作者：Michael Rothman，Vincent Zimmer

在本文中，我们将介绍以安全、可管理和可观察的方式在现场更新基于计算的平台的方法。

在整篇文章中，我们还将介绍存在哪些底层组件来实现所有这些工作，特别是在基于 UEFI 的固件实现Beyond BIOS 的上下文中。

让我们从“平台固件”开始，在这种情况下，平台固件由嵌入式逻辑定义，该逻辑有助于初始化平台硬件并启动引导目标。此固件通常驻留在计算机的主板上，甚至驻留在插件设备（如存储控制器和网络设备）上的芯片上。

最终，平台启动固件的要点是启动目标软件，通常是操作系统。

从历史上看，启动固件没有一组可跨平台、第三方硬件和操作系统域互操作的标准化应用程序编程接口 （API）。这些组件中的每一个都有自己的编程孤岛，几乎没有标准交互。

然而，在2005年，UEFI（统一可扩展固件接口）论坛成立。其主要目标之一是为机器内的组件如何相互通信提供行业标准。

简而言之，UEFI 论坛涵盖三个主要规范：

UEFI 规范

平台与第三方内容（如操作系统或插件设备）之间的 API 集。

平台初始化 （PI） 规范

定义如何构建基础平台固件。

高级配置和电源接口 （ACPI） 规范

定义从平台到操作系统的不可发现信息和运行时交互的抽象。

如上所述，固件执行许多角色。固件的实施基于行业标准，例如 UEFI PI 规范。PI 阶段包括预 EFI 初始化 （PEI） 和驱动程序执行环境 （DXE）。通常，一个平台可能有 50 个 PEI 模块和 180 个 DXE 模块。构建这些元素的源代码树可以包含数十万行 C 代码，随着产品的发布，将策划各种分支，如图 1 所示。

图1 固件源码树产品的演进

这些模块和驱动程序都在环 0 内执行，并且通常没有组件间分离，这在操作系统中的应用程序中很常见。因此，任何组件中的缺陷都可能导致平台的潜在危害。其中许多组件使用攻击者控制的输入，例如磁盘上的数据结构、操作系统设置的 UEFI 变量等策略对象以及来自未受保护总线的输入。如此大量的可执行代码具有许多攻击面，随着新技术的引入，会创建更多面。对 UEFI 固件实现必须支持的各种标准的支持会增加复杂性。这些标准的演变见下文图2。

图2 固件支持的规格和标准的演变

关于攻击的类别，市场上已经观察到许多攻击。其中包括权限升级到早期 PI 或以后的 DXE 流、错误的选项 ROM（旨在初始化特殊设备），甚至攻击硬件。针对固件的攻击类示例如下图 3 所示。

图3 固件攻击分类

通过UEFI论坛和开源社区建立了报告机制，以支持负责任地披露这些安全问题。然而，挑战在于分散的供应链。例如，EDKII 代码在tianocore.org上的使用需要经过许多人的处理，例如开源到芯片供应商、芯片供应商到原始设备制造商 （OEM） 以及 OEM 到原始设备制造商 （ODM）。例如，TianoCore 中的缺陷如何最终在其系统上的最终用户闪存 ROM 中为由 ODM 生成的设备进行更新？当今供应链和修补的复杂性可以在下面的图 4 中得到证明。

图4 UEFI固件供应链

主机固件的作用是什么？

引导固件分阶段初始化，包括 PEI 和 DXE，如图 5 所示。

图5 UEFI PI固件启动流程

在 （DXE） 驱动程序执行环境中，我们枚举平台上的设备，然后执行逻辑来初始化这些设备。有时，如果这些设备众所周知并符合某些标准，则这些设备可能在固件中具有内置支持，而其他设备可能具有设备携带的初始化代码，并且反过来由固件启动。

在后一种情况下，设备的初始化代码通常会公开固件管理协议 （FMP） 接口，如果需要，该接口可用于现场更新。

固件初始化的最后阶段是操作系统加载程序通过 UEFI API 与固件交互并促进其自身的初始化。它还可以通过各种方式执行固件更新，例如基于胶囊的更新。

如前所述，固件更改可能会穿过芯片供应商、固件供应商、OEM 和 ODM 供应链的曲折路径，出现在最终用户系统中。从历史上看，这些当事方中的许多都有自定义更新工具，这些工具必须安装到各种操作系统和独特的位置中才能发现和下载更新。这种蒙昧主义的空间，即如何更新您的设备，通常导致许多最终用户不维修他们的设备并及时更新他们的固件。

进入 UEFI 胶囊。UEFI 胶囊包含各种元素，包括将更新本身的二进制封装到称为 UEFI 胶囊的东西中。UEFI 胶囊具有由全局唯一标识符 （GUID） 命名的明确定义的标头。系统固件的生产者将其更新有效负载（无论是代码、数据还是更新驱动程序）包装为此格式。然后，通过使用胶囊生产者拥有的密钥材料在胶囊中应用加密签名来保证更新的来源。

使用胶囊后，OS 可以通过引用 EFI 系统资源表 （ESRT） 来确定平台是否支持此胶囊类型，该表 （ESRT） 是一系列指定平台中的版本和可能可更新元素的 GUID。如果手头的胶囊 GUID 与 ESRT 条目匹配，则操作系统可以暂存，或者预操作系统 UEFI 应用程序将使用上述胶囊二进制文件作为参数发出 UpdateCapsule（） UEFI 运行时调用。Linux 和 Windows 通常通过将胶囊复制到操作系统前的可访问位置（如 EFI 系统分区 （ESP））并重新启动来暂存更新。重新启动后，UEFI OS 加载程序可以发出 UpdateCapsule（） 调用，设备将重新启动。在重新启动期间，UEFI PI 代码将确定胶囊位置，可能合并，加密验证，如果真实，则使用更新更新闪存。整体流程如下图所示 7。

图 7 胶囊更新启动流程

更新发生后，可能会对系统稳定性有一些担忧。因此，UEFI ACPI 规范中有一些功能，例如平台运行状况评估表 （PHAT），可以查询以查看系统状态是否有任何意外更改。更新还会影响系统完整性，如平台配置寄存器 （PCR） 中的更改所示。因此，在更新之前，操作系统可能需要解封机密，发布更新，然后针对最新的 PCR 重新密封。

为了促进生态系统创建胶囊，TianoCore / EDK2资源提供了一个模板，用于创建基于UEFI固件管理协议的更新驱动程序，创建ESRT条目，签名等。生态系统中还支持使用Linux供应商固件服务（LVFS）和Windows Update（WU）管理Linux中的胶囊更新。鉴于链的强度取决于其最薄弱的环节，因此可以在构建安全固件中找到有关构建高保证固件的一些最佳实践。

总之，本文讨论了以安全、可管理和可观察的方式执行固件更新的方法。这些属性通过基于 UEFI 的固件中的基础结构启用，包括基于加密的胶囊、PHAT 和 FMP 协议。

审核编辑：郭婷