固件攻击面减少 (FASR)

2019 年 10 月，Microsoft 与我们的 OEM 和芯片合作伙伴密切合作，推出安全核心 PC。 这些设备具有深度集成的硬件、固件和软件，以帮助确保增强设备、标识和数据的安全性。 安全核心 PC 的核心安全支柱之一是帮助为设备提供固件保护。 满足此支柱所需的基于硬件的基本功能是动态可信度量根 (D-RTM)。但是，由于此功能依赖基础芯片集，目前提供 D-RTM 的设备并不多，这导致我们无法兑现帮助所有 Windows 设备提高和维持高安全标准的承诺。

可以采取更多措施来增强所有 Windows 设备（包括这些没有 D-RTM 的设备）的安全状况。 Microsoft 正在与合作伙伴合作，通过开发一组开源 SMM 安全增强功能，为 OEM 提供更高的灵活性，从而解决阻止 UEFI 固件应用内存保护的兼容性问题。

为了反映对固件安全的这一承诺，我们确定了一种新方法，以确保设备能够满足安全核心 PC 的固件保护要求。

FASR 概览

对于缺少基于硬件的 D-RTM 功能的安全核心 PC，我们必须定义少量固件组件来减少攻击面，并且可以在操作系统中证明其有效性。 此方法称为固件攻击面减少 (FASR)。 若要使基于 FASR 的固件在不同供应商的 PC 之间进行扩展，必须定义新的固件启动方法。

FASR 支持两个启动路径：

1. 经认证的启动路径：

   • 仅允许使用 Microsoft 信任、签名和集成的代码执行。

   • 操作系统可检测启动路径篡改。

   下图显示经过认证的启动路径上的 FASR S-RTM 启动流。 此启动路径有助于防止执行意外平台固件代码。 但是确实会使用自定义启动路径提供的一些特定于平台的数据。 下图显示经过认证的启动路径上的 FASR 启动流。

   

2. 自定义启动路径：可以执行所有平台固件代码。 特定于特定 OEM/平台的关键启动信息将转换为自定义启动路径上的数据，并由经过认证的启动路径用于在该启动路径上正确配置系统。 下图显示自定义启动路径上的 FASR 启动流。

   

   为安全核心 PC 合规性启用的 FASR 设备默认为经过认证的启动路径，除非发生了导致启动在固件启动过程早期切换到自定义启动路径的事件。 此类事件的示例包括固件更新、用户请求了固件 UI，或者用户已选择禁用安全核心 PC，这意味着在重新启用之前，它们将始终在自定义启动路径上启动。

   自定义启动可用于启动支持 FASR 的设备上的平台固件支持的任何操作系统或第三方软件，但 Windows 不会将自定义启动路径上的启动识别为安全核心 PC 兼容。

为了更好地了解 FASR 背后的安全技术，我们希望与您分享 Windows 启动过程的简要概述。

Windows 启动过程

信任根

新式 PC 中的初始固件执行遵循启动过程，其中初始代码集加载其他代码，随着启动进展，功能级别会扩展。 每组代码验证构成信任链的下一组代码。 当 UEFI 固件获得控制时，遵循验证软件签名的安全启动标准，以持续使用操作系统的信任链。 然后，Windows 启动加载程序继续使用受信任启动的信任链，在加载之前会验证启动过程中的所有其他 OS 组件。

通常，攻击者会在启用有助于保护系统的安全功能和锁之前尽早控制启动过程。 当系统退出重置时，必须以信任方式定位执行的初始代码集。 履行执行此早期代码验证角色的硬件验证技术称为信任根。 虽然确切的详细信息因硬件供应商而异，但所有信任根通常都植根于 SOC 中的不可变硬件或 ROM。

测量启动

