无缝危机预防和恢复

2024-02-28

如果固件更新失败，结果可能是毁灭性的。最好的情况是更新失败，但系统可以复原并恢复，而不会让最终用户察觉出来。最糟糕的是，失败的固件更新可能导致系统不可用，要求最终用户将其系统退回给零售商或制造商进行修复。后一种情况是我们所谓的危机。

危机可能由于固件更新失败或由于与 Windows 或其他系统方面不兼容的固件导致。本部分讨论旨在防止和恢复因固件更新失败而导致的危机的功能。我们期望固件创作者提供的固件更新测试范围可防止因不兼容固件导致的大多数危机。

为了为最终用户提供出色的体验，必须满足固件驱动程序包更新机制的以下危机预防和恢复要求。这些要求不排除额外的危机预防或恢复解决方案。

预安装条件

当系统固件执行实际更新时，必须执行一系列预安装检查。系统固件必须执行此检查，以确保有足够的能力来完成更新。此外，建议在应用更新之前为每个更新执行检查（如果有多个固件更新）。下表列出了要检查和验证的项。必须在适用的情况下执行所有检查。测试没有具体执行顺序。

检查类型	说明
强力	系统必须至少具有 25% 的电池电量。不需要有线电源（通过 USB 电缆和/或 AC 电源供电）。在测试/实验室环境中，只要提供有线电源，在没有电池的情况下仍能进行固件更新。但是，必须区分电量用尽/电池不充电和无电池这三种不同的情况。
安全性	验证更新封装程序有效负载是否已正确签名。验证有效负载中的任何基于 PE 的 EFI 文件是否已使用适当的 EFI 证书正确签名
完整性	对固件更新有效负载执行完整性检查。
版本	验证所应用的固件是否未将当前已安装的固件降级到 LowestSupportedFirmwareVersion 值之外。
存储	根据系统的硬件，将根据需要执行以下检查有足够的空间备份将要替换的当前固件设备中有足够的空间容纳新固件。

任何失败都必须生成相应的上次尝试状态错误代码。有关详细信息，请参阅 ESRT 表定义和固件更新状态中的“上次尝试状态”错误代码信息。

如果应用了多个更新，并且某些更新通过预安装检查，而其他更新未通过，则平台固件可以继续为通过预安装检查的资源更新固件。但是，任何预安装检查失败的资源都不得更新。

安装后条件

安装固件（设备或系统）后，必须对其进行检查，以验证新更新的固件映像是否符合预期。这是为了尽量减少在实际更新过程中产生任何损坏风险（例如闪存 ROM 中的粘滞位、更新期间总线上的干扰等）。

更新过程必须验证更新的固件是否通过完整性检查。如果失败，则必须通过回滚到固件的最后一个已知有效版本来恢复。

任何失败都必须生成相应的上次尝试状态错误代码。有关详细信息，请参阅 ESRT 表定义和固件更新状态中的“上次尝试状态”错误代码信息。

从安装和启动失败中恢复

为了防止系统达到不可启动状态，在固件更新无法安装或系统无法成功启动的情况下，固件更新机制必须满足以下要求。

在以下部分中，术语“已提交”用于描述固件。固件“提交”后，固件将被视为完全安装，并且不会由于启动失败等原因自动回滚。“未提交”固件描述部分更新的固件，在固件更新无法完成或更新固件检测到故障的情况下，可能会回滚到以前的版本（例如，更新中的 CRC 检查无效）。是否提交固件是固件应在内部跟踪的内容，并且不会作为 ESRT 的一部分捕获。

固件更新失败

如果单个系统或设备固件无法安装或安装不正确（例如，由于某种损坏或安装更新时断电），则更新可能总共重试三 (3) 次尝试，包括第一次尝试。如果固件将执行其他重试尝试，则系统不得在任何尝试之间启动到 Windows。如果所有尝试都失败，更新固件必须放弃更新。如果部分应用了更新，固件必须回滚到以前的版本。固件必须回滚到以前的版本，而无需任何用户交互。更新失败不会影响其他挂起的更新；应尝试挂起的固件更新。

处理完所有更新后，UEFI 将恢复启动 Windows。 UEFI 固件必须验证是否已成功安装任何未提交的固件更新，以解决因断电导致的问题（UEFI 绝不应尝试使用部分写入的固件启动 Windows）。

安装失败的可能原因包括但不限于以下问题：