高级配置与电源接口（ACPI）规范定义了一组电源状态（见图9-1）。这些电源状态包括以下内容：
• G0 (S0) —— 工作状态：运行中的固件或操作系统处于S0状态。
• G1 —— 睡眠状态
• S1 —— 待机：除了CPU缓存，所有的系统上下文都保留。所有CPU都停止运行。其他设备仍处于工作状态。当系统暂停时，系统从下一条指令开始恢复。
• S2 —— 与S1类似：目前未使用。
• S3 —— 暂停至内存：系统上下文保存到平台内存。设备停止工作。只刷新DRAM来保留内容。系统从固件复位向量恢复，并跳转到操作系统唤醒向量。之后，操作系统从内存中恢复上下文。当用户选择“睡眠”选项，系统进入S3状态。这也可以由某些操作启动，例如关闭笔记本的盖子。
• S4 —— 暂停至磁盘：系统上下文保存到磁盘中。所有设备停止工作。系统从固件复位向量恢复，并以正常启动方式启动操作系统。之后 操作系统从磁盘恢复上下文。当用户选择“休眠”选项时，系统会进入S4状态。
• 有一个名为S4 BIOS的选项，这意味着BIOS保存内存的副本到磁盘，然后启动硬件S4。当系统唤醒时，固件会从磁盘恢复内存，并通过将控制权转移到操作系统唤醒向量来唤醒操作系统。如今，大多数平台都不采用这种方式，因为这是早期高级电源管理（APM）的一种独立于操作系统的技术。
• G2 (S5) —— 软关闭状态：当用户选择“关闭”选项时，系统进入S5状态。
• G3 —— 电源关闭状态：当用户选择关闭机器电源时，机器处于G3状态。
系统固件参与Sx的暂停和恢复。S1恢复由操作系统内部直接处理。S4恢复和S5恢复与正常启动类似。S3恢复是一种特殊的启动路径，与正常启动路径有很大不同。这些差异带来了独特的安全挑战，我们将在本章重点讨论。
S3意味着"暂停到内存"。操作系统的上下文在内存中，某些固件S3的上下文也在内存中。如果恶意代码可以访问S3恢复中使用的操作系统或固件S3的上下文，则可能会影响系统的机密性、完整性和可用性。
S3恢复的资产如表9-1所示。这些资产包括但不限于闪存内容、内存内容、硅片寄存器设置、TPM设备状态和存储设备配置。这些资产可能需要完整性、可用性或保密性属性。
表 9-1 S3恢复资产
| 资产 | 完整性 | 可用性 | 机密性 |
|---|---|---|---|
| 闪存 | 固件代码 固件配置 | 固件代码 固件配置 | 无 |
| 内存 | SMRAM | 操作系统唤醒向量 | SMRAM |
| 硅片 | 锁存寄存器 | 硅片寄存器 内存配置数据 | 无 |
| TPM状态 | TPM2平台层次 | TPM设备状态 | 无 |
| 存储磁盘 | TCG存储块SID HDD冻结 | 无 | 磁盘密码 |
S3恢复攻击者可以使用软件攻击（例如编写代码修改系统上下文）或硬件攻击（例如使用闪存编程器访问闪存区域、使用设备执行DMA攻击并触发断电）。攻击面可以是闪存访问、内存访问、硅寄存器或TPM命令。有关S3攻击面，见表9-2。
表 9-2 S3攻击面
| 攻击面 | 软件攻击 | 硬件攻击 |
|---|---|---|
| 闪存访问 | 读/写配置（变量） | 固件代码 固件配置 |
| 内存访问 | ACPI非易失性存储（NVS） ACPI保留内存 | ACPI非易失性存储（NVS） ACPI保留内存 |
| 硅寄存器 | 读/写硅寄存器（I/O，MMIO，PCI） | 无 |
| TPM命令 | TPM设备状态（关闭命令） | 无 |
攻击可能在S3暂停期间（例如修改操作系统中的ACPI内存、发送恶意TPM命令或不发送特定TPM命令）、处于S3状态（例如使用闪存编程器更新固件代码）或S3恢复期间（例如附加恶意的PCI设备进行DMA访问）发生。
为了缓解这些攻击，S3恢复实现应采取防御措施。见表9-3。有些S3缓解措施与正常启动中使用的类似，例如在S3中验证闪存映像，以及设置IOMMU或其他DMA保护以抵御S3中的DMA攻击。有些S3缓解措施针对特定设备，例如保留TPM设备状态。这些技术已在前几章中讨论过。S3缓解措施的一个主要类别是安全存储，用于保存S3恢复时使用的设置，包括：1）内存中的CPU配置数据，例如CPU状态、SMM环境——页表和SMBASE；2）硅寄存器配置数据，例如芯片组和PCI Express设备的寄存器设置；3）设备配置数据，例如TCG存储BlockSID状态和硬盘解锁密码。我们将这类安全存储称为锁箱（LockBox）。
表 9-3 S3攻击缓解措施 | 资产 | 预防 | 检测 | 恢复 | | :--- | :--- | :--- | ：--- | | 闪存 | 闪存设备锁 变量锁/认证 | S3中的闪存镜像验证 变量检查/RPMC | 切换到正常启动去恢复 | | 内存 | S3中的IOMMU 保存数据到锁箱 | 电源损失检测 | 切换到正常启动 | | 硅 | 保存配置数据到锁箱 代码中的寄存器锁 | 无 | 无 | | TPM状态 | 发送TPM2_HierarchyChangeAuth() | 检查TPM2_Startup() | 覆盖PCR | | 存储磁盘 | 保存配置数据到锁箱 | 无 | 无 |
锁箱是用于S3恢复期间的安全存储抽象。在正常启动或S3暂停阶段，授权的固件组件保存当前的配置到锁箱中。在S3恢复阶段，授权固件组件会从锁箱中检索配置、配置系统并启动到操作系统唤醒向量。见图 9-2。
锁箱可以提供机密性、完整性和可用性支持。出于机密性考虑，只有被授权的实体才能读取锁箱内容。对于完整性，只有被授权的实体才能往锁箱写入内容。对于可用性考虑，锁箱应始终存在。要防止硬件攻击是很困难的，因为硬件攻击可能包括只断电破坏内存内容或使用闪存编程器擦除闪存内容。
平台有很多实现锁箱的选择，包括但不限于可信执行环境（TEE），例如系统管理模式（SMM）、UEFI变量（使用变量锁实现完整性和加密变量实现保密性）、TPM非易失性存储，或基于协处理器的机制，例如英特尔聚合安全和管理引擎（CSME）、AMD平台安全处理器（PSP）、服务器基板管理控制器（BMC）等。锁箱实现选择的总结见表9-4。
表 9-4 S3锁箱实现
| 机制 | 完整性 | 可用性 | 机密性 | 注释 |
|---|---|---|---|---|
| TEE(SMM) | 是 | 对于软件攻击，是；对于硬件攻击，否 | 是 | 在内存初始化之前可能不支持 |
| 变量 | 需要变量锁或认证 | 对于软件攻击，是；对于硬件攻击，否 | 需要加密变量 | 闪存大小限制 |
| TPM NV | 需要认证会话或锁 | 是 | 需要认证会话 | TPM设备依赖，NV大小限制 |
| 协处理器 | 是 | 是 | 是 | 协处理设备依赖 |
现在，让我们看一下锁箱实现的一些真实的使用案例。
S3恢复过程的目标是将平台恢复到启动前的配置。UEFI PI架构仍需分阶段恢复平台，就像在正常启动路径中一样。图9-3显示了S3恢复启动路径中的各个阶段。
在正常启动中，PEI阶段负责初始化足够的平台资源，来执行DXE阶段，而DXE阶段是由不同的DXE驱动程序执行大部分平台配置的阶段。
在S3恢复阶段，引入DXE并使DXE驱动程序启动路径感知是非常危险的，原因如下：
• DXE 阶段承载了大量服务，因此规模相当大。
• 从闪存加载 DXE 非常耗时。
相反，PI架构提供的启动脚本可让S3恢复启动路径完全规避DXE阶段，这有助于最大限度地提高S3恢复性能。启动脚本是一组条目，例如IO_WRITE(端口、数据)、MMIO_WRITE(地址、数据)和PCI_WRITE(段、总线、设备、功能、寄存器、数据)。这是一种配置硅寄存器的轻量级方法。在正常启动过程中，例如从S5启动时，DXE驱动程序会在启动脚本中记录平台配置，并保存在NVS中。在S3恢复启动路径期间，启动脚本引擎会执行脚本，从而恢复配置。
ACPI规范只要求BIOS恢复芯片组和处理器配置。芯片组配置可视为DXE驱动程序在PI架构启动脚本中记录的一系列内存、I/O和PCI配置操作。在S3恢复期间，启动脚本引擎会执行启动脚本以恢复芯片组设置。
正常启动时，启动脚本的保存方式如下：
- 在DXE阶段，芯片/平台驱动程序将寄存器配置保存到启动脚本中。这就是启动时的S3脚本。
- 在SMM阶段，硅/平台驱动程序可以继续将寄存器配置保存到表中，即使在操作系统运行期间也是如此。典型的实现是，当操作系统触发进入S3时，系统进入SMM。一个特殊的SMI处理程序会收集运行时硅寄存器设置（如PCI配置），并将信息保存到启动脚本中。这就是运行时S3脚本。
在S3恢复期间，启动脚本的执行过程如下：
- 在PEI中，启动脚本执行引擎会获取启动脚本并重播保存的启动脚本，以恢复系统配置。启动时S3脚本和运行时S3脚本都会被执行。
实际上，启动脚本庞大，因为它包含来自芯片组和PCI Express设备的所有硅设置。将启动脚本保存到UEFI变量或TPM NV并不总是可行的，因为TPM或闪存的可使用的存储空间有限。使用SMM环境是一种架构解决方案，它被EDK II BIOS使用来实现基于SMM的锁箱，并作为默认的启动脚本。
除了启动脚本的使用，我们也需要将硬盘密码保存到锁箱中，来自动解锁磁盘。因此，基于SMM的锁箱需要同时考虑完整性和保密性。
一种基于SMM的锁箱的完整性规则如下：
• 在SmmReadyToLock事件发生之前，任何驱动程序都可以使用DXE锁箱或SMM锁箱接口将信息保存到锁箱中。还支持从锁箱中恢复信息，尽管很少使用。
• 在SmmReadyToLock事件发生后，DXE代码不再受信任。通过DXE代码将信息保存到锁箱的尝试将被拒绝。SMM代码已经可用，并可以使用SMM锁箱保存运行时启动脚本。
• 在S3恢复期间，无需将信息保存到锁箱中。因此，PEI锁箱不提供将信息保存到锁箱的功能。
根据这些规则，只有平台制造商的代码才能将信息保存到锁箱中。第三方代码不能将信息保存到锁箱中。
一种基于SMM的锁箱的机密性规则如下：
• 默认情况下，锁箱不提供任何机密性支持。DXE/PEI/SMM实例可以恢复锁箱内容。
• 如果锁箱需要机密性，创建者需要设置为锁箱设置LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY属性。
• 如果LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY属性设置，此锁箱只能被恢复
• 在SmmReadyToLock事件之前（或）
• 在系统进入S3（S3Entry事件）和S3恢复结束（EndOfS3恢复事件）之间
根据此规则，机密只能在平台退出平台制造商认证阶段或固件恢复阶段之前恢复。第三方代码不能从锁箱恢复机密。
在EDK II，锁箱提供了如下的服务：
1）SaveLockBox()：发送数据到锁箱。锁箱可以由全球唯一标识符（GUID）唯一地识别。
2）UpdateLockBox()：更新锁箱中地数据。
3）SetLockBoxAttributes()：设置锁箱属性。
a) LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE意味着这个锁箱能使用RestoreAllLockBoxInPlace()恢复到它原来的地址。
b) LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY意味着这个锁箱能在S3恢复路径中恢复。这用来提供机密性支持。
4）RestoreLockBox()：从锁箱中获取数据给调用者提供的缓冲区地址或原始的缓冲区地址。
5）RestoreAllLockBoxInPlace()：从所有的拥有LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE属性的锁箱中恢复数据。
并非所有的锁箱服务在所有的BIOS阶段都可用。全部概要显示在图9-4。
.jpg)
.jpg)
S代表锁箱保存。 R代表锁箱恢复。 RS代表锁箱恢复机密。
基于SMM的锁箱实现保存所有锁箱内容到SMRAM内部。见图9-5。
LockBoxQueue是SmmLockBox链接列表的头部。每个锁箱都使用以下数据结构：
- GUID：标识锁箱。
- Buffer：指向原始数据缓冲区的指针。当调用者要求恢复到原始缓冲区地址时，就会用到这个指针。
- Length： 锁箱中数据的大小。
- Attributer： 锁箱的属性。
- SmramBuffer： SMRAM 中的数据缓冲区。
LockBoxQueue的地址也为由SMST保存为指向的SMM配置表。原因是，如果SMI还未启用，PEI阶段的锁箱库就可以搜索SMRAM区域来获取LockBoxQueue，并获取所有锁箱内容。这使得在S3恢复阶段中在在SMM备就绪之前，PEI锁箱服务就已可用。
DXE阶段的锁箱库调用SMM_COMMUNICATION协议与SMM锁箱服务提供者通信。SmmLockBox驱动程序提供锁箱软件SMI处理程序来处理来自DXE实例的请求。
让我们以启动脚本为例（见图9-6）：当SMM版本的启动脚本库请求锁箱服务时，代码会调用LockBoxSmmLib。SMM实例分配SMRAM、保存数据并立即返回。当DXE版本的启动脚本库请求锁箱服务时，代码会调用SMM_COMMUNICATE.Communicate()。然后软件SMI被触发。SmmCore调度到由SmmLockBox驱动程序注册的处理程序。锁箱SMM处理程序调用SMM锁箱实例分配SMRAM并保存数据，然后处理程序从SMM返回。
在SmmReadyToLock事件之前，DXE锁箱库支持五种锁箱服务。在SmmReadyToLock事件发出信号后，SaveLockBox()、UpdateLockBox()和SetLockBoxAttribute()将关闭，并出于安全原因拒绝进一步调用。RestoreLockBox()只能还原没有LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY属性的锁箱。否则，调用也会被拒绝。
SMM锁箱库还支持五种锁箱服务。它还会记录当前的执行阶段。SmmReadyToLock事件后，固件会退出平台制造商授权状态。在SmmReadyToLock后，来自DXE环境的锁箱保存请求将被拒绝。在系统进入S3之前，平台会通过EFI_SMM_SX_DISPATCH2协议发出S3Entry事件信号。然后系统进入S3状态。系统唤醒后，PEI S3恢复驱动程序恢复环境。在固件调用操作系统唤醒向量之前，它会发出EndOfS3Resume事件信号。SMM锁箱只允许在S3Entry事件和EndOfS3Resume事件之间恢复锁箱机密。
PEI锁箱库有两种与SMRAM中的锁箱通信的方式：
1）使用SMM_COMMUNICATION PPI与SmmLockBox服务提供者通信，与DXE锁箱库的行为类似（见图9-7）
2）如果在SMM准备就绪之前使用PEI锁箱库，SMM_COMMUNICATION PPI将返回EFI_NOT_STARTED。在这种情况下，PEI锁箱库可以直接搜索SMRAM区域来查找锁箱内容。锁箱内部数据结构如图9-5所示。PEI锁箱库可以查找ACPI_VARIABLE_HOB来获得SMM_S3_RESUME_STATE位置，然后检索SMM系统表（SMST）指针。LockBoxQueue 的地址将保存为SMM系统表（SMST）中的SmmConfigurationTable表项。当PEI为32位，而SMM/DXE为64位，则必须注意 —— 即使在32位PEI执行环境中，也必须将SMST中定义的所有 UINTN/VOID * 解析为UINT64。
PEI锁箱库在S3阶段只支持两种锁箱服务 —— RestoreLockBox()和RestoreAllLockBoxInPlace()。
一旦我们有了锁箱，启动脚本的实现就应该使用锁来保护硅配置数据和启动脚本执行引擎本身。以下内容必须保存到锁箱中：
- 启动脚本执行引擎
启动脚本引擎在S3恢复阶段执行S3启动脚本。
启动脚本引擎可能在TEE（例如SMM）中。如果是这样，则无需将其保存到锁箱中。由于SMM是一个高权限环境，平台可能不希望赋予启动脚本引擎这种权限。
因此，目前的实现是让启动脚本在正常执行环境下执行。在正常启动过程中，启动脚本引擎被加载到预留内存中。在S3恢复期间，启动脚本引擎从预留内存中执行。
预留内存不是安全之地，因为操作系统可能会修改其内容。因此，启动脚本引擎应在正常启动时将启动脚本本身保存到锁箱中，并在S3恢复时将其从锁箱中恢复到预留内存中。引导脚本引擎的锁箱需要使用LOCK_BOX_ATTRIBUTE_ RESTORE_IN_PLACE。因此，当S3恢复模块调用RestoreAllLockBoxInPlace()时，内容可以自动恢复。
- 启动时S3脚本和运行时S3脚本
从概念上讲，一个平台可以有两个启动脚本 —— 启动时S3脚本和运行时S3脚本。启动时S3脚本包括BIOS启动时记录的硅设置。这些信息必须在EndOfDxe事件发生前收集。运行时S3脚本在操作系统触发S3挂起时提供额外的芯片配置。一个特殊的SMI处理程序会捕获S3挂起动作，并将运行时芯片设置作为附加数据保存到运行时S3脚本中。
启动脚本驱动程序可选择将两个表分开或合并为一个表。启动时S3脚本和运行时S3脚本都在ACPI非易失性存储（NVS）内存中，并应保存到锁箱中。
S3脚本的锁箱也应具有LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE属性。这样，它就能在S3恢复阶段自动恢复。然后，启动脚本引擎只需执行在ACPI NVS内存中的启动脚本内容。
- S3脚本元数据
启动脚本实现可以分配额外内存来记录启动时S3脚本和运行时S3脚本的元数据，包括表地址、表长度、最后一个启动脚本表项等。元数据位于ACPI NVS内存中，也应保存到锁箱中。图9-8显示了EDK II中的S3脚本和元数据。
- 派遣操作码（DISPATCH OPCODE）特殊处理
启动脚本定义了一组用于访问寄存器的操作码，如IO_WRITE、IO_READ_WRITE、IO_POLL、MEM_WRITE、MEM_READ_WRITE、MEM_POLL、PCI_CONFIG_WRITE、PCI_CONFIG_READ_WRITE、PCI_CONFIG_POLL等。启动脚本还支持两个特殊的操作码：DISPATCH_OPCODE和DISPATCH_2_OPCODE。这两个DISPATCH OPCODE支持在启动脚本执行期间运行任意代码的能力。这些代码对象包括一个EntryPoint和一个Context参数。EntryPoint只是指向将被运行代码的指针，而Context是要传递到EntryPoint的参数。见图 9-9。
与DISPATCH_2_OPCODE相关的EntryPoint是启动脚本中的一个8字节地址。在锁箱中保存8字节EntryPoint无法保护EntryPoint函数使用的所有代码。因此，生成8字节EntryPoint的驱动程序必须使用锁箱服务来保护EntryPoint使用的代码。如果该函数调用其他函数，其他函数的所有代码也必须受锁箱保护。
与DISPATCH_2_OPCODE关联的Context也是启动脚本中的8字节地址。出于同样的原因，生成8字节EntryPoint的驱动程序必须使用锁箱服务来保护Context参数引用的数据。如果Context包含另一个数据指针，则引用的所有数据也必须受锁箱保护。
在文章"在EDK II中实现S3恢复"中有更详细的描述，该文介绍了EDK II中的锁箱和S3恢复设计。
在大多数情况下，基于SMM的锁箱可以用来保护数据，但并不是所有情况。这取决于锁箱何时准备就绪。基于SMM的锁箱只能在内存初始化后被消耗。如果S3恢复模块需要在内存初始化前消耗数据，那么我们就需要设计另一种解决方案。UEFI只读变量是一个不错的候选，因为它们在内存初始化之前就可以使用。如果锁箱不需要机密性，只读变量就可以用来存储数据。
在大多数IA平台中，内存参考代码（MRC）是初始化系统内存的组件。在内存初始化之前，基于SMM的锁箱无法在MRC中使用，因为SMM尚未就绪。但是，S3路径中的MRC模块依赖于内存配置数据，而内存配置数据必须保存在安全的地方。解决方法是将配置保存到UEFI变量中，并使用EDKII_VARIABLE_LOCK_PROTOCOL将其锁定。由于该变量在EndOfDxe之后是只读的，因此内存配置数据的完整性得以保持。见图9-10。
除了基于本地TEE的锁箱外，安全协处理器，例如AMD平台安全处理器（PSP），也可帮助保存和恢复硅配置。
AMD PSP是基于ARM的处理器，它与AMD64内核位于同一芯片组中。在S3挂起操作中，SMI处理程序捕获S3命令后，SMI处理程序会将S3进入事件通知PSP。PSP保存CPU内核上下文。然后，SMI处理程序向系统发送S3命令。在S3恢复期间，PSP恢复CPU内核的S3保存状态，然后将控制权转移到BIOS，继续S3恢复路径。图9-11显示了 AMD PSP辅助S3恢复流程。
现在，让我们来看一下对锁箱攻击的一些实例和缓解措施。
某些固件实现在S3启动脚本中包含寄存器锁。如果脚本未受保护，攻击者可能会修改启动脚本来注入恶意操作码或删除S3恢复中的锁寄存器访问。启动脚本必须保存到锁箱中。
除启动脚本外，如果固件使用DISPATCH OPCODE，固件还应将生成DISPATCH EntryPoint的镜像保存到锁箱中，并将上下文数据保存到锁箱中。否则，攻击者可以修改DISPATCH函数来注入恶意代码。
锁箱还可用于保存S3恢复过程中使用的机密，例如硬盘存储密码。对于此类机密，锁箱必须使用LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY属性。否则，攻击者可能会在正常启动时转储锁箱的内容。
在正常启动过程中，某些硅寄存器会被锁定来维护系统的完整性，例如SMRAM锁和闪存锁。在S3恢复期间也必须锁定相同的寄存器。否则，攻击者可以触发S3恢复，使系统进入不安全状态。
平台可使用PEI S3恢复代码来锁定寄存器，或将锁定操作放在启动脚本中。强烈建议使用闪存中的代码锁定寄存器，因为它不依赖于启动脚本。
在本章中，我们讨论了S3恢复路径，并重点介绍了锁箱设计。下一章，我们将讨论固件中的访问控制。
会议、期刊与论文
[P-1] Jiewen Yao, Vincent Zimmer, “A Tour Beyond BIOS Implementing S3 Resume with EDK II,” Intel Whitepaper 2015, https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Implementing_S3_resume_with_EDKII_V2.pdf
[P-2] Roger Lai, “AMD Secure and Server Innovation,” in UEFI Plugfest 2013, available at https://www.uefi.org/sites/default/files/resources/UEFI_PlugFest_AMD_Security_and_Server_innovation_AMD_March_2013.pdf
[P-3] Rafal Wojtczuk, Corey Kallenberg, “Attacks on UEFI Security,” in CanSecWest 2015, available at https://fahrplan.events.ccc.de/congress/2014/Fahrplan/system/attachments/2557/original/AttacksOnUEFI_Slides.pdf
[P-4] Oleksandr Bazhaniuk, Yuriy Bulygin, Andrew Furtak, Mikhail Gorobets, John Loucaides, Alex Matrosov, Mickey Shkatov, “Attacking and Defending BIOS in 2015,” in RECon 2015, available at https://papers.put.as/papers/firmware/2015/AttackingAndDefendingBIOS-RECon2015.pdf
[P-5] Yuriy Bulygin, Mikhail Gorobets, Oleksandr Bazhaniuk, Andrew Furtak, “FRACTURED BACKBONE: BREAKING MODERN OS DEFENSES WITH FIRMWARE ATTACKS,” in BlackHat US 2017, https://www.blackhat.com/docs/us-17/wednesday/us-17-Bulygin-Fractured-Backbone-Breaking-Modern-OS-Defenses-With-Firmware-Attacks.pdf
规范和指南
[S-1] UEFI Organization, “ACPI Specification,” 2019, available at https://www.uefi.org/
[S-2] UEFI Organization, “UEFI Platform Initialization Specification,” 2019, available at https://www.uefi.org/