安全启动定位在信任根中有助于确保验证所有固件的数字签名；但是，还需要有固件具体执行操作的记录。 Windows 硬件兼容性计划要求所有 Windows 10 和 Windows 11 PC 都包含一个名为“受信任的平台模块 (TPM)”的芯片。 TPM 包含名为“平台配置寄存器 (PCR)”的内存位置。 每个 PCR 都包含启动期间加载的代码和/或数据的哈希，例如非易失性存储设备（例如 SPI 闪存）上的固件代码、PCI 设备中的可选 ROM 或 OS 启动加载程序。 可以存储在 PCR 中的值的大小取决于支持的哈希算法的摘要大小。 例如，SHA-1 PCR 可以存储 20 个字节，而 SHA-2 PCR 可以存储 32 个字节。 与同一哈希算法关联的多个 PCR 称为库。 TCG PC 客户端 TPM 配置文件规范定义至少一个具有 24 个寄存器的 PCR 库的包容性。

在 TPM 存在的情况下，每个固件组件还可以在启动过程中加载新代码和数据时更新或扩展相应的 PCR。 扩展过程使用与新代码或数据参数连接的当前 PCR 值作为输入将 PCR 值更新为哈希算法的输出。 因此可以在启动过程后检查 PCR 以确定执行的操作。 这样，操作系统中的软件就可以了解启动过程是否不同于以前的启动过程。 在安全敏感环境中，操作系统可以了解某些 PCR 中预期的确切代码组度量值，以检测意外固件代码的执行情况。 由于库中的前 16 个 PCR 只能通过重置整个 TPM 来重置，因此它们受信任，并且是用于在 TPM 中存储重要度量值的首选位置。

用于测量的信任根

现在，我们已了解信任根的角色以及测量的启动的使用方式，下面我们将探讨两种建立信任根的方法，以便向 TPM 报告度量链：静态和动态。

静态度量信任根 (S-RTM) 在系统重置时建立信任，并要求在整个启动过程中维护信任。 如果信任在启动过程的任何时刻受影响，则在系统重置之前无法恢复信任。 下图说明如何在经认证的启动路径上使用 S-RTM。

相比之下，动态度量信任根 (D-RTM) 仅信任少量早期芯片集初始化固件代码，以及用于在启动期间动态重新建立信任的硬件代理。 系统最初可以启动到不受信任的固件代码，但启动后不久，通过控制所有 CPU 并强制其进入已知测量的路径，还原为受信任状态。 下图概述传统的 D-RTM 流。

在 S-RTM 和 D-RTM 之间进行取舍。 S-RTM 不需要特殊的硬件功能，但需要软件来更好地考虑整个启动期间执行的代码。 D-RTM 需要特殊的硬件功能，但允许软件在系统的生存期内动态启动到受信任状态。

Windows 安全核心 PC 使用安全启动中的 D-RTM，使广大系统制造商能够灵活地在固件中实现独特的功能和体验，同时帮助确保系统能够达到托管安全操作系统环境可以接受的受信任和测量状态。 D-RTM 启动事件用于在加载安全内核之前从未知环境重新建立信任。 下图显示用于重新建立已知系统环境的 D-RTM 启动事件。

过去，由于 S-RTM 缺乏对特殊硬件功能的依赖，因此可以在多个设备中实施 S-RTM 来验证系统的安全状态，但操作系统没有可靠的方法来确认能否信任使用 S-RTM 在任何给定的 Windows 设备上报告的度量值。

固件安全增强

最小化 OS 启动路径中的固件组件

信任 S-RTM 度量的一种方法是减少允许执行最少量的固件组件。 如果所有使用 S-RTM 的设备都使用同一组固件组件，则操作系统只需信任一组已知和受信任组件的预期 SSD 值。 使用此基于 SRTM 的方法，当验证启动固件集时，可以将设备视为满足安全核心 PC 的固件保护要求，以仅包含可由 Windows 证明的 Microsoft 签名软件。 为了更好地了解这些固件组件与普通 PC 启动时的固件组件有何不同，让我们检查启动前后的过程。

由于现代 PC 固件提供的灵活性和丰富的功能集，在操作系统之前执行的代码会导致攻击面增加。 下图显示传统的 S-RTM 启动流示例。

启动期间固件的主要职责可以大幅简化为：

• 特定于平台的功能：仅适用于特定平台硬件设计的功能。

