硬件设备是解决方案的重要组成部分。它和板上的其他设备是平台的一部分，例如可信平台模块（TPM）设备、底板管理控制器（BMC）、电源提供单元（PSU）等等。也可以是独立的设备，例如通用串行总线（USB）设备、图形卡设备、网卡设备、硬盘设备等等。
《高度安全设备的七大特性》介绍了如下的设计原则：
1. 基于硬件的信任根
2. 小型可信计算基础
3. 纵深防御
4. 区隔化
5. 基于证书的认证
6. 可再生安全
7. 故障报告
原则3，4与通用安全软件设计原则类似。原则1，2，5，6，7与硬件/固件弹性有关。设备固件弹性应该遵循和主机固件弹性相同的规则。保护、检测和恢复都应该考虑。第3，4，5章已经对此进行了讨论。
在系统启动过程中，主机需要与设备通信以交换信息。这种通信通道可能会受到硬件对手的攻击。攻击机制可能包括但不限于拦截、修改、窃听和伪装。
与主机固件类似，平台可能希望定义一种为设备执行证明的方法，而不仅仅是支持设备固件的弹性。这包括设备硬件身份认证和设备固件身份测量。
图8-1举例说明了如何使用非对称加密技术来实现这一目标。每台设备都配有一个证书。证书的公共部分通过平台活动信任根（PA-RoT）被知晓。证书的私有部分作为秘密保存在设备不可改变的ROM中，作为活动组件信任根（AC-RoT）。在系统启动过程中，平台信任根作为发起者发送消息给设备信任根（回应者），设备发送回应。
在识别阶段，平台信任根请求设备证书，设备信任根返回设备的公共证书。然后，平台信任根可以知道哪个设备在平台上。
接下来，在认证阶段，平台信任根会向设备信任根发送一个质疑消息，设备信任根用其私人证书加密质疑值作为回应。有了质疑/响应，平台信任根就可以知道设备是真实的。
最后，在测量阶段，平台信任根请求设备的测量值，包括不可改变ROM、可变固件、硬件配置和固件配置的测量值。一旦设备信任根返回这些信息，平台信任根可将这些信息保存到TPM设备（用于存储和报告的信任根）中，以便进一步进行平台证明。
一旦平台信任根认证设备后，可能需要交换信息。平台信任根信任设备，但平台信任根可能不信任它们之间的链接。攻击者可能会劫持硬件总线来攻击平台信任根和设备之间的链接。平台主板上的连接类似于今天的互联网 —— 两个端点需要在不受信任的世界中创建一个安全通道。互联网中最著名的安全通道是传输层安全（TLS）。TLS可以在握手阶段提供身份认证，在应用阶段提供保密性和完整性。最初的TLS是在面向连接的协议（例如传输控制协议）之上的一个协议。TLS概念也可用于其他协议，例如可扩展身份认证协议（EAP）。TLS的变种 —— 数据报TLS（DTLS）—— 可用于无连接协议，例如用户数据报协议（UDP）。
安全通道可以包括三个阶段：握手、应用和终止（见图8-2）。在握手阶段，发起者和响应者需要交换密钥和加密参数，并进行身份认证。在握手阶段结束时，发起者和响应者都能计算出一组会话密钥，用于加密消息和计算信息的信息认证码（MAC）。在应用阶段，发起方和响应方可交换应用层信息，这些信息由会话密钥加密，并由会话MAC密钥MAC化。通信结束后，会话即被关闭。
我们已经在第七章讨论过DICE。在这，活动组件信任根（AC-RoT）可以是DICE设备。每个DICE设备包括唯一的设备秘密（UDS），DICE核心基于UDS生成DICE证书。这DICE证书可以用来作为设备标识。第7章的图7-9显示了DICE证书的生成过程。
现在，让我们来看一下安全设备通信的一些实例。
分布式管理任务组（DMTF）平台管理组件交互工作组发布了 "安全协议和数据模型（SPDM）规范"，来定义两个实体之间的消息传递，包括如何交换设备认证和设备测量信息。表8-1列出了SPDM 1.0规范中定义的命令。通过这些命令，主机可对设备进行认证，并将设备测量延伸到TPM PCR中。
表 8-1 认证和测量的SPDM 1.0命令列表
| 命令/应答 | 类型 | 描述 |
|---|---|---|
| GET_VERSION/VERSION | 能力发现与协商 | 接收一个端点的SPDM版本 |
| GET_CAPABILITIES/CAPABILITIES | 能力发现与协商 | 接收一个端点的安全能力 |
| NEGOTIATE_ALGORITHMS/ALGORITHMS | 能力发现与协商 | 协商加密算法 |
| GET_DIGEST/DIGEST | 硬件标识认证 | 接收证书链摘要 |
| GET_CERTIFICATE/CERTIFICATE | 硬件标识认证 | 接收证书链 |
| CHALLENGE/CHALLENGE_AUTH | 硬件标识认证 | 通过质疑-应答协议认证一个端点 |
| GET_MEASUREMENTS/MEASUREMENTS | 固件测量值 | 接收固件测量值 |
TLS是在互联网上提供安全通道的优秀协议。不过对于平台板上的链接来说可能过于复杂。因此，SPDM 1.1规范为平台上的安全通信通道添加了一些特殊命令。这些命令以简化的方式模拟TLS 1.3，假定传输层提供了数据传输和接收的可靠性，并且数据的传输是有序的，或者数据的顺序可以在接收时重建。见表8-2。在握手阶段，两个实体可以使用基于证书的非对称密钥会话创建或基于预共享密钥（PSK）的会话创建。由于嵌入式设备可能处于资源有限的环境中，因此PSK可用于那些不支持非对称密钥加密或证书处理的终端。在应用阶段，两个实体可以通过发送心跳消息或更新会话密钥消息来维护会话。一旦不再需要会话，两个实体就会使用“结束会话”消息关闭会话。
表 8-2 安全通信通道的SPDM 1.1命令列表 【1】
| 命令/应答 | 类型 | 描述 |
|---|---|---|
| KET_EXCHANGE/KEY_EXCHANGE_RSP | 会话握手：基于非对称密钥会话创建 | 启动请求者与响应者之间的握手，认证响应者，协商加密参数（DH密钥交换），并且建立共享的密钥介质。 |
| FINISH/FINISH_RSP | 会话握手：基于非对称密钥会话创建 | 完成请求者与响应者之间由KEY_EXCHANGE发起的握手。 |
| PSK_EXCHANGE/PSK_EXCHANGE_RSP | 会话握手：基于对称密钥会话创建 | 允许请求者和响应者基于预先共享的密钥，使用对称密钥加密执行双向认证和会话密钥建立。 |
| PSK_FINISH/PSK_FINISH_RSP | 会话握手：基于对称密钥会话创建 | 告知响应者请求者知悉PSK并且已经衍生出正确的会话密钥。 |
| HEARTBEAT/HEARTBEAT_ACK | 会话应用：会话维护 | 保持会话活跃。 |
| KEY_UPDATE/KEY_UPDATE_ACK | 会话应用：会话维护 | 更新会话密钥，尤其当每条记录的nonce值即将到达最大值并翻转。 |
| GET_ENCAPSULATED_REQUEST/ENCAPSULATED_REQEDST | 会话应用：由响应者发起的消息（潜在的双向认证） | 接收来自响应者的SPDM请求消息。 |
| DELIVER_ENCAPSULATED_RESPONSE/ENCAPSULATED_RESPONSE_ACK | 对响应者的请求提供应答。 | |
| END_SESSION/END_SESSION_ACK | 会话应用：会话结束 | 结束会话。 |
【1】 注：原文的命令与规范不符，已修正
SPDM 1.0只支持单向认证 —— 请求者认证响应者。SPDM 1.1的封装消息可用来双向认证。响应者能发送消息给请求者，例如GET_DIGEST/GET_CERTIFICATE甚至是CHALLENGE，来验证请求者的身份（标识）。
SPDM定义了数据交换模型。SPDM消息能通过不同的硬件接口发送。USB组织发布了“USB认证规范”来描述在USB总线上如何为USB设备交换SPDM消息。
SPDM消息也可以通过PCIe设备发送。Intel发布了“PCIe设备安全增强规范”作为一种方法。PCI-SIG通过“ECN —— 组件测量和认证（CMA）”和“ECN —— 数据对象交换（DOE）”规范扩充了该材料，来描述在PCI express总线上PCIe设备如何交换SPDM消息，并提供验证组件配置、固件/可执行文件（测量）和硬件身份（认证）的机制。
PCI-SIG发布了“ECN —— 完整性和数据加密”规范来描述如何为两个端口之间收发的交易层报文（TLPs）提供机密性、完整性和重放保护。安全模型考虑了来自链路上的物理攻击威胁，包括对手使用实验室设备，专用的内插器，恶意的扩展设备等来审查试图保密的数据，修改TLP内容，重新排序或删除TLP。
IDE文档定义了IDE数据流，它是端口到端口的连接来保证两个端口间的TLP传输安全。IDE数据流有两类。选择性数据流是指IDE TLP流穿过交换机但不影响安全性，而链接IDE数据流是指两个端口必须连接，并且没有交换机介入。SPDM安全会话消息是用来建立IDE数据流和编程密钥。
其他硬件接口，例如计算机快速链接（CXL），也采用SPDM消息。
DMTF组织定义了管理组件传输协议（MCTP）。它用于受管计算机系统平台管理子系统内智能设备之间的通信。例如，MCTP可用于管理控制器、智能管理设备、网络控制器和系统固件之间的通信。MTCP可通过SMBus/I2C、USB、PCIe厂商定义消息等传输。SPDM消息也可通过MTCP传输。因此，MCTP设备可以交换 SPDM消息。正如我们在第7章中所讨论的，Cerberus项目使用这种机制让平台主动信任根（PA-RoT）认证设备主动组件信任根（AC-RoT）。
EDK II项目正在为其UEFI BIOS实现增加设备固件安全功能。设备认证和测量活动与UEFI镜像认证和测量。见图8-3和图8-4。
以PCI总线为例。PCI枚举过程发现设备后，PCI总线驱动程序会检查UEFI设备认证或测量是否启用。如果启用，PCI总线驱动程序就会利用平台策略来确定该设备是否需要认证或测量。这一步骤是保持兼容性所必需的，因为目前市场上只有数量有限的设备支持这一功能。如果平台策略要求对设备进行认证或测量，PCI总线驱动程序就会检查设备的功能，然后执行认证或测量。只有在设备认证通过并收集了测量结果后，PCI总线驱动程序才会允许启用或使用该设备。如果设备不具备所需的能力或认证失败，PCI总线会将其视为违反策略，并拒绝该设备。这里的"允许"表示PCI总线驱动程序为设备分配资源（MMIO、I/O、总线），并通过EFI_PCI_IO_PROTOCOL使其可被发现；"拒绝"表示PCI总线驱动程序不分配资源，也不安装EFI_PCI_IO_PROTOCOL。
可信计算小组（TCG）PC客户端工作组正在将设备固件测量纳入其"TCG PC Client平台固件概要文件规范"中。来描述如何收集设备测量值、如何将测量值延伸到TPM中，并将测量结果记录在事件日志中。
将所有相关组件放在一起，我们就得到了图8-5。NIST SP800-193提供了一般平台固件弹性指南。NIST SP800-155规范提供了一般平台完整性测量指南。主机CPU可通过PCIe或USB上的SPDM消息与设备通信，来进行认证和测量。设备的测量延伸到TPM，并创建相应的事件日志。独立平台信任根设备可与关键启动设备通信，通过SMBus或I2C上的MCTP发送SPDM消息来进行认证和测量。
现在，让我们看一下安全通信攻击的一些实例和缓解措施。
在UEFI安全启动中，一种攻击方式就是禁用UEFI安全启动功能。这也可用于设备安全。启用/禁用设备认证或测量的平台策略应该是静态设置或者是需要用户实际确认的运行时设置。
设备认证中的设备签名数据库与UEFI安全启动中的镜像签名数据库类似。它是一个记录被允许的设备证书和被禁止的设备证书的数据库。该数据库保存在UEFI变量中，记录可以注册或撤销。当用户要更新设备签名数据库时，必须在实际用户存在的情况下签署或更新新的数据库。
设备选择是一个新的攻击面。由于设备认证是一个新概念，并非所有现有设备都支持它。平台可能会选择采用一种策略，只对某些设备而不是所有设备进行认证。因此，平台需要有一种方法来记录哪些设备需要进行认证，哪些设备可以不进行认证。如果将此信息保存为UEFI变量，则必须将其锁定，否则攻击者可能会直接更新设备选择配置来绕过认证流程。
在设备认证前，我们不知道设备是好的还是恶意的。一个受损的设备或恶意设备可能会发送畸形的响应消息给发起者，包括畸形的头部，畸形的证书，畸形的签名，畸形的测量值等。见图8-6。这些攻击可能会引起发起者的软件缓冲溢出。当解析来自设备的响应时必须小心。
在建立安全通信之前，基本的不安全通信可能已经发生。因此，必须注意预防对设备的攻击。
设备认证和测量是新技术。现有设备可能不支持这些功能。因此，应该检查来自设备的所有信息，确保其格式正确。当主机软件发现一个新设备时，主机软件需要知道它是哪个设备、支持哪些功能以及是什么属性。这些信息通常在设备规范中定义，并以类型-长度-值（TLV）格式报告。然而，恶意设备并不遵循规范，可能会发送畸形的TLV数据，从而导致主机软件出现缓冲区溢出或其他基于解析的漏洞。
现在，让我们看一下设备标识符数据攻击的一些实例和缓解措施。
USB描述符用于报告USB设备属性。USB规范定义了一组标准描述符，包括设备描述符、二进制设备对象存储（BOS）描述符、配置描述符、接口描述符和端点描述符。每个描述符开头的长度字段表示描述符的总大小。
如果软件只是按照USB规范中定义的结构为描述符数据结构分配缓冲区，恶意USB设备可能会提供一个非常大的长度字段值，导致软件缓冲区溢出（见图 8-7）。
蓝牙广告是蓝牙从设备向蓝牙主设备报告信息时发送的信息。广告数据（AD）以长度字段开头，然后是类型和数据。如果主机软件对AD结构做出假设，并仅根据长度字段复制数据，恶意蓝牙设备可能会使用较大的长度字段值注入不良的广告数据，从而导致主机软件缓冲区溢出（见图8-8）。
直接内存访问（DMA）是设备与主机通信的一种机制。经主机许可，设备可访问任何系统内存来交换信息，与主机CPU独立。在主机环境中，大多数架构都支持内存管理单元（MMU），为CPU提供虚拟地址/物理地址转换。对于设备，系统可使用I/O内存管理单元（IOMMU）来执行设备地址/物理地址转换。请参见图8-9。
IOMMU是一项可选功能。没有IOMMU，系统可能会将设备地址视作内存物理地址处理。IOMMU提供两个功能：
1）地址转换：将设备地址重新映射到不同的物理地址。例如，设备可能只支持32位设备地址，最大地址为4GiB。通过IOMMU，设备地址可被映射到高于4GiB的64位物理地址。如果系统没有大的连续物理地址，IOMMU可将连续设备地址映射到分片的物理地址。
2）访问控制：IOMMU可以控制哪些设备可以读取或写入哪些系统内存。这对于防止恶意设备攻击系统内存非常重要。
有了MMU，页表将虚拟地址转换为物理地址。以图8-10为例，页表指针指向页目录的地址。CPU使用虚拟地址的上部分作为页目录的索引，来检索页表的地址。然后，CPU使用虚拟地址的中间部分作为页表索引来检索物理页地址，再加上虚拟地址的下部分作为物理页偏移量。这就是最终的物理地址。每个页表表项都有精确的权限控制，来确定页面是可读、可写还是可执行。在实际应用中，根据虚拟地址大小，页表的层数是灵活的。对于32位架构，可以是2或3级；对于64位架构，可以是4或5级。
如果平台启用了管理程序，管理程序控制最终物理地址访问（见图 8-11）。现代虚拟化技术支持两种不同的转换表。一个转换表位于客户操作系统中。它由客户操作系统控制，将客户虚拟地址转换为客户物理地址。这个客户转换表与没有虚拟化的转换表相同。另一个转换表位于虚拟机监控器中。它由管理程序控制，将客户物理地址转换为主机物理地址。双层转换的优势在于可以在不同的域中实现不同的控制。
IOMMMU的转换过程更复杂，因为IOMMU需要考虑更多：
1）IOMMU引擎
一个平台可能有多个IOMMU引擎。每个IOMMU引擎管理一组PCI设备。在大多数情况下，每个PCI段都有自己的IOMMU引擎。在一个PCI段中，也可能有多个IOMMU引擎。例如，在X86客户机系统上，图形控制器可能有一个专用的IOMMU引擎。所有其他PCI设备则由另一个IOMMU引擎管理。这是由硬件设计决定的。平台需要在IOMMU ACPI表中报告PCI设备范围信息。对于非PCI系统，每个设备都有一个唯一的ID，ID也会在IOMMU ACPI表中报告。每个IOMMU引擎都有一个设备表基址。
2） 设备源标识符
每个设备都应有自己的转换表。两台设备可以参考相同的设备地址，但IOMMU应有能力为两台设备设置不同的物理地址。在IOMMU中，设备源标识符用于识别设备。PCI设备可通过段号、总线号、设备号和功能号来识别（见图8-12）。如果每个段都有自己的IOMMU引擎，则总线/设备/功能编号可用作该段中当前设备的设备源标识符。整个源标识符为16位，包括8位总线号、5位设备号和3位功能号。尽管这是为PCI设备设计的，但非PCI设备也有标识符号。IOMMU使用设备标识符作为设备表的索引，来检索转换表或进程地址空间ID（PASID）表。
3） 进程地址空间ID（PASID）
PASID是PCI Express规范中定义的一项功能。有了PASID，一个设备可被多个进程共享，并为每个进程提供完整的64位虚拟地址空间。PASID的实现要求PCIe事务层数据包（TLP）的前缀包含20位PASID，并将其添加到内存事务TLP中。如果系统支持PASID，设备表中的地址就是PASID表地址。IOMMU使用PASID作为 PASID表的索引来检索转换表的地址。非PCI系统也有类似的概念。每个进程都可以使用一个唯一的ID来表示自己的转换表。
4）嵌套转换表
每个设备都有一个独一无二的转换表。转换表的数据结构与MMU中的数据结构类似。设备地址的上部分用作查找下一级页表的索引。IOMMU使用叶子页表的地址作为最终物理页面地址，再加上设备地址的下部分作为最终物理页面偏移量。
在管理程序环境中，IOMMU引擎可以选择使用两个转换表。这种可选功能称为嵌套转换。为客户操作系统设置的一个客户机转换表将设备地址转换为客户机物理地址。然后，为管理程序设置的另一个主机转换表将客户机物理地址翻译为主机物理地址。IOMMU中这种双层转换的优势在于，它与当前大多数管理程序中的当前虚拟化设计相一致，即不同的域有不同的控制。
与MMU类似，每个页表项都有精确的权限控制，来确定页面是否可读、可写、可执行或甚至不存在。如果设备访问违反了转换表中预定义的策略控制，访问将被拒绝，IOMMU引擎将产生错误。
图8-13展示了全部的IOMMU地址转换流程。
现在，让我们看一下DMA保护的一些实例。
英特尔定向I/O虚拟化技术（VT-d）是IOMMU的一种实现。它支持DMA地址转换功能。VT-d引擎使用两级设备表。每个VT-d引擎只有一个根表（root table）。当进行地址转换时，VT-d使用高8位（总线编号）作为根表的索引，来检索上下文表的地址。然后，VT-d将低8位（设备编号和功能编号）作为上下文表的索引，来检索下一个转换表的地址。它可以是PASID表或在不支持PASID下是设备转换表。
如果系统支持PASID，则上下文表中的地址就是PASID目录。如果设备发送带有20位PASID的内存访问请求，VT-d将PASID[19:6]作为PASID目录的索引来检索PASID表的地址。然后，VT-d将PASID[5:0]作为PASID表的索引来检索设备转换表的地址。
VT-d支持嵌套转换。客户机转换表称为一级转换表。主机转换表称为二级转换表。转换表的两个地址都包含在PASID表项中。一级转换表和二级转换表的结构与其他页表类似。VT-d引擎使用地址的高位作为索引来检索下一级页表，直到包含最终物理页地址的叶子页。
图8-14显示了使用VT-d的地址转换。更多详细信息请参考英特尔VT-d规范。
通常，DMA访问可以通过两种方式阻止：转换和排除。除了转换页表之外，VT-d还包括两组寄存器以提供DMA排除。该寄存器被称为受保护的内存寄存器（PMR）。一个寄存器组低于4GB ——受保护的低内存寄存器（PLMR）。另一个是高于4GB ——受保护高内存寄存器（PHMR）。PMR覆盖的区域是不具有DMA功能的区域（见图8-15）。这种DMA排除机制在简单且资源受限的环境中是有用的，例如系统固件或认证代码模块（ACM）中的早期启动阶段。
AMD IOMMU具有DMA转换能力，但使用不同的数据结构。IOMMU引擎可以有多个设备表段。每个设备表只是一个一级表。支持嵌套转换。每个设备表表项包括两个转换表地址：客户机CR3（GCR3）表和主机页表。客户机CR3表用于PASID转换，它可以是多级的。IOMMU使用PASID作为索引来检索最终客户机CR3级别1表中的客户机页表地址。然后IOMMU使用客户机页表客户机设备地址转换为客户机物理地址，并使用主机页表将客户机物理地址转换为系统物理地址。
除了DMA转换，AMD还通过DMA排除 ——设备排除矢量（DEV）支持了DMA保护。DEV表是物理存储器中一个连续比特位阵列，每个比特对应一个4K页。
图8-16显示了AMD IOMMU的地址转换。更多详细信息，请参考AMD IOMMU规范。
ARM系统使用系统内存管理单元（SMMU）进行DMA重映射。由于大多数ARM系统不支持PCI设备，故使用StreamID作为设备标识符，并使用SubStreamID作为PASID。StreamID命名空间是基于SMMU的。不同的SMMU后的设备可能被分配相同的StreamID。一个设备可能会以不止一个StreamID发送流量，这表示数据流是按设备特定状态区分的。SubStreamID用于区分来自同一逻辑块的流量来源，以便为每个流量关联不同的应用地址转换。每个SMMU都有一个数据流表。SMMU使用StreamID作为索引，从数据流表中获取数据流表项（STE）。数据流表项包括第一阶段上下文表（S1ContextPtr）的地址和第二阶段转换表（S2TTB）的地址。然后，SMMU使用SubStreamID作为索引，从第一阶段上下文表中获取上下文描述符（CD）。上下文描述符包括第一阶段转换表（TTB0/TTB1）的地址。第1阶段和第2阶段转换表如我们之前讨论的那样支持嵌套转换。阶段1转换表将客户机虚拟地址转换为中间物理地址，阶段2转换表将中间物理地址转换为最终物理地址。
图8-17显示了使用ARM SMMU的地址转换。更多细节信息请参考ARM SMMU规范。
EDK II为系统固件实现了一个IOMMU协议（见图8-18）。IOMMU协议对IOMMU访问进行了抽象。典型的IOMMU驱动程序包括以下四个组件：
- IOMMU ACPI表解析器：平台通过ACPI表报告IOMMU的存在。与平台无关的IOMMU驱动程序会解析ACPI表，确定IOMMU的位置和受IOMMU管理的设备。
- IOMMU引擎管理器：该驱动程序需要控制IOMMU，包括启用、禁用和刷新转换表。
- 转换表管理器：驱动程序也需要根据设备的请求更新转换表。默认情况下，IOMMU初始化后，任何内存都不支持DMA。当设备请求DMA缓冲区时，IOMMU驱动程序允许在IOMMU的转换表中进行DMA访问。一旦DMA缓冲区被释放，IOMMU驱动程序需要撤销IOMMU转换表中的访问权限。
- IOMMU协议服务：驱动程序提供一个软件接口，以便其他设备驱动程序提交DMA请求。
提交DMA请求的设备可以是使用EFI_PCI_IO_PROTOCOL的PCI设备。它也可以是低功耗子系统（LPSS）ACPI设备，如通用异步接收器/发送器（UART），或通过串行外设接口（SPI）或内部集成电路（I2C）总线或安全数字输入输出（SDIO）总线连接的设备。这些设备使用设备特定的I/O接口。以图8-19中的PCI驱动程序为例。这里，PCI驱动程序使用AllocateBuffer/FreeBuffer来管理用于读取和写入的通用DMA缓冲区，或者分配系统内存，然后使用Map/Unmap将其用作读取DMA缓冲区或写入DMA缓冲区。所有这些操作都与IOMMU驱动程序挂钩。IOMMU驱动程序 在AllocateBuffer/FreeBuffer/Map/Unmap函数中分配DMA缓冲区。随后，PCI驱动程序使用IOMMU协议中的SetAttributes函数通知IOMMU 驱动程序访问权限，并修改DMA转换表中的访问权限。转换表是基于设备的，因此IOMMU驱动程序能通过设备句柄识别设备。IOMMU转换表是为细粒度保护而设置的。由于IOMMU驱动程序可通过UEFI设备句柄识别设备，因此每个设备都将分配一个转换表。
UEFI环境默认不启用虚拟化，不会为PCI设备启用PASID。因此，IOMMU引擎只需要使用设备表和主机转换表。PASID表和客户机转换表不是必需的。
在UEFI环境建立之前，预先通用可扩展固件接口初始化（PEI）阶段也可以在内存初始化后使用IOMMU（见图8-20）。PEI阶段是一个简单且资源受限的执行环境。此时，没有设备句柄的概念。因此，所有设备共享一个转换表。某些架构可能会提供一组寄存器来定义全局DMA可行区域或全局DMA不可行区域。这些寄存器可用于设置受保护区域，并留出一小块区域作为DMA缓冲区。这就简化了固件代码。以Intel VT-d为例，受保护的高内存基址和限制寄存器（PHMB/PHML）和受保护的低内存基址和限制寄存器（PLMB/PLML）都可用于PEI阶段。PEI IOMMU驱动程序可设置PHMB/PHML寄存器，来覆盖从4GiB到可用DRAM上限（TOUUD）的区域。对于低于4GiB的内存，某些MMIO区域天然不支持DMA，例如闪存、高级可编程中断控制器（APIC）和PCIe配置空间。即使低于低可用DRAM（TOLUD）上限，一些特殊区域也不支持DMA，例如系统管理RAM（SMRAM）。因此，PEI IOMMU驱动程序可以将支持DMA的内存区域保留在DMA不可行的区域下方，并设置 PLMB/PLML来覆盖内存的其余部分。
图8-21显示了EDK II中的DMA保护机制。固件退出（正常启动中的ExitBootServices事件和S3恢复时的EndOfPei）与操作系统IOMMU驱动程序取得控制之间可能存在间隙。如果操作系统无法直接从固件处取得IOMMU的控制，固件就必须禁用基于IOMMU的保护。如果操作系统可以无缝取得IOMMU控制，固件则可以继续启用IOMMU。
“在UEFI固件中使用IOMMU进行DMA保护”详细描述了EDK II中的IOMMU设计。
现在，让我们来看一下一些DMA攻击的实例和他们的缓解措施。
直接内存访问（DMA）攻击是绕过固件安全功能（例如安全启动或认证更新）的一种方法。在主机CPU认证镜像后，恶意设备可能会产生DMA流量在CPU执行镜像或读取镜像之前修改镜像的内存。DMA攻击还可用来窃取内存中的机密，例如BIOS密码和硬盘驱动器（HDD）密码。PCILeech和microblaze是一种开源工具，可以执行这样的DMA攻击。图8-22显示了可能的DMA攻击。
由于恶意DMA是由恶意设备产生的，因此首先要考虑的缓解措施就是禁用设备的DMA。PCI设备在PCI配置空间中有一个总线主使能（BME）位。该位可用于控制PCI设备是否允许DMA。理想情况下，固件可以通过不设置BME位来防止DMA攻击。然而，有局限性：
- 某些内部PCI设备或非PCI设备没有BME位。DMA始终启用。
- 如果桥接器下的设备需要DMA，则路径上的所有桥接器都需要设置BME启用位。
- EDK II PCI总线驱动程序需要启用BME位，来测试是否可以启用或禁用BME。这样，设备驱动程序就能知道是否需要设置BME来启用DMA。
- 平台可以选择只为启动时所需的设备（例如一个存储设备和一个图形设备）启用BME。但在最终用户选择这些设备之前，这些设备必须首先存在且工作。如果存在多个设备，设备驱动程序已经启用了这些设备的BME位。如果有一个设备是恶意的，那么在启用BME位后清除BME位是无效的，因为攻击已经发生了。
通常情况下，IOMMU引擎由操作系统设置，来防止对操作系统内核的DMA攻击（见图8-23）。此处，固件也可以使用IOMMU来抵御DMA攻击。系统内存默认不支持DMA。只有在设备驱动程序发送DMA缓冲区请求后，IOMMU才会为该特定设备分配DMA缓冲区。一旦DMA完成，IOMMU就会将内存重置为不支持DMA。
正如我们所见，IOMMU是防止对设备进行DMA攻击的有效方法。对于已经采用基于IOMMU保护的平台，一种可能的攻击方式是删除IOMMU ACPI表报告。这样，主机软件就会认为系统中没有可用的IOMMU。
这种攻击可以通过启用UEFI安全启动来缓解。这样，就无法运行不受信任的第三方代码。另一种方法是启用TCG可信启动。例如，启用DRTM和Intel TXT后，SINIT-ACM将验证DMAR ACPI表。如果缺少DMAR ACPI表或DMAR表中的信息与预期不符，SINIT-ACM将触发平台的TXT重置。如果创建了预期的DMAR表，SINIT-ACM将复制DMAR表到TXT堆的SINIT-to-MLE区域。然后，管理程序就可以从TXT堆获取验证后的DMR表，而不是从正常的ACPI表区域。
消息信号中断（MSI）是一种让PCIe设备向CPU发送中断信号的机制。在引入MSI之前，传统PCI设备使用专用中断线（主板上的引脚和导线）来发出传统中断信号。这是一种带外机制。传统PCI设备每张卡仅限四个中断引脚。基于MSI的新中断是一种带内中断传输机制。从设备的角度来看，MSI只是一个写入特殊目标地址的PCIe内存事务。使用MSI，PCI设备可以有32个向量。有了MSI-X，向量数量增加到2048个。
以前，X86平台只有一个 CPU。操作系统需要建立一个中断描述符表（IDT）来描述每个中断向量的中断处理程序地址。X86系统定义了256个中断向量。前32个向量是保留的异常，如除以零、调试、断点和页面故障异常。其余的则用于硬件中断或软件产生的中断。这些旧平台使用可编程中断控制器（PIC），也称为8259。典型的系统有两个8259控制器，一个作为主设备，另一个作为从设备。每个8259芯片都有八个中断请求（IRQ）输入。这样，一个系统就有16个IRQ输入。每个8259芯片都可以通过软件编程设置中断向量基址。因此，每个IRQ可由PIC映射到中断向量。遗憾的是，传统系统已经为特定设备分配了某些IRQ。例如，IRQ0用于定时器，IRQ1 用于PS2键盘，IRQ2用于8259从设备，IRQ3用于串行端口A，IRQ4用于串行端口B，IRQ5用于并行端口A，IRQ6用于软盘，IRQ7用于并行端口B，IRQ8用于CMOS/RTC报警，IRQ12用于PS2鼠标，IRQ13用于算术处理器，IRQ14用于传统主IDE控制器，IRQ15用于传统次要IDE控制器。
因此，能分配给PCI设备的IRQ数量有限。根据PCI规范，每个PCI设备可以有四个中断引脚（INTA#、INTB#、INTC#、INTD#）。PCI设备的每个功能都有一个引脚。现在，我们需要一种将PCI设备中断引脚映射到有限IRQ的方法。这由可编程中断路由器实现。系统通常有八个PCI中断请求（PIRQ）路由控制寄存器（PIRQA、PIRQB、PIRQC、PIRQD、PIRQE、PIRQF、PIRQG、PIRQH）在低引脚数（LPC）控制器。对于PCI设备，INT A/B/C/D通常是硬编码。PIRQ寄存器将芯片组上的引脚映射到特定的IRQ。电路板上的导线决定INTA/INTB/INTC/INTD是否映射到IRQA/PIRQB/PIRQC/PIRQD/PIRQE/PIRQF/PIRQG/PIRQH，内置设备除外。图8-24显示了带有8259的中断流程。
单个CPU已不再是趋势。如今的大多数系统都包含多个CPU。每个CPU都有自己的IDT表。PIC是不够的，因为它无法指出哪个中断向量是哪个CPU的。X86系统引入了高级可编程中断控制器（APIC）。APIC分为多个部分 —— CPU内部的本地APIC和与传统PIC有类似目的的IOAPIC。让我们先关注一下IOAPIC。IOAPIC支持24个APIC中断。每个中断都有一个由软件在中断重定向表中指定的的唯一向量。前16个中断映射到16个传统IRQ（IRQ0 ~ IRQ15）。接下来的8个中断（索引16 ~ 23）专用于8个PCI IRQ（PIRQA ~ PIRQH）。IOAPIC其中一个优势是，我们不需要费力地为PCI IRQ分配IRQ编号。IOAPIC的另一个优势是，我们可以在中断重定向表中指定哪个 IRQ发送给哪个CPU。中断重定向表中的每个表项都有一个目标ID。目标ID与CPU本地的APIC中的APIC ID相匹配。APIC ID在多CPU系统中也是CPU的标识符。在APIC模式下，PCI设备只需指出哪个APIC索引（16 ~ 23）是中断线。当然，如果系统需要支持多个PCI设备，则可能包含多个IOAPIC。通过第二个IOAPIC，所有24个中断都可用于PCI IRQ。图8-25显示了带有IOAPIC的中断流程。
除了PCI设备外，CPU可能需要在多CPU环境中通过处理器间中断（IPI）交互通信。这可以通过本地APIC来实现。每个本地APIC都有一个中断命令寄存器（ICR）。访问ICR只是内存写入操作。软件可通过向ICR写入其他CPU的目标ID和向量编号。然后，硬件将通过本地APIC总线向其他CPU发送中断。图8-26显示了带有本地APIC的中断流程。
通过本地APIC，软件可以写入一个地址来触发中断。我们能否对PCI设备使用类似的机制呢？答案是肯定的，使用消息信号中断（MSI）。PCI设备可在PCI配置空间中提供消息地址寄存器和消息数据寄存器。软件可在消息地址寄存器中写入目标ID，在消息数据寄存器中设置向量。一旦PCI设备请求中断，设备只需将消息数据写入消息地址。然后，本地APIC就可以解释该消息并调用相应的中断处理程序。这一操作不依赖于任何中断引脚。这种设计消除了引脚数量的限制，并提供了低延迟和高效率。参见图8-27。
MSI提供了灵活性。然而，设备可能会直接向系统总线发送恶意中断信息并破坏系统，如启动信息、系统中断调用或对齐检查（#AC）异常。因此，我们需要一种方法来防止这种情况发生。
基本的缓解思路借鉴了特权环从用户模式切换到监管模式的保护机制。监管者模式代码设置了带有服务处理程序地址和门编号的一个调用门或中断门。用户模式只能调用该门切换到服务处理程序代码，而不能任意选择调用哪段代码。
新的MSI中断格式称为重映射格式。重映射格式与原始兼容格式的关键区别在于重映射格式允许指定各种详细属性，例如目标ID和向量编号。这些信息被编入中断重映射表（IRT）中。可重映射MSI格式只允许编写中断重映射表的索引。见图8-28。
系统IOMMU引擎也可支持IRT。它提供中断隔离和中断迁移功能。
现在，让我们看一下中断保护的一些实例。
英特尔VT-d引擎支持中断重映射。每个VT-d引擎有一个中断重映射表。当MSI产生时，MSR地址和MSR数据字段包括句柄和子句柄信息。IOMMU将这两个字段用作重映射表中重映射表项的索引。重映射表项包括目标ID和向量信息。IOMMU根据重映射表项中的信息生成新的中断请求。
除了普通的中断重映射，VT-d引擎也支持发布中断重映射。发布中断是虚拟化技术的一项功能。它允许APIC直接向客户操作系统注入中断，而无需退出虚拟机。在初始化阶段，管理程序会为客户操作系统中的每个虚拟CPU设置一个发布中断描述符（PID）。PID包括已发布中断请求（PIR）、抑制位、通知目标 （NDST）和通知向量（NV）。PIR中的每个位都映射到一个中断向量。当客户操作系统配置中断时，管理程序会分配中断重映射表项，并填入已发布的中断描述符、紧急位和虚拟向量。当中断触发时，IOMMU会检查重映射表项是重映射中断还是已发布中断。如果是已发布中断，IOMMU会检查已发布中断的表项标志（如抑制和紧急），来确定管理程序是否要立即处理该中断。如果不是，IOMMU会更新已发布中断请求位，让客户操作系统后续处理。如果管理程序想要处理，IOMMU就会向通知目标的通知向量发出中断信号。
发布中断功能提高了虚拟化效率，并支持虚拟中断迁移。对于支持单根（single-root）I/O虚拟化（SR-IOV）的PCI设备，该功能允许管理程序将虚拟中断直接分配给一个虚拟函数（VF）。它解决了中断向量可扩展性问题，因为每个VF都可以有自己的虚拟向量编号。
图8-29显示了英特尔VT-d中的中断重映射。更多详细信息，请参考英特尔VT-d规范。
AMD IOMMU支持设备级的中断重映射。每个设备表项都包含一个中断重映射表地址。IOMMU使用MSI数据位10~0作为中断重映射表的索引来获取表项。重映射表项包括目标ID和向量信息。最后，IOMMU重新生成中断请求并将其发送出去。
图8-30显示了AMD IOMMU中的中断重映射。更多详细信息，请参考AMD IOMMU规范。
与X86系统不同，ARM系统采用不同的中断控制器架构，遵循通用中断控制器（GIC）规范。见图8-31。GICv2支持1024个中断号（INTID）。INTID 015用于软件生成中断（SGI）。INTID 1632为专用外设中断（PPI）。SGI和PPI都是CPU接口的本地中断。INTID 1020~1023用于特殊用途。其余为共享外设中断（SPI）。这是一种基于硬件引脚的机制。PPI和SPI由GICv2中的分配器组件管理。PPI是CPU内核专用的。SPI可共享，分配器提供SPI的路由配置。仲裁完成后，分配器将中断发送到GICv2中相应的CPU接口。CPU接口通过IRQ（中断请求）或FIQ（快速中断请求）向相应的CPU内核发送中断信息。GICv2最多支持八个处理单元（PE）。这对于客户端系统来说可能已经足够，但服务器平台可能需要支持更多的内核。
GICv3定义了支持更多内核的亲和层次结构，分离了CPU接口，并在分配器和CPU接口之间添加了一个再分配器（见图 8-32）。每个CPU接口都有一个相关的再分配器。现在，分配器管理SPI并将其发送到再分配器。再分配器管理PPI并通过中断路由基础结构（IRI）命令将中断发送到CPU接口。最后，CPU接口向CPU内核发送IRQ和 FIQ。
GICv3引入了一种新的基于消息的中断 —— 特定位置外设中断（LPI）。它可以减少系统中的线数。与MSI类似，一个基于内存的设置LPI未决寄存器（GICR_SETLPIR）由GICv3中的再分配器提供。支持LPI的设备可将IntID信息写入寄存器触发LPI。然后，LPI被传送到再分配器。
GICv3还引入了中断转换服务（ITS）。见图8-33。LPI设备可以向ITS转换寄存器（GITS_TRANSLATER）发送EventID信息，而不是IntID。然后，ITS将EventID转换为最终IntID，并将IntID发送给最终再分配器。在ARM系统中，中断重映射由GIC中的ITS完成。
ITS包含设备表的地址。当设备发送LPI时，ITS将设备ID用作设备表的索引，来检索中断转换表（ITT）的地址。然后，ITS使用EventID作为ITT的索引来检索中断转换表项(ITE)。对于物理中断，ITE包括IntID和中断集合编号（ICID）。ITS从ICID导出集合表ID，并使用该表ID作为索引，选择描述目标再分配器的集合表（CT） 表项。最后，ITS将IntID发送给再分配器。对于GICv4支持的虚拟中断，ITE包括虚拟IntID（vIntID）和虚拟处理元件ID（vPEID）。ITS使用vPEID作为vPEID表的索引来获取真正的再分配器，并将vIntID传递给再分配器。
图8-34显示了ARM GIC中的中断重映射。更多详细信息，请参考ARM GIC规范。
现在，让我们来看一下一些中断攻击的实例和他们的缓解措施。
由于MSI由设备生成，恶意设备可能会在系统总线上生成恶意MSI来攻击系统。如果没有中断重映射，设备就有能力决定CPU目标ID和中断向量。仅仅产生一个普通中断是没有意义的。它可以由普通中断处理程序处理。然而，有些特殊的中断处理程序可以用来攻击系统，例如启动处理器间中断（SIPI）、系统调用INT服务和对齐检查（#AC）异常。这些特殊中断处理程序可用于从不受信任的域攻击受信任的域。让我们逐一看看：
1）SIPI攻击
在具有多个处理器的X86系统中，CPU需要发送特殊中断，例如系统管理中断、非屏蔽中断、INIT和启动。这些信息包含在本地APIC的中断命令寄存器（ICR）中。它被命名为交付模式（DM）。例如，如果启动程序处理器（BSP）希望重启应用处理器（AP），BSP可以在ICR中发送INIT消息，然后在ICR中发送启动IPI（SIPI）消息。SIPI消息包含一个启动向量，它指向1MiB以下的4K对齐的地址。AP收到信息后，将被重置并在该地址重新启动。
X86系统的MSI消息类型采用相同的设计。具体来说，MSI地址寄存器包含目标ID，MSI数据寄存器包含中断向量。此外，MSI数据寄存器还包含发送模式（DM）。这意味着设备可能会发送一些特殊中断。启动IPI（SPI）就是其中之一。如果攻击者设法写入1MiB内存并在其中放置了shellcode，他们就可以让设备发送MSI消息，让其中一个CPU不受任何限制地开始执行shellcode。见图8-35。
2）系统调用注入攻击
管理程序通常为可信域提供超级调用（软件中断，例如INT 0x80或0x82）以提供服务。为了防止来自不可信域的超级调用，管理程序会检查执行上下文。如果当前上下文不是可信域，超级调用就会被拒绝。如果攻击者在可信域处于活动状态时设法让设备发送MSI（超级调用软件中断），那么管理程序就会认为超级调用是由可信域发送的。通过精心准备的参数，攻击者可以利用超级调用，让管理程序向不受信任的域授予更多权限。见图8-36。
3）对齐检查（#AC）异常注入攻击
MSI数据消息包括中断向量。向量编号可以从0x10至0xFF。但是，向量编号从0x10到0x1F是异常编号。当异常发生时，CPU可能会将错误代码放到堆栈顶部，以提供异常的附加信息。错误代码是异常特定的。有些异常有错误代码，有些异常则没有。不幸的是，对齐检查异常（#AC，向量0x11）有错误代码。#AC处理程序假设顶部有错误代码，并解析数据结构。然而，CPU从未为硬件中断设置错误代码。如果设备指示生成向量为0x11的MSI，则堆栈顶部没有错误代码。当#AC异常处理程序解析数据并返回时，会将CS视为RIP，将RFLAGS视为CS。如果攻击者设法控制了RFLAGS和CS，并将shellcode放到RFLAGS:CS指向的低内存中，那么他们就可以在特权环境中控制代码的执行。见图8-37。
所有MSI攻击都是在管理程序环境中演示的。固件通常不会启用管理程序。并且固件通常不会启用设备中断。然而，MSI可以在固件中启用。例如，EDK II高精度事件定时器（HPET）可配置为通过IOAPIC或MSI发送中断。万一在固件中启用了更多权限控制，则必须注意防止不信任域启用设备MSI来攻击信任域。
可靠性、可用性和可维护性（RAS）是描述服务器平台稳健性的术语。最初，它来自于IBM大型计算机。现在，它已成为服务器计算机的一个重要属性。RAS能力是一个系统级概念，包括硬件、软件和固件。每个服务器供应商都可能有自己的RAS解决方案。介绍完整的RAS功能超出了本书的范围。这儿，我们只关注高级RAS功能对安全的影响。
现在，让我们来看一下一些服务器RAS的实例。
CPU热添加（又称CPU在线）是一种RAS功能，可在不关闭机器的情况下添加新的CPU硬件到运行的系统。CPU热添加需要：
- 硬件支持： 硬件内部逻辑需要支持与新添加的CPU的业务。
- 固件支持： 固件需要在BIOS中提供初始化路由，系统管理模式（SMM）中的CPU同步路由和ACPI路由，来帮助操作系统（OS）启动机器。
- 软件支持： 操作系统需要支持添加新CPU的能力。
我们在第7章中介绍了CPU热添加的高级流程。正常CPU在操作系统中运行时，会收到热插拔事件并退出。热添加的CPU需要像正常CPU一样运行CPU复位向量，以完成CPU初始化和内存配置。然后，正常CPU释放静止状态，将热插拔CPU带入操作系统环境。CPU交会的细节可能与具体实现有关。图8-38显示了一个示例。
从主机现有的CPU端：
步骤 1：平台生成系统控制中断（SCI）或通用事件（GPE）。事件由操作系统ACPI驱动程序捕获。
步骤 2：操作系统ACPI驱动程序运行固件提供的SCI/GPE处理程序。并且ACPI代码会触发系统管理中断（SMI），在系统管理模式（SMM）下等待会合。
从新添加的CPU端：
步骤 A：新加入的CPU按正常流程执行系统复位向量，并进行基本内存配置。
步骤 B：新添加的CPU执行SMM重置，将默认SMI处理器地址从0x38000更改为系统管理内存（SMRAM）。
步骤 C：新添加的CPU与SMM中的其他现有CPU进行SMM会合。然后，新CPU等待来自操作系统的唤醒消息。
从主机现有CPU端：
步骤 3：SMM会合完成后，主机CPU返回ACPI代码。ACPI处理程序通知操作系统CPU驱动程序已添加新CPU。
步骤 4：操作系统向新CPU发送启动消息，并将新CPU带入操作系统。现在，所有CPU都能在操作系统环境中运行。
服务器RAS设计还涉及内存子系统。例如，纠错码（ECC）技术可以检测和纠正DRAM芯片中的单位或多位内存错误。一些高级内存保护技术需要固件支持，如在线备用内存和热插拔镜像内存。
在线备用内存是ECC的补充（见图8-39）。DIMM可以设计一个特殊排位作为在线备用排位。如果其中一个DIMM超过了可修正内存错误的阈值率，该DIMM中受影响的内存排位将离线，数据将被复制到在线备用排位。这项技术可在不关闭服务器的情况下保持服务器的可用性和内存的可靠性。
镜像内存是一种容错解决方案，比在线备用内存提供更高的可用性（见图8-40）。其基本思想是，用户指定一半内存作为系统内存，另一半内存作为镜像内存。相同的数据同时写入系统内存和镜像内存，数据只从系统内存读取。但如果DIMM达到预定义的内存错误阈值，系统将从镜像内存读取数据。镜像内存可以是非热插拔的，也可以是热插拔的。如果使用热插拔镜像内存，用户可以在不关闭服务器的情况下热插拔发生故障的DIMM。
硬件和系统固件都支持在线备用内存和热插拔镜像内存。无需操作系统或特殊软件支持。
现在，让我们看一下服务器RAS攻击的实例和缓解措施。
在X86系统中，如果CPU被热添加，它将执行来自BIOS复位向量和初始启动块的指令。它还需要执行SMM重置，从位于0x38000的默认SMI处理器到SMRAM顶段 (TSEG)。这一操作是强制性的，因为0x38000是正常的DRAM区域。它不是SMRAM，不受系统架构保护。现在，如果攻击者掌握系统，他们可以编写shellcode并复制到0x38000区域，或使用恶意设备产生DMA事务，将数据写入到0x38000（见图8-41）。一旦热添加的CPU完成SMM重置，CPU就会在SMM中运行恶意代码。这很危险，因为SMM中的shellcode掌握整个系统，包括更新闪存区域或将木马注入受保护的SMRAM。
为了防止SMM重置攻击，平台需要在SMM中交会所有活动的CPU，然后让热添加的CPU在默认SMBASE中重新初始化处理程序，然后执行SMM重置。此外，还应考虑DMA攻击。服务器硅片引入了GENPROTRANGE寄存器。固件需要设置0x38000到GENPROTRANGE，使其成为不支持DMA的区域（见图8-42）。有了这些保护措施，恶意程序就无法运行，恶意DMA也无法攻击默认SMBASE。
另一个攻击点是唤醒向量。当操作系统将新CPU带入环境时，操作系统会发出向量号为0xE2的启动IPI消息，即让新CPU执行在地址为0xE2000的代码。类似的保护机制可用于维护系统的完整性，包括DMA保护和完整性验证。参见图8-43。
系统固件是支持在线备用内存和热插拔镜像内存的关键要素。这项工作由操作系统运行时的系统管理模式（SMM）完成。由于SMM代码需要帮助将操作系统内存复制到良好的DIMM组，因此SMM代码需要：1）读取操作系统内存；2）写入操作系统内存。读取操作可能会破坏机密性，写入操作可能会破坏完整性。因此，SMM RAS处理程序必须被仔细审查，平台制造商必须确保不存在漏洞。
有关SMM安全性的更多细节，请参考第17章。
在本章中，我们讨论了与设备安全相关的主题，包括安全设备设计原理、安全通信和设备攻击预防，例如DMA和中断。在下一章中，我们将重点讨论系统固件和S3恢复启动路径。
会议、期刊与论文
[P-1] Galen Hunt, George Letey, Edmund B. Nightingale, “The Seven Properties of Highly Secure Devices,” in Microsoft Whitepaper 2017, available at https://www.microsoft.com/en-us/research/wp-content/uploads/2017/03/SevenPropertiesofHighlySecureDevices.pdf
[P-2] Jiewen Yao, Vincent Zimmer, “A Tour Beyond BIOS Using IOMMU for DMA Protection,” Intel Whitepaper 2017, available at https://www.intel.com/content/dam/develop/external/us/en/documents/intel-whitepaper-using-iommu-for-dma-protection-in-uefi-820238.pdf
[P-3] Anthony Ligouri, “Powering Next-Gen EC2 Instances: Deep Dive into the Nitro System,” in AWS re:Invent 2018, available at https://www.slideshare.net/AmazonWebServices/powering-nextgen-ec2-instances-deep-dive-into-the-nitro-system-cmp303r1-aws-reinvent-2018
[P-4] Shelia Berta, “Backdooring Hardware Devices By Injecting Malicious Payloads On Microcontrollers,” in Blackhat US 2019, available at https://i.blackhat.com/webcasts/2019/Microcontrollers_BH_webcast_Sheila_Berta.pdf
[P-5] Damien Aumaitre, Christophe Devine, “Subverting Windows 7 x64 Kernel with DMA attacks,” in HITB SecConf 2010, available at https://conference.hitb.org/hitbsecconf2010ams/materials/D2T2%20-%20Devine%20&%20Aumaitre%20-%20Subverting%20Windows%207%20x64%20Kernel%20with%20DMA%20Attacks.pdf
[P-6] Jeff Forristal, “Hardware Involved Software Attacks,” Whitepaper 2011, https://www.semanticscholar.org/paper/Hardware-Involved-Software-Attacks-Forristal/842a04f4eec4288a615d03bf76ed59b1513b8515
[P-7] Fernand Lone Sang, Vincent Nicomette, Yves Deswarte, “I/O Attacks in IntelPC Architectures and Countermeasures,” in LAAS-CNRS 2011, available at https://www.researchgate.net/publication/261523463_IO_Attacks_in_Intel_PC-based_Architectures_and_Countermeasures
[P-8] P. Stewin and I. Bystrov. “Understanding DMA Malware,” in Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA’12), 2012, available at https://pdfs.semanticscholar.org/88ad/913424405ac32657a8557f74003b22e9be3c.pdf
[P-9] Russ Sevinsky, “Funderbolt – Adventures in thunderbolt DMA attacks,” in Blackhat US 2013, available at https://media.blackhat.com/us-13/US-13-SevinskyFunderbolt-Adventures-in-Thunderbolt-DMA-Attacks-Slides.pdf
[P-10] Sergej Schumilo, “Don’t trust your USB,” in Blackhat 2014, available at https://www.blackhat.com/docs/eu-14/materials/eu-14-Schumilo-Dont-Trust-Your-USB-How-To-Find-Bugs-In-USB-Device-Drivers-wp.pdf
[P-11] Trammell Hudson, “Thunderstrike,” in 31C3 2015, available at https://trmm.net/Thunderstrike_31c3
[P-12] Trammell Hudson, Xeno Kovah, Corey Kallenberg, “Thunderstrike 2,” in Blackhat 2015, available at https://www.blackhat.com/docs/us-15/materials/us-15-Hudson-Thunderstrike-2-Sith-Strike.pdf
[P-13] Mickey Shkatov, Jesse Michael, “Scared Poopless – LTE and your laptop,” in DEFCON23 2015, available at https://infocondb.org/con/def-con/def-con-23/scared-poopless-lte-and-your-laptop
[P-14] Alex Ionescu, “Getting Physical With USB Type-C – Windows 10 RAM Forensics and UEFI Attacks,” in Recon 2017, available at http://publications.alex-ionescu.com/Recon/ReconBru%202017%20-%20Getting%20Physical%20with%20USB%20Type-C,%20Windows%2010%20RAM%20Forensics%20and%20UEFI%20Attacks.pdf
[P-15] Ben Blaxil, Joel Sandin, “PicoDMA: DMA Attacks at Your Fingertips,” in Blackhat US 2019, available at http://i.blackhat.com/USA-19/Wednesday/us-19-Sandin-PicoDMA-DMA-Attacks-At-Your-Fingertips.pdf
[P-16] Rafal Wojtczuk, Joanna Rutkowska, “Following the White Rabbit: Software attacks against Intel(R) VT-d technology,” invisiblethingslab whitepaper 2011, https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
[P-17] Cuauhtemoc Chavez-Corona, Jorge Gonzalez-Diaz, Rene Henriquez-Garcia, Laura Fuentes-Castaneda, Jan Seidl, “Abusing CPU Hot-Add weaknesses to escalate privileges in Server Datacenters,” in CanSecWest 2017, available at https://www.slideshare.net/slideshow/privilege-escalation-on-highend-servers-due-to-implementation-gaps-in-cpu-hotadd-flow/73217903
[P-18] HPE, “Memory technology evolution: an overview of system memory technologies Technology brief,” HPE Whitepaper, available at https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c01552458
[P-19] HPE, “HP Advanced Memory Protection technologies,” HPE Whitepaper, available at http://service1.pcconnection.com/PDF/AdvMemoryProtection.pdf
[P-20] Daniel Henderson, “POWER8® Processor-Based Systems RAS,” IBM Whitepaper 2016, available at https://www.ibm.com/support/pages/sites/default/files/inline-files/$FILE/POWER8_RAS_whitepaper_POW03133USEN.PDF
[P-21] Galen Hunt, George Letey, Edmund B. Nightingale, “The Seven Properties of Highly Secure Devices,” Microsoft Whitepaper 2017, https://www.microsoft.com/en-us/research/wp-content/uploads/2017/03/SevenPropertiesofHighlySecureDevices.pdf
规范和指南
[S-1] DMTF org, “MCTP Base Specification,” 2016, available at https://www.dmtf.org/standards/pmci
[S-2] DMTF org, “Security Protocol and Data Model Specification,” 2019, available at https://www.dmtf.org/standards/pmci
[S-3] DMTF org, “SPDM over MCTP Binding Specification,” 2019, available at https://www.dmtf.org/standards/pmci
[S-4] DMTF org, “Secured MCTP Messages over MCTP Binding Specification,” 2019, available at https://www.dmtf.org/standards/pmci
[S-5] DMTF org, “Platform Level Data Model (PLDM) for Firmware Update Specification,” 2018, available at https://www.dmtf.org/standards/pmci
[S-6] IETF, “RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3,” 2018, available at https://tools.ietf.org/html/rfc8446
[S-7] IETF, “RFC 6347 – Datagram Transport Layer Security Version 1.2,” 2012, available at https://tools.ietf.org/html/rfc6347
[S-8] USB org, “USB Authentication Specification,” 2019 available at https://www.usb.org/documents
[S-9] PCI-SIG, “PCI Local Bus Specification,” 2004, available at https://pcisig.com/specifications
[S-10] PCI-SIG, “PCI Express Base Specification,” 2019, available at https://pcisig.com/specifications
[S-11] PCI-SIG, “Data Object Exchange (DOE) ECN,” 2019, available at https://pcisig.com/specifications/review-zone
[S-12] PCI-SIG, “Component Measurement and Authentication (CMA) ECN,” 2019, available at https://pcisig.com/specifications/review-zone
[S-13] PCI-SIG, “Integrity and Data Encryption (IDE) ECN,” 2020, available at https://pcisig.com/specifications/review-zone
[S-14] CXL org, “The CXL Specification,” 2019, available at https://www.computeexpresslink.org/
[S-15] Trusted Computing Group, “TCG Guidance for Secure Update of Software and Firmware on Embedded Systems,” 2019, available at https://trustedcomputinggroup.org/
[S-16] Trusted Computing Group, “TCG Runtime Integrity Protections in Mobile Devices,” 2019, available at https://trustedcomputinggroup.org/
[S-17] OCP, “Project Cerberus Architecture Overview Specification,” 2018, available at https://github.com/opencomputeproject/Project_Olympus/blob/master/Project_Cerberus
[S-18] OCP, “Project Cerberus Firmware Update Specification,” 2019, available at https://github.com/opencomputeproject/Project_Olympus/blob/master/Project_Cerberus
[S-19] UEFI Organization, “ACPI Specification,” 2019, available at https://www.uefi.org/
[S-20] AMD, “AMD Architecture Programmer’s Manual,” 2019, available at https://www.amd.com/en/support/tech-docs
[S-21] AMD, “AMD I/O Virtualization Technology,” 2016, available at https://support.amd.com/TechDocs/48882_IOMMU.pdf
[S-22] ARM, “ARM® System Memory Management Unit Architecture Specification,” 2017, available at https://static.docs.arm.com/ihi0070/b/SMMUv3_architecture_specification_IHI0070B.pdf
[S-23] ARM, “I/O Remapping Table,” 2018, available at https://static.docs.arm.com/den0049/d/DEN0049D_IO_Remapping_Table.pdf
[S-24] ARM, “ARM® Generic Interrupt Controller Architecture Specification,” 2017, available at https://static.docs.arm.com/ihi0069/d/IHI0069D_gic_architecture_specification.pdf
[S-25] Intel, “Intel 64 and IA-32 Architecture Software Developer Manuals,” 2019, available at https://software.intel.com/en-us/articles/intel-sdm
[S-26] Intel, “Intel Scalable I/O Virtualization Specification,” 2018, available at https://www.intel.com/content/www/us/en/content-details/671403/intel-scalable-i-o-virtualization-technical-specification.html
[S-27] Intel, “Virtualization Technology for Directed I/O specification,” 2019, available at https://www.intel.com/content/www/us/en/content-details/774206/intel-virtualization-technology-for-directed-i-o-architecture-specification.html
[S-28] Intel, “PCIe Device Security Enhancements Specification,” 2018, available at https://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/pcie-device-security-enhancements.pdf
[S-29] 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
[S-30] Intel, “Multi Processor Specification,” 1997, available at https://pdos.csail.mit.edu/6.828/2018/readings/ia32/MPspec.pdf
网页
[W-1] Microsoft, “Hardware Compatibility Specification for Systems for Windows 10,” https://docs.microsoft.com/en-us/windows-hardware/design/compatibility/systems
[W-2] Microsoft, “Blocking the SBP-2 driver and Thunderbolt controllers to reduce 1394 DMA and Thunderbolt DMA threats to BitLocker,” http://support.microsoft.com/kb/2516445
[W-3] Microsoft, “Kernel DMA Protection for Thunderbolt,” https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dmaprotection-for-thunderbolt
[W-4] Microsoft, “Windows Hardware Error Architecture (WHEA) design guide,” https://docs.microsoft.com/en-us/windows-hardware/drivers/whea/
[W-5] Microsoft, “Component Firmware Update,” https://github.com/Microsoft/CFU
[W-6] Microsoft, “Component Firmware Update Protocol Specification,” https://github.com/microsoft/CFU/blob/master/Documentation/CFU-Protocol/Component%20Firmware%20Update%20Protocol%20Specification.docx
[W-7] Microsoft, “Introducing Component Firmware Update,” 2018, https://blogs.windows.com/windowsdeveloper/2018/10/17/introducing-component-firmwareupdate/
[W-8] EDKII, “SPDM based Device Firmware Security in EDKII,” 2019, https://edk2.groups.io/g/devel/files/Designs/2019/1018/EDKII-Device%20Firmware%20Security%20v2.pdf, https://github.com/jyao1/openspdm
[W-9] Amazon, “AWS Nitro System,” https://aws.amazon.com/ec2/nitro/
[W-10] Nigel Edwards, Theo Koulouris, Michael Krause, “PCIe Component Authentication,” 2019, https://pcisig.com/pcie%C2%AE-component-authentication
[W-11] Intel, “Intel® Virtualization Technology for Directed I/O (VT-d): Enhancing Intel platforms for efficient virtualization of I/O devices,” https://software.intel.com/en-us/articles/intel-virtualization-technology-for-directed-io-vt-denhancing-intel-platforms-for-efficient-virtualization-of-io-devices
[W-12] “Thunderbolt™ 3 and Security on Microsoft Windows® 10 Operating system,” https://thunderbolttechnology.net/security/Thunderbolt%203%20and%20Security.pdf
[W-13] Ulf Frisk, “Attacking UEFI and Linux,” 2017, http://blog.frizk.net/2017/01/attacking-uefi-and-linux.html
[W-14] Ulf Frisk, “DMA attacking over USB-C and Thunderbolt 3,” 2016, http://blog.frizk.net/2016/10/dma-attacking-over-usb-c-and.html
[W-15] Ulf Frisk, “macOS FileVault2 Password Retrieval,” 2016, http://blog.frizk.net/2016/12/filevault-password-retrieval.html
[W-16] “PCILeech,” https://github.com/ufrisk/pcileech
[W-17] Microblaze, https://github.com/Cr4sh/s6_pcie_microblaze
[W-18] “Facedancer,” http://goodfet.sourceforge.net/hardware/facedancer21/