本章描述平台弹性的一个重要方面 —— 恢复。这支持CIA三要素（保密性、完整性和可用性）中的可用性方面。如果平台检测到组件（包括代码或数据）的完整性被破坏，平台需要将组件恢复到已知的良好状态。这一过程称为恢复。它是固件弹性的最后一个要素。恢复过程是更新过程的一个变体。它将系统更新到旧状态。因此，在恢复过程中应遵循更新的所有指导，如签名检查和版本检查。
恢复过程由恢复信任根（RTRec）或恢复信任链（CTRec）执行。RTRec和CTRec应为不可变代码或已知的良好代码。如果RTRec或CTRec无法建立，则最终用户必须执行手动恢复。例如，如果整个闪存芯片损坏或擦除，甚至获取的第一条CPU指令都是无效操作码。在这种情况下，最终用户可能需要在闪存芯片上接入闪存编程器并烧录新的镜像，或者将机器运回制造商处维修。
RTRec和CTRec可能与检测信任根(RTD)和检测信任链(CTD)相同，也可能不同。根据RTRec和RTD之间的关系，平台可能使用不同的方式进行恢复（见表5-1）。
表 5-1 恢复策略
| 机制 | RTRec/RTD关系 | 细节 | 实例 |
|---|---|---|---|
| 立即恢复 | RTRec与RTD是一样的。 | 一旦RTD检测到未经授权的更改，RTD就会调用RTRec，RTRec会立即开始进行恢复。 | EDK II签名恢复。Coreboot恢复。HP Sure Start。Cerberus项目。英特尔PFR冷重启。 |
| 重置恢复 | RTRec在RTD/CTD之前运行。 | 一旦RTD/CTD检测到未经授权的更改，RTD/CTD就将平台状态设置为"恢复模式"并重置系统。在下次启动时，RTRec检测“恢复模式”并执行恢复。 | 英特尔PFR热重启。 |
| 降级启动和延迟恢复 | RTRec在RTD/CTD之后运行。 | 一旦RTD/CTD检测到未经授权的更改，RTD/CTD将继续启动系统，并携带验证失败时的可检测指示符，例如TPM测量值。平台RTRec可能有机会在后续将系统恢复到正常状态。 | 带有执行策略设置为超时关机的英特尔Boot Guard。 |
| 停止和带外恢复 | RTD与RTRec在不同领域。 | 一旦RTD/CTD检测到未经授权的更改，RTD/CTD就会立即停止系统，而不具备任何带内恢复能力。因此，只有带外（OOB）RTRec才能恢复系统。 | 带有执行策略设置为立即关机的英特尔Boot Guard。 |
恢复镜像可能是系统上不可改变ROM、系统上制造商提供的上一个已知的良好的镜像、或最终用户保存的镜像。如果恢复镜像是可变的，则恢复镜像更新必须遵循与正常镜像更新相同的流程，例如镜像保护、签名检查、版本检查等等（见表5-2）。
表 5-2 恢复镜像选择
| 机制 | 优点 | 缺点 |
|---|---|---|
| 不可改变的ROM | 无法破解不可改变ROM。 | 如果不可改变的ROM有漏洞，漏洞是永久的。 |
| 上一个已知良好的镜像 | 平台自动更新恢复镜像，并且平台保证恢复镜像中不存在已知安全漏洞。 | 很难去定义什么是“良好”。或许平台保存的镜像存在很多功能上的问题。 |
| 最终用户保存的镜像 | 最终用户有自由决定使用哪个镜像进行恢复。 | 需要与最终用户交流。最终用户可能选择有漏洞的镜像。 |
自动保存上一个已知良好镜像的解决方案是一个挑战，因为"良好"的定义无法精确界定。当固件成功传输到操作系统加载器时，我们能说新镜像是"良好"吗？或者当操作系统成功启动时？或者当操作系统设备驱动程序全部启动时？或者当操作系统中业务应用程序开始运行时？或者操作系统通过证书测试时？没有统一的答案，平台设计者需要做出抉择来平衡所需的操作系统功能，证明系统处于良好状态。
恢复镜像可能在系统ROM中，例如闪存设备；不可拆卸磁盘上，例如硬驱；或者可移除磁盘，例如USB密钥或CDROM/DVDROM；或通过传输从远程位置传递，例如串口或网络；甚至来自带外管理设备（见表5-3）。
表 5-3 恢复镜像位置
| 机制 | 优点 | 缺点 | 实例 |
|---|---|---|---|
| 闪存ROM | 恢复镜像一直存在。 | 成本较高。 | 在相同的闪存设备或不同的闪存设备上。 |
| 不可移除磁盘 | 不增加的成本。 | 恢复镜像本身需要受到保护，并且只允许经过授权的恢复镜像更新。 | 硬驱（硬盘驱动（HDD）、固态硬盘（SSD）、NVMe等等） —— 隐藏分区或系统分区。 |
| 可移除磁盘 | 恢复镜像无法被攻击，因为它在正常启动时没有连接到系统。 | 需要与用户交流。最终用户保证恢复镜像的正确性。 | CDROM/DvDROM，USB密钥。 |
| 远程传输 | 无需接触本地机器。 | 网络驱动栈必须在RTRec中。必须设置恢复服务器。 | 网络（以太网、Wi-Fi、蓝牙等等），串口。 |
| 带外传输 | 便于远程管理。 | 带外引擎需要访问闪存。 | 基板管理控制器（BMC），可管理引擎。 |
现在，让我们看一下镜像恢复的一些实例。
在正常启动过程中，芯片会将闪存芯片的两个64KB的顶部启动块映射到地址[0xE0000, 0xFFFFF)。当CPU从复位向量 —— 0xF000:0xFFF0 ——启动时，CPU可以直接在闪存上执行指令。由于典型的16位真实模式启动块代码会立即切换到32位保护模式以访问整个闪存区域（可能大于1MB），因此这些相同启动块也会映射到[0xFFFE0000，0xFFFFFFFF]。见图 5-1。
顶部交换（TS）是一种将固件集线器或SPI闪存（也称为启动块）的顶部区块与另一位置进行交换的功能（见图5-2）。这是为允许启动块安全更新而设计的。当它启用后，PCH将反转周期进入闪存顶部的两个块的地址。例如，如果块大小为64K，访问FFFF_0000h-FFF_FFFFh的MMIO地址将变为访问FFFE_0000h-FFFE_FFFFh闪存地址，反之亦然。
安全启动块更新可在以下方式中使用：
- 固件将顶部区块备份到顶部以下的区块（交换区块）。
- 固件启用顶层交换。这将反转循环进入低引脚计数（LPC）或串行外设接口 (SPI) 总线的适当地址位。该位存储在RTC中。
- 固件擦除顶层块并写入新的顶层块。
- 固件禁用顶端交换。
如果在步骤3中发生任何断电复位，系统将从步骤1中备份的启动块启动并执行恢复。见图5-3。
由于启动块B可以控制不同的代码流，BIOS可以实现不同的基于顶层交换的恢复工作方式。例如，RTD（如ACM或嵌入式控制器）可以在转移控制前检查启动程序块A。如果RTD发现有问题，RTD可以选择设置顶部交换并重置系统。在下一次启动时，RTD可以检查启动块B。如果这次检查通过，则启动块B拥有重置向量。它现在处于恢复模式。启动块B可以从闪存镜像中启动主块B1。主块B1可能包含外部存储驱动程序，并从那里加载主块B2。最后，主块将找出一种方法，将已知的良好镜像烧录到启动块A和主块A，清除顶部交换并重置系统。现在下次启动将再次变成正常启动。支持顶层交换恢复的闪存镜像布局见图5-4。
Boot BIOS Strap (BBS)是一种选择BIOS从何处启动的功能（见图 5-5）。它可以从LPC总线或SPI总线启动。平台制造商可以选择通过LPC总线或SPI总线连接闪存。前几代产品甚至可以从PCI总线启动BIOS。如果选择PCI总线，则4GB以下内存的顶部16MB（FF00_0000h至FFFF_FFFFh）将由PCI至PCI桥接器的主端接收并转发至PCI总线。这样，系统就可以从插入式PCI卡中恢复。例如，如果平台所有者发现整个BIOS区域损坏，他们可以设置一个跳线，然后插入一块卡上有已知良好的BIOS的PCI卡。跳线可引导BIOS访问PCI总线。一旦系统启动，平台所有者可以更新新的镜像到连接到LPC或SPI总线的BIOS中。这种从PCI启动的功能在较新的芯片组中并不存在。
coreboot固件有两个分区：只读分区（包括启动块、verstage和恢复镜像）和读写分区（包括romstage + ramstage + payload）。只读分区是RTD和RTRec。启动块设置临时RAM后，verstage会尝试验证并加载读/写固件A。如果它失败了，固件会尝试验证和加载固件B。如果它再次失败，它会尝试验证和加载恢复镜像。恢复镜像被包含在只读部分中，它有完整的用于恢复模式的romstage、ramstage和payload副本。coreboot恢复闪存镜像布局见图5-6。
在EDK II签名的恢复解决方案中，预先可扩展固件接口（Pre-EFI）初始化(PEI)固件卷作为RTRec工作。PEI组件检查驱动执行环境（DXE）主固件卷（FV）并且决定启动模式。PEI FV可以在恢复启动模式下加载DXE主FV的恢复版本。恢复DXE主FV可以被外部存储加载，例如HDD，USB密钥，CDROM等等。EDK II签名的恢复流程见图5-7。
步骤0：在系统启动期间，平台PEI检测启动模式并且在需要恢复时设置BOOT_IN_RECOVERY_MODE。它还会安装EFI_PEI_BOOT_IN_RECOVERY_MODE_PPI以便在恢复模式下调度依赖恢复的模块。
步骤1：在PEI阶段的最后步骤，DxeIpl尝试通过EFI_PEI_RECOVERY_MODULE_PPI加载恢复镜像。如果系统启动模式处于BOOT_IN_RECOVERY_MODE，加载恢复胶囊镜像。
步骤2：RecoveryModule是EFI_PEI_RECOVERY_MODULE_PPI的生产者。它消耗EFI_PEI_DEVICE_RECOVERY_MODULE_PPI。
步骤3：PEI文件系统驱动是EFI_PEI_DEVICE_RECOVERY_MODULE_PPI的生产者。在EDK II中，这些模块包括CDROM/DVDROM（CdExpressPei）和FAT文件系统（FatPei）。它们消耗EFI_PEI_RECOVERY_BLOCK_IO2_PPI。
步骤4：PEI块IO存储驱动是EFI_PEI_RECOVERY_BLOCK_IO2_PPI的生产者。在EDK II中，这些模块是USB（UsbBotPei），HDD（IdeBusPei），eMMC（EmmcBlockIoPei），和UFS。这些PEIM是从存储设备加载恢复胶囊镜像到内存的模块。
步骤5：一旦恢复模块检索到恢复镜像，它会解析和验证恢复镜像，来检查完整性，并为DXE阶段提取固件卷。
步骤6：最后，恢复模块为DXE安装提取的固件卷（FV）。它构建EFI_HOB_FIRMWARE_VOLUME，并且安装EFI_PEI_FIRMWARE_VOLUME_INFO2_PPI。
然后DxeIpl可以找到DXE内核和DXE主固件卷，并且将控制转移给DXE。之后，DXE阶段闪存更新驱动更新闪存区域中的DXE固件卷来完成恢复。
coreboot恢复和EDK II签名恢复解决方案假设RTD/RTRec和其他可变镜像位于单个设备中。这简化了电路板设计并降低了成本。但是，在某些情况下，并不能保证启动是真的只读的。它仍然是可以更新的。因此，之前的解决方案行不通。
惠普Sure Start技术包括一个独立的芯片作为保护、检测和恢复的信任根。该芯片具有自愈能力，提供了从整个BIOS损坏中自动恢复的能力，也提供固件保护，能防止永久拒绝服务（PDoS）攻击。上电后，惠普Sure Start芯片检查启动块。如果启动块损坏，惠普Sure Start芯片会从已知的良好镜像中恢复它。然后，启动块检查系统BIOS镜像的其余部分。流程见图5-8。
Cerberus安全架构是由开放计算项目（OCP）定义的用于保护、检测和恢复的服务器平台解决方案。其范围从主机固件扩展到基板管理控制器（BMC）固件。如第4章中讨论的，Cerberus芯片连接到BIOS闪存芯片和BMC闪存芯片。每个闪存芯片包括三个区域：活动镜像、恢复镜像和暂存镜像（见图 5-9）。如果活动固件无法启动，Cerberus芯片可以触发恢复程序，从恢复镜像中加载镜像覆盖损坏的活动固件。恢复也可通过 "恢复镜像"命令触发。见表5-4。当然，Cerberus芯片需要保护恢复镜像免受活动镜像的篡改。
除了BIOS和BMC固件外，一旦Cerberus发现设备组件固件已损坏，Cerberus的信任根（RoT）命令可以用于支持设备固件更新和恢复镜像更新。
表 5-4 Cerberus信任根命令列表
| 注册名 | 信任根 | 描述 |
|---|---|---|
| 恢复固件（Recovery Firmware） | 平台活动（PA）信任根/组件活动（CA）信任根 | 使用备份恢复固件索引。 |
| 准备恢复固件（Prepare Recovery Firmware） | 平台活动（PA）信任根/组件活动（CA）信任根 | 为恢复镜像准备存储。 |
| 更新恢复固件（Update Recovery Firmware） | 平台活动（PA）信任根 | 更新恢复镜像。 |
| 激活恢复固件（Activate recovery Firmware） | 平台活动（PA）信任根 | 激活接收的恢复镜像。 |
ARM可信固件A中的恢复实现是平台特定的。如果需要恢复启动，平台可以选择启动保存在闪存镜像其他位置的有效的闪存镜像。此操作可与固件更新流程相结合，使用恢复镜像覆盖活动镜像区域。
ARM可信固件M使用交换机制进行更新，这我们在第3章中已经讨论过。这种交换机制也用于恢复。如果新镜像启动失败，系统会重新启动，恢复到旧的稳定镜像，并设置回滚标志。见图5-10。
现在，让我们看一下一些攻击镜像恢复的实例和缓解这些攻击的策略。
由于恢复镜像是另一个BIOS镜像，因此对工作镜像的所有硬件攻击也可应用于恢复镜像。如果恢复镜像位于闪存中，则闪存区域必须被保护。如果恢复镜像位于不可移动磁盘的系统分区上，则更具挑战性。该分区必须是受保护分区或隐藏分区。
更新恢复镜像是另一个攻击面。所有应用于活动镜像更新的规则也必须应用于恢复镜像更新，如认证检查、版本检查、不可绕过性等。
恢复镜像不得存在任何已知的安全漏洞。恢复镜像可能与活动镜像不同，不具备与活动镜像相同的完整功能，因为恢复镜像的主要功能是将系统恢复到可以更新到新活动镜像的状态。
当活动镜像更新时，平台所有者必须确定漏洞是否也存在于恢复镜像中。如果恢复镜像存在类似的安全问题，恢复镜像也必须与活动镜像一起更新。否则，攻击可能会触发恢复程序并激活易受攻击的环境。
硬件配置，如顶部交换 (TS) 或Boot BIOS Strap(BBS)，可能有助于恢复过程。但是，不适当地使用这一高级设置可能会成为攻击面。如果这些寄存器没有锁定，攻击者可以切换TS或BBS，让系统从恶意软件控制的其他源启动。在系统退出平台制造商认证阶段之前，所有与安全相关的硬件设置必须被锁定。
除了可执行代码外，配置数据也可能被篡改或损坏。如果检测到这种情况，配置数据也需要进行恢复。
配置可能是制造商的默认配置、制造商/供应商保存的最后已知良好的配置，或最终用户保存的配置。如果恢复配置是可变的，则恢复配置更新必须遵循与正常配置更新相同的流程。见表 5-5。
表 5-5 恢复配置选择
| 机制 | 优点 | 缺点 |
|---|---|---|
| 制造商的默认配置 | 没有方法能破坏制造商的默认值，默认配置应该存储在不可更改的区域或恢复镜像区域。 | 如果制造商默认的值不是安全的配置，它必须跟整个恢复镜像一起更新。 |
| 最后已知的良好配置 | 平台自动保留最后的配置数据。 | 与最后已知的良好的镜像类似，它很难去定义什么是良好。 |
| 最终用户保存的配置 | 最终用户自由决定恢复哪种配置。 | 最终用户可能错误地保存了不能启动的配置。 |
通常，制造商会提供默认配置值。如果配置不是最终用户可更改的，例如重要生产数据 (VPD)，则应将其作为恢复映像的一部分，而不是恢复配置。如果配置是最终用户可更改的，例如设置变量策略数据或安全启动配置数据，则可能有两套默认值，一套是平台制造商的默认值，另一套是最终用户在设置页面中保存的配置。最终用户可以选择在设置页面加载最终用户保存的配置，或者加载平台制造商的默认值。图5-11显示了该流程。
现在，让我们看一下一些攻击配置恢复的实例和缓解这些攻击的策略。
对恢复配置的大多数攻击与对恢复镜像的攻击类似。配置数据本身应受到保护。
如果默认配置不够安全，并且当前配置又更新了默认配置，攻击者可能会选择触发恢复来加载默认的不安全配置。例如，默认映像可能包含一个安全启动禁止数据库——dbx1。如果平台追加新的安全启动禁止数据库到dbx1中，然后当前禁止数据库——dbx2——包含的条目多于默认禁止数据库dbx1。为了让有漏洞的签名的镜像运行，攻击者需要想办法从安全启动禁止数据库中删除新条目。启用恢复功能后，他们可以触发平台恢复来加载制造商的默认配置——dbx1。图5-12展示了这一概念。
为了减少此类攻击，如果平台需要将任何配置更新到安全状态，平台必须更新当前配置、保存的配置和默认配置。
在正常运行环境下，我们希望检测信任根（RTD）能够检测到固件损坏的情形，并随后触发或启动恢复过程。然而，在某些特殊情况下，固件可能会因未被RTD检测到配置数据攻击而挂起。在后一种情况下，我们仍然需要一种自动恢复机制。看门狗是一种硬件设备，能在这种情况下协助恢复过程，以抵御拒绝服务攻击。典型的看门狗设计见图5-13。
在弹性解决方案中，看门狗应该是弹性引擎的一部分，例如平台信任根。看门狗应在平台信任根期间启动，不应该被系统中任何暴露的漏洞停止或篡改。在正常情况下，系统应定期重新武装看门狗（喂狗），以防止其超时。如果系统运行到损坏状态或挂起，则系统将无法重新武装看门狗（喂狗）。当计时器计时结束后，看门狗将产生复位信号以启动恢复操作。这相当于固件的 "死人开关"。
目前，看门狗已广泛应用于计算机平台，例如X86系统或ARM系统。然而，并非所有的看门狗都能用于弹性用途，因为看门狗有一个特殊的要求，即对于易受攻击的弹性目标，看门狗应具有防篡改抵御能力。联网的弹性看门狗应该是可锁定的看门狗或经过认证的看门狗。只有弹性信任根（RTRes）才能控制它。
在本章中，我们讨论了固件恢复能力的第三部分 ——— 恢复。我们讨论了镜像恢复和配置恢复。下一章，我们将讨论操作系统/加载器的弹性能力。
会议、期刊与论文
[P-1] Jiewen Yao, Vincent Zimmer, “A Tour Beyond BIOS- Capsule Update and Recovery in EDK II,” Intel whitepaper, 2016, available at https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers
[P-2] Jim Mann, “System Firmware – The Emerging Malware Battlefront,” NIST Computer Security Resource Center, 2015, available at https://csrc.nist.gov/CSRC/media/Presentations/System-Firmware-The-Emerging-Malware-Battlefront/images-media/day1_trusted-computing_100-150.pdf
[P-3] Andrew Thoelke, “ARM Trusted Firmware for ARMv8-A,” Linaro Connect US 2013, available at https://www.slideshare.net/linaroorg/arm-trusted-firmareforarmv8alcu13
[P-4] Andrew Thoelke, “Adopting ARM Trusted Firmware,” Linaro Connect Asia 2014, available at https://www.slideshare.net/linaroorg/lca14-102-adoptingarmtrustedfirmware
[P-5] Dan Handley, “ARM Trusted Firmware – from Enterprise to Embedded,” Linaro Connect Las Vegas 2016, available at https://static.linaro.org/connect/las16/Presentations/Thursday/LAS16-402%20-%20ARM-TF%20From%20Embedded%20To%20Enterprise%20v1.0%20%281%29.pdf 【1】
[P-6] Dan Handley, Charles Garcia-Tobin, “Trusted Firmware Deep Dive,” available at http://www.linaro.org/app/resources/Connect%20Events/Trusted_Firmware_Deep_Dive_v1.0_.pdf
[P-7] Sun Bing, “BIOS Boot Hijacking and VMware Vulnerabilities Digging,” in Power Of Community 2007, available at http://powerofcommunity.net/poc2007/sunbing.pdf
[P-8] Alexander Ermolov, “Safeguarding Rootkits: Intel Boot Guard,” in Zeronights 2016, available at https://github.com/flothrone/bootguard/blob/master/Intel%20BootGuard%20final.pdf
[P-9] Alexander Ermolov, “Safeguarding Rootkits: Intel Boot Guard, (part2),” in DC 2017, available at https://github.com/flothrone/bootguard/blob/master/Intel%20BG%20part2.pdf
[P-10] Ronald Aigner, Paul England, Andrey Marochko, Dennis Mattoon, Rob Spiger, Stefan Thom, “Cyber-Resilient Platform Requirements,” Microsoft Whitepaper, 2017, available at https://www.microsoft.com/en-us/research/publication/cyber-resilient-platform-requirements/
[P-11] Frank Stajano, Ross Anderson, “The Grenade Timer: Fortifying the Watchdog Timer Against Malicious Mobile Code,” in Proceedings of 7th International Workshop on Mobile Multimedia Communications, 2000 available at https://www.cl.cam.ac.uk/~rja14/Papers/grenade.pdf
规范和指南
[S-1] NIST SP800-193, “Platform Firmware Resiliency Guidelines,” 2018, available at https://csrc.nist.gov/publications/sp800
[S-2] OCP, “Project Cerberus Architecture Overview Specification,” 2018, available at https://github.com/opencomputeproject/Project_Olympus/blob/master/Project_Cerberus
[S-3] OCP, “Project Cerberus Firmware Challenge Specification,” 2019, available at https://github.com/opencomputeproject/Project_Olympus/blob/master/Project_Cerberus
[S-4] OCP, “Project Cerberus Firmware Update Specification,” 2019, available at https://github.com/opencomputeproject/Project_Olympus/blob/master/Project_Cerberus
[S-5] OCP, “Project Cerberus Processor Cryptography Specification,” 2018, available at https://github.com/opencomputeproject/Project_Olympus/blob/master/Project_Cerberus
[S-6] Intel, “Intel® 9 Series Chipset Platform Controller Hub (PCH) Datasheet,” 2015, available at https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/9-series-chipset-pch-datasheet.pdf 【1】
网页
[W-1] Google, “Firmware Boot and Recovery,” https://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery/?tmpl=%2Fsystem%2Fapp%2Ftemplates%2Fprint%2F&showPrintDialog=1
[W-2] Checkm8, https://github.com/axi0mX/ipwndfu
【1】译者注，原地址无法访问或已变更，译者重新贴了可访问的地址