• 非特定于平台的功能：行业标准和其他硬件常见的功能。

相对较小的新式固件子集通常特定于平台。 执行常见任务（例如分配内存、调度固件驱动程序、处理事件等）的大部分固件基础结构代码在所有（或大多数）基于 UEFI 的系统之间均相同。 这些任务的固件二进制驱动程序可跨 PC 重复使用。 此外，行业标准硬件规格和接口使通用固件驱动程序能够初始化硬盘、USB 控制器和其他外围设备。 此硬件的固件二进制驱动程序也可以跨 PC 重复使用。 总之，PC 可以启动一组最少的常见固件驱动程序。

减少启动期间加载的总固件驱动程序组可能会产生其他优势：

• 改进启动时间

• 减少更新所需的供应商协调

• 减少错误暴露

• 减少攻击面

FASR 启动路径验证和安全核心合规性

若要使 FASR 系统满足安全核心 PC 的固件保护要求，必须在经认证的启动路径上启动。 FASR 固件通过向操作系统提供名为 FASR 清单（测量为 TPM）的 Microsoft 签名清单（测量为 TPM）（该清单包含认证路径上模块启动序列的预期 PCR 值）来促进这一过程。 这可以与认证路径上发生的实际启动序列进行比较。 如果这些度量值匹配，则系统被视为满足安全核心 PC 程序的固件保护要求。 与预期的认证启动路径序列的任何偏差都会导致对操作系统检测的 TPM 平台配置寄存器 (PCR) 进行意外测量。

此外，Windows 仅在根据当前启动期间记录的度量值成功验证已签名 FASR 清单时才公开虚拟机监控程序保护的机密。 如果经认证的启动路径或封装程序更新不存在 FASR 清单，则签名验证失败或发生 PCR 不匹配，并且不会解封或迁移 VSM 机密。

FASR 固件如何解决内存保护和 SMM 问题

现在，已定义一个具有最少功能集的 Microsoft 签名二进制文件，因此可以包括 Microsoft 正在与合作伙伴合作推向市场的基本但缺少的固件安全保护。 经认证的启动路径必须至少满足以下要求：

1. 代码不读/写到 NULL/第 0 页

2. 映像代码和数据部分分开

3. 映像分区在页面 (4 KB) 边界上对齐

4. 数据仅分配给数据内存类型，代码分配给代码内存类型

5. 代码映像不会从作为 UEFI 二进制文件分发的代码加载（仅指定的调度程序）

6. 代码保留在已分配内存缓冲区的边界内，在页面分配周围有保护页

7. 可以检测到堆栈溢出

8. 代码不从堆栈执行

9. /NXCOMPAT DLL 特征设置为启用 NX 保护

第三方选项 ROM、UEFI 应用程序和 UEFI 驱动程序通常未根据这组要求构建或验证。 因此，它们不会在经认证的启动路径上执行。 自定义启动路径可以选择降低所需的保护级别，但该启动路径不被视为操作系统兼容的安全核心 PC。

系统管理模式 (SMM)

SMM 是 x86 体系结构中的特殊处理器操作模式。 它对系统安全性提出了独特的挑战，因为 SMM 环境中执行的代码对操作系统不透明，通常以主机处理器上软件的最高权限级别（有时称为“Ring -2”）执行。 进入后，SMM 通过设置页表、中断调度表 (IDT) 和其他系统结构来配置自己的环境。 SMM 表示严重的攻击面，恶意代码可以利用此攻击面来破坏或规避通过基于虚拟化的安全功能 (VBS) 启用的 OS 保护。 为了帮助缓解 SMM 构成的危险，SMM 中的功能可以从概念上拆分为 SMM 核心基础结构和 SMM 驱动程序，如下所示：

• SMM 核心：执行体系结构和基础结构责任的所有 SMM 实现通用的代码

• SMM 驱动程序：编写用于在 SMM 中完成特定于平台的任务的代码

SMM 生命周期中的一些关键时刻如下：

1. 建立 SMM 基础（或核心）时 – SMM 初始程序加载 (IPL)

