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

作者：Michael Rothman，Vincent Zimmer

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

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

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

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

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

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

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

国际金融机构规范

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

平台初始化 （PI） 规范

定义如何构建底层平台固件。

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

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

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

图1 固件源树产品的演变

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

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

关于攻击的类别，市场上已经观察到很多。其中包括早期 PI 或更高版本的 DXE 流中的特权提升、错误的选项 ROM（旨在初始化特殊设备），甚至是攻击硬件。针对固件的攻击类别的示例可以在下面的图 3 中看到。

图3 固件攻击的分类

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

图 4 UEFI 固件的供应链

主机固件的作用是什么？

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

图 5 UEFI PI 固件的启动流程

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

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

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

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

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

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

图 7 胶囊更新启动流程

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

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

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

审核编辑：郭婷