2. 加载 SMM 驱动程序时 – 称为 SMM 驱动程序调度

3. 进入 SMM 时 – 通过系统管理中断 (SMI)

SMM 初始程序加载 (IPL)

CPU 具有特殊功能，可授予 SMM 代码高特权并帮助保护它。 例如，一种机制定义为通过软件或硬件事件进入 SMM，使用 CPU 指令从 SMM 返回，并定义了多个寄存器来控制 SMM 的访问和锁定配置。 其中许多控制寄存器由 SMM IPL 代码配置，以限制对存储 SMM 代码和数据的内存区域（称为系统管理 RAM 或 SMRAM）的访问。

由于 SMRAM 区域位于主内存 (DRAM)，因此启用 DRAM 之前无法在启动期间建立。 DRAM 启用过程因芯片供应商而异，但是在主内存可用之前，相当多 MB 的代码可以直接从 CPU LLC 缓存（包括初始化 DRAM 的代码）运行。

FASR 固件比大多数其他系统更早地将 SMM IPL 点引入启动。 这可以减少攻击者在设置 SMM 之前破坏此过程并控制系统的机会。 为了更好地了解这一点以及对 FASR 固件中的 SMM 所做的其他改进，我们需要了解有关固件启动过程的详细信息。

UEFI 固件中的平台初始化 (PI) 启动

新式 PC 固件围绕许多规范构建。 UEFI 规范定义 UEFI 兼容操作系统（如 Windows）与设备上的固件之间的接口。 另一种规范称为平台初始化 (PI) 规范，定义固件驱动程序的构建方式，并详细介绍启动过程本身。 在高级别，可以将 UEFI 规范视为允许单个 Windows 映像处理很多不同设备的标准化之一，PI 规范可以视为允许不同硬件供应商的很多固件映像协同工作的标准化之一。 这两种规范都由 UEFI 论坛维护。

PI 规范定义启动阶段，以及哪些驱动程序写入启动阶段。 在固件启动期间，每个阶段将移交给下一阶段，在大多数情况下，不再使用阶段移交的驱动程序，并且仅将重要数据传递到下一阶段，以便可以继续启动过程。 启动阶段可以总结如下：

1. SEC – 获取 CPU 重置矢量的控制，并从程序集转换到 C 代码以加载 PEI

2. PEI – 初始化系统状态以加载 DXE 并初始化 DRAM

3. DXE – 执行剩余的系统初始化，其中包括提供加载操作系统所需的支持 BDS

4. BDS – 发现当前启动的启动选项（例如 OS 启动加载程序）并尝试启动该选项

5. OS – 操作系统内核

保护 SMM 初始程序加载 (IPL)

符合 UEFI PI 规范的传统固件在 DXE 启动阶段加载 SMM IPL。 FASR 固件在 PEI 启动阶段加载 SMM IPL。 受信任计算库 (TCB) 是保护系统的一组保护机制，包括硬件、固件和软件。 通过将 SMM IPL 从 DXE 移动到 PEI，将从 TCB 中删除整个 DXE 阶段（比 PEI 更大且更丰富的环境）。 下图显示在 UEFI 启动过程早期移动的 SMM IPL。

PEI 和 DXE 代码在环 0 处执行，并且不会在操作系统中保留（很少例外）。 SMM 代码以比环 0（和虚拟机监控程序）更高的特权执行，并保存到操作系统中，因此不允许 DXE 漏洞影响 SMM 的建立，从而减少整个系统攻击面。 此外，由于 SMM 在启动过程早期启动，因此可以提前启用帮助保护 SMM 的锁定位集，从而进一步将攻击者入侵 SMM 的时段减至最少。

保护 SMM 驱动程序调度过程

PI 规范中定义了两种 SMM 模式：传统 MM 和独立 MM。 传统 MM 相当于以前在 PI 兼容固件中使用的 SMM 软件模型，这构成行业中的大部分 UEFI 固件。 独立 MM 是一种相对较新的模式，通过修改历史模型来提高 SMM 环境的安全性，并防止传统 MM 实现中出现的常见错误，这些错误导致多年来出现许多可移植性和安全挑战。

FASR 固件仅在独立 MM 模式下运行。 这样，FASR 固件就可以遵循在 SMM 中执行软件的严格方法。 目前，许多基于 SMM 的漏洞由传统 MM 中 SMM 代码允许的不良做法造成，这些做法只能在独立 MM 中删除。 在高级别，发生这种情况是因为，在传统 MM 模型中，SMM 驱动程序被调度两次，一次由环 0 中的 DXE 调度程序调度，另一次由 SMM 中的 SMM 调度程序调度。 这为 DXE 环境中执行的驱动程序代码提供了充足的机会，以缓存指向 SMRAM 外部资源的指针，这些资源在入口点返回后不得访问。 依赖 SMM 代码调用 SMM 外部代码的攻击通常称为“SMM 标注攻击”。

保护 SMM 条目

数据通过名为“通信缓冲区”的结构传递到 SMI 处理程序。 SMI 处理程序负责验证数据是否满足入口点的某些要求。 Windows SMM 安全缓解表 (WSMT) 是一种机制，用于帮助缓解未选中 SMI 处理程序对操作系统中基于虚拟化的安全功能构成的威胁。 Microsoft 为 TianoCore 项目提供了代码，以改进通信缓冲区验证。 除了利用这两种技术外，FASR 代码还实施严格的内存访问保护，允许 SMM 代码仅访问显式允许的内存范围。

管理模式监控程序（MM 监控程序）

SMM 核心代码很常见，并且只需最小限度更改即可在系统之间共享。 通过将特权分离引入 SMM 环境，可以大大减少 SMM 施加的攻击面。 因此，FASR 固件包括在独立 MM 中执行的 SMM 监控程序。 这会导致明确定义的 SMM 环境，以及具有创建时强制实施的特权级别的最小 TCB。 MM 监控程序对 IO 端口访问、模型特定寄存器 (MSR) 访问、MMIO 访问、CPU 保存状态访问以及 SMM 环境中的允许指令进行了限制。 SMM 监控程序策略用于配置要限制的硬件资源的确切详细信息，这些确切的详细信息可能会根据芯片的代数发生更改。

该策略最近已转换为默认拒绝方法，可显著减少 SMM 监控程序外部代码可用的硬件资源。 此监控程序在不依赖新式 PC 中不常见的任何硬件功能的情况下运行。

FASR 中使用的 MM 监控程序开源，可在 Project Mu MM 监控程序存储库中使用。

FASR 系统符合安全核心 PC 要求

下表显示安全核心 PC 的主要安全支柱或目标，以及 FASR 系统如何在认证路径中启动才能达到安全核心 PC 的要求：

安全优势	安全核心 PC 中的安全功能
创建硬件支持的信任根	安全启动
	受信任的平台模块 2.0
	直接内存访问 (DMA) 保护
防御固件级攻击（请参阅下面的说明）	系统防护安全启动 (D-RTM) 或 S-RTM (FASR FW)
	系统管理模式 (SMM) 隔离或独立 MM 与 MM 监控程序 (FASR FW)
防止 OS 执行未经验证的代码	内存完整性（也称为 HVCI）
提供高级身份验证和保护	Windows Hello
在设备丢失或被盗时保护关键数据	BitLocker 加密

如果系统没有支持 D-RTM 的高级安全功能，则可以使用 S-RTM 和独立 MM 与 MM 监控程序的组合来满足固件保护要求，这两者均由 FASR 固件提供。

总结

这些是 Microsoft 为应对当今整个行业普遍存在的日益增多的固件攻击而做出的一些投资。 通过使用开源代码进行这些更改，我们授权合作伙伴利用其中一些安全优势，进而更广泛地造福生态系统和行业。

安全核心 PC 计划的主要目标是帮助确保客户有权访问适用于 Windows PC 的一些最先进的安全功能。 通过其中一些固件更改，我们距离实现该目标更近了一步，并更新了安全核心 PC 的固件保护要求，以反映此内容。 在此处了解有关安全核心 PC 的详细信息。