Abstract

可信执行环境（TEE），如 Intel SGX/TDX、AMD SEV-SNP、ARM TrustZone/CCA，已在主流架构中广泛采用。然而，这些 TEE 通常不将 I/O 隔离（例如，防御恶意 DMA 请求）视为一等公民，这可能会降低 I/O 性能。对于 I/O 密集型工作负载，使用 IOMMU 或软件 I/O 等传统方法会使吞吐量至少降低 20%。主要原因是I/O设备与CPU的隔离要求不同。本文提出了一种新颖的 TEE I/O 隔离机制，称为 sIOPMP（可扩展 I/O 物理内存保护），具有三个关键特性。首先，我们设计了一个基于多阶段树的检查器，支持超过 1,000 个硬件区域。其次，我们将设备分为热设备和冷设备，并通过可安装条目支持无限设备。第三，我们提出了一种重新映射机制，用于在动态 I/O 工作负载的热状态和冷状态之间切换设备。评估结果表明，与 TEE 中采用的基于 IOMMU 的机制或软件 I/O 相比，sIOPMP 对于基准测试和实际工作负载仅引入了可以忽略不计的性能开销，并且提高了 20% ∼ 38% 的网络吞吐量。

INTRODUCTION

可信执行环境 (TEE) 代表了当前人们强烈关注的领域，示例包括 Intel SGX/TDX [5, 29]、AMD SEV [6, 49, 71]、Arm TrustZone/CCA [1, 12] 和 RISC- V蓬莱[38]和Keystone[52]。 TEE 旨在为应用程序和虚拟机提供安全的执行环境，保证 CPU 和内存隔离。同时，随着最先进的 TEE 运行分布式 MapReduce [37,69,83]、加密数据库 [54,65,86] 和机密机器学习 [48,56,88]，I/O 要求变得越来越重要应用程序，这在很大程度上依赖于 I/O 性能。迫切的需求是在 TEE 系统中支持直接内存访问 (DMA)，但它可能允许恶意设备访问安全内存 [19,21,36,75]，从而绕过 CPU 侧检查。因此，TEE 必须考虑设备访问内存的隔离，并将安全检查扩展到 SoC 级别。

防御恶意 DMA 请求的常见方法是使用 I/O 内存管理单元 (IOMMU) [16,43,47,81]。 IOMMU为设备提供了虚拟地址空间，设备只能通过虚拟地址访问物理内存。这样，恶意设备就无法访问 IOMMU 限制的任意物理地址。

然而，传统的 IOMMU 并不是纯粹出于安全考虑而设计的——它还支持地址和中断重新映射。因此，由于其固有的缺陷，不适合将整个IOMMU纳入TEE系统的可信计算库（TCB）中。首先，由于使用异步命令队列造成昂贵的 IOTLB 失效，IOMMU 在繁重的工作负载中会遇到性能问题。之前的工作 [59,60,64] 表明 IOTLB 刷新可能会导致 I/O 吞吐量增加 20% ∼ 30% 的开销。其次，IOMMU 仅支持页级隔离，这对于内存缓冲区可以是任意大小的 DMA 场景来说是不够的。在网络堆栈中，有许多子页面数据包很难被IOMMU[61]隔离，需要额外的复制。三、IOMMU要求页表和 I/O 虚拟地址 (IOVA) 的复杂配置，为恶意设备暴露了漏洞。例如，Theodore Markettos 等人。 [58]利用共享数据结构描述符环中的漏洞来绕过 IOMMU 检查。最后，IOMMU设计的可扩展性较差，例如IOVA分配和IOTLB，在多设备和租户的场景中成为瓶颈[51]。由于这些限制，由于性能下降问题和小型 TCB 的必要性，当前的 TEE 不使用（或仅使用）传统的 IOMMU 作为基本 I/O 保护机制。

TEE 更喜欢使用基于区域的 I/O 隔离、内存加密或两者的组合来防御 DMA 攻击。在TrustZone [12]中，所有硬件资源被分为安全世界和正常世界，只有安全世界中的组件才能访问安全硬件资源。这会阻止正常世界中的设备访问安全内存，即使是通过 DMA 请求也是如此。然而，这种基于区域的隔离机制受到内存区域数量（最多16个区域）和设备角色不同的限制。其他 TEE 系统，例如 SEV [49]，使用加密内存来防止恶意 DMA 访问。由于安全存储器中的数据是加密的，因此如果没有加密密钥，设备无法将密文解密为明文。然而，单独使用内存加密（没有完整性树）无法防御重放攻击，重放攻击可以将过时的内存区域回滚到同一地址。一些最先进的TEE同时采用内存加密和I/O隔离，例如TDX[5]、SGX[29]、SEV-SNP[71]和CCA[1]。 SEV-SNP和CCA提出了额外的基于页面的I/O隔离机制：RMP（反向映射表）和GPC（粒度保护检查器），它们是IOMMU或sMMU内部的新组件。然而，它们仍然面临与 IOMMU 相同的问题：异步条目失效、页级隔离和缺乏可扩展性。此外，内存加密还会阻止合法的 DMA 请求，这需要额外的内存复制，从而降低 I/O 性能（例如，bifrost [53] 中引入了 23% 的开销）。

为了解决上述问题，TEE系统进一步提出了TEE-IO规范：SEV-TIO[15]、TDX-TEEIO[45]。 TEE-IO制定了设备认证、PCI-e存根之间的安全数据传输等程序。通过这一增强，它允许受信任的PCI-e控制器访问SoC内部TEE数据的明文，并直接执行DMA请求。尽管 TEE-IO 提出了一种为具有加密内存的 TEE 启用 DMA 功能的方法，但它无法解决与 I/O 隔离相关的性能问题（特别是在动态工作负载中），因为它仍然依赖于现有的 I/O 隔离机制，例如RMP。综上所述，TEE-IO 与本文讨论的 I/O 隔离是正交的，TEE 迫切需要但仍然缺乏一种高效的 I/O 隔离机制。

在深入研究现有的I/O隔离机制后，我们发现它们通常源自CPU端使用的内存隔离机制。例如，现代 TEE 对设备采用与 CPU 中使用的相同的隔离机制（即 GPC 或 RMP）。然而，一个关键的见解是 DMA 的内存隔离要求与 CPU 端的内存隔离要求有很大不同。在DMA场景下，设备访问内存必须是连续的，或者限制在几个连续的范围内（分散-聚集模式）。因此，分页对于 I/O 隔离来说效率低下，因为它缺乏对子页面或超级页面区域的抽象。然而，基于区域的隔离也存在一些固有的挑战：（1）很难支持大量的内存区域，因为当前强大的DMA控制器可以支持512或1024个分散缓冲区[41, 44]。 (2)在考虑设备虚拟化和插件设备时，尚不清楚如何支持无限数量的设备。

本文提出了一种高性能、可扩展的I/O隔离机制，称为sIOPMP（可扩展IOPMP）。 sIOPMP 使用新颖的 I/O 特定机制来解决以下挑战。首先，在不影响设备链接速率的情​​况下检查超过 1000 个内存区域是很困难的。为了解决这个问题，我们观察到当前的设备更关心 I/O 吞吐量而不是延迟（即，即使在 CXL [2] 下，几个周期的增加也可以忽略 [79]），因此我们设计了一个多阶段树基于的检查器支持 1000 多个硬件区域，且延迟开销可以忽略不计。其次，仅用有限的 SoC 资源来支持无限的设备也具有挑战性。我们观察到，虽然整个系统中可能有很多设备（虚拟功能和插件设备），但同时运行的热点设备却很少，这通常受到CPU内核和总线系统容量的限制。基于这一观察，我们提出了可安装区域机制，可以支持无限数量的冷设备并实现热设备的线速性能。第三，假设设备的工作负载是不可变的是不切实际的，因此设备状态可能会在不同时间发生变化。为了支持动态工作负载，我们观察到内容可寻址内存（CAM）可以通过内容搜索并在一个周期内返回其地址。因此，我们设计了一种基于CAM的零成本重映射机制，根据不同的I/O工作负载动态切换设备冷热状态。

我们在chipyard实现了sIOPMP的原型[13]，它是一个定制的RISC-V SoC生成器。由于 RISC-V SoC 中没有现有的 IOPMP 实现，因此我们首先将 PMP 实现移植到 IOPMP 作为基准。然后，我们将 IOPMP 实现扩展到 sIOPMP 并在实际系统中对其进行评估。值得注意的是，sIOPMP 设计与 RISC-V 的耦合并不紧密，并且可以轻松移植到其他 ISA。我们仅选择 RISC-V 作为我们的平台因为它是开源的。我们还扩展了蓬莱飞地[38]中的安全监视器以支持sIOPMP配置，并为上层软件提供基于所有权的接口。评估结果表明，sIOPMP可以在不影响时序约束（时钟频率）的情况下支持超过1000个硬件区域，并且在微基准测试和实际应用中都不会牺牲I/O吞吐量。与最先进的 I/O 隔离机制（例如 IOMMU、SWIO、TEE-IO）相比，sIOPMP 提高了 20% 以上的网络带宽（iperf [17]）。至于硬件成本，sIOPMP 仅消耗额外 1.9% 的 LUT 和 FF，支持超过 1024 个条目。

BACKGROUND and MOTIVATION

DMA Attack

直接内存访问 (DMA) [23,73,90] 的提出是为了通过使设备能够直接访问物理内存而不涉及 CPU 来提高 I/O 性能。然而，DMA技术也引入了来自设备端的另一个攻击面。恶意设备可以利用 DMA 支持的协议（例如 PCI-e、thunderbolt）来窃取系统内存中存储的机密（例如密码、磁盘加密密钥）[19、21、25、34、36、75]。此外，随着当前 TEE 系统的发展，DMA 攻击变得更加严重，因为设备可能突破安全 CPU 内核建立的隔离边界。

IOPMP

输入/输出设备物理内存保护单元 (IOPMP) [4] 旨在调节总线主控发出的访问并防御恶意 DMA 攻击。在 IOPMP 设计中，总线上具有相同访问权限的每个主控器或总线主控器组都有一个称为源 ID (SID) 的唯一标识符。特别是，如果主设备具有多个具有不同权限的通道或可以在不同的特权模式（例如处理器）下运行，则每个通道或特权模式应该有自己的SID。

除了 SID 之外，IOPMP 还使用内存域 (MD) 来组织每个设备可以访问的物理内存。一个内存域包含多个连续的内存区域，每个内存区域可以有不同的访问权限。例如，NIC设备可以与存储器域关联，该存储器域包含三个存储器区域：RX区域、TX区域和控制寄存器区域。 IOPMP 条目数组（图 1 中的右半部分）是 IOPMP 最基本的结构。每个 IOPMP 条目都从零开始索引，并定义检查事务时的规则。该条目包括内存区域和该区域的读/写权限。每个IOPMP条目恰好属于一个内存域，并且一个内存域可以有多个IOPMP条目。与 MD 关联的任何 SID 也与属于该内存域的所有 IOPMP 条目关联。 IOPMP 条目具有静态优先级，其中编号最小的条目具有最高优先级。当发出事务时，IOPMP 按照 IOPMP 条目的优先级顺序检查事务。如果事务与 IOPMP 条目匹配，IOPMP 将检查该 IOPMP 条目内的读/写权限。例如，假设内存域 0 有两个 IOPMP 条目：条目 0 和条目 1。条目 0 对于内存地址 A 具有 No_PERMISSION，而条目 1 对于内存地址 A 具有 READ_PERMISSION。根据优先级，与内存域0关联的设备最终缺乏对地址A的访问权限。

IOPMP 有多个配置寄存器表来控制其行为，如图 1 所示。SRC2MD 表（图 1 的左上角）标识与给定 SID 关联的内存域。该表有一个寄存器SRCs MD，它有64位空间和两个字段：SRCs MD.L和SRCs MD.MD。 SRCs MD.L 是该寄存器的粘性锁，并且SRCs MD.MD 是位图字段，其显示存储器域m（位图中的索引m）是否与该SID关联。 MDCFG 表（图 1 左下角）定义了 IOPMP 条目和内存域之间的关系。该表具有配置寄存器阵列，其中寄存器MDmCFG用于存储器域m。在MDmCFG寄存器中，MDmCFG.T指示属于存储器域m的IOPMP条目的最后索引。更具体地，如果 MDm-1CFG.T ≤ j < MDmCFG.T ，其中 m > 0，则具有索引 j 的 IOPMP 条目属于 MD m。存储器域 0 拥有索引 j < MD0CFG.T 的 IOPMP 条目。

总而言之，IOPMP 设计使用带有配置表的优先级区域来将内存域与设备隔离。然而，它仍然面临着硬件区域寄存器有限和优先级检查开销等挑战。

Related Work: Other I/O Isolation Mechanisms

我们在表 1 中总结了当前 TEE 系统的 I/O 保护机制。 IOMMU-strict 和 IOMMU-defer [57, 64] 是 Linux 内核（4.7 版本之后）中使用的 IOMMU 的两种配置。 IOMMU-strict 会使每个取消映射操作的 IOTLB 失效，而 IOMMU-defer 会延迟 IOTLB 失效并批量取消映射操作。然而，IOMMU-defer 牺牲了安全性和性能，并为恶意设备访问未映射的页面创建了潜在的攻击窗口。为平衡安全和性能，最先进的解决方案 [59, 60] 使用设备的固定映射来减少 IOMMU 取消映射的开销，但失去了灵活性。除了性能开销之外，基于 IOMMU 的设计还增加了 TCB 大小，因为它处理 I/O 地址和中断重新映射。因此，当前的TEE系统[1,5,12,29,38,71]没有使用传统的IOMMU作为I/O隔离的安全模块。相反，他们引入了 RMP 和 GPC 等附加组件，专门用于设备访问检查。

一些 TEE 系统 [4、12、20、24、30、39、70] 对设备使用基于区域的内存隔离。然而，这种方法存在可扩展性问题——孤立的内存区域和设备角色的数量有限。例如，TrustZone 仅支持 16 个内存区域，具有两种设备角色：安全和正常。 IOPMP仅支持设备的64个源ID，当考虑设备虚拟化时，这个限制变得更加严重。 SEV 和其他人 [76, 80] 依靠内存加密来防止恶意 DMA 访问。然而，内存加密会导致性能和硬件资源开销[37,40,42,67,68,77,78]，并且无法防止基于DMA的重放攻击（即，没有完整性树）。因此，当前的TEE系统同时采用内存加密和额外的I/O隔离来防御恶意DMA攻击。例如，CCA需要在每个主节点上安装GPC（粒度保护检查）模块，以将设备的物理地址转换为世界标签（Normal、Secure、Realm和Root）。 SEV-SNP需要IOMMU中的RMP（反向映射表）来验证页面映射及其所有权的完整性。然而，这些基于页面的检查仍然面临着与 IOMMU 类似的挑战，例如 TLB 失效的高开销、较差的可扩展性以及缺乏子页面隔离。此外，由于隔离的设备内存仍然是加密的，当前无法被设备访问，因此需要额外的步骤，例如将设备的数据复制到反弹缓冲区，并利用虚拟机管理程序来调解 I/O 操作。

为了使可信设备能够直接访问 TEE 内部的内存，未来的 TEE 系统（例如，SEV-TIO [15] 和 TDX-TEEIO [45]）已扩展 TCB 以包含 PCI-e 控制器，并通过经过身份验证的方式建立可信 I/O使用 PCI TEE 设备接口安全协议 (TDISP) 的设备。然而TEE-IO仅仅解决了TEE内部如何支持合法设备访问的问题。对于非法设备操作（即DMA重放攻击），它仍然依赖于前面提到的I/O隔离方法（例如RMP和GPC），这意味着在频繁DMA映射/取消映射的动态I/O工作负载期间效率低下操作（例如网络）。综上所述，TEE-IO 与 I/O 隔离是正交的，我们在未来的 TEE 设计中需要同时考虑两者。

我们提出了 sIOPMP，这是一种针对 TEE 系统的高效且可扩展的 I/O 保护机制。 sIOPMP 通过支持无限的设备和超过 1000 个优先级条目（与 DMA 控制器中的分散收集缓冲区的数量相匹配）克服了基于区域的隔离的限制，并且在轻负载和重负载中引入的性能开销都可以忽略不计。此外，sIOPMP 还通过仅包含可信硬件和固件组件来确保较小的 TCB 大小，并提供基于所有权的管理接口。

DESIGN OVERVIEW

Design Goals

Performance

我们的 I/O 保护机制的性能应该与本机 I/O 性能紧密匹配。具体来说，我们的设计不应牺牲设备的链路速率，即使在繁重的工作负载下，也不应为设备吞吐量引入可忽略不计的开销。

Security

我们的设计应该保护安全内存免受恶意设备发出任意 DMA 请求的影响。此外，由于可信计算库（TCB）规模庞大，其中存在大量未经身份验证的代码。由于操作系统位于富执行环境 (REE) 一侧，我们不能相信操作系统能够正确配置 DMA。

Scalability

我们的设计应该足够灵活，以支持无限数量的设备，并提供子页面内存隔离。考虑到可以提供大量虚拟功能（VF）的设备的虚拟化扩展，硬编码最大设备数量是不可接受的。此外，在考虑 DMA 请求中的分散-聚集模式时，我们的设计应该提供足够的硬件区域。

Threat Model

我们系统的 TCB 仅包含 SoC 模块（即 CPU 内核、sIOPMP 扩展等）和轻量级固件：安全监视器。我们假设任何片外设备（例如 GPU、加速器、smartNIC）都可能受到损害，并且我们不信任 REE 中运行的任何软件。

Privilege software attacks

我们不信任 REE 端不可信操作系统中的任何代码。不受信任的操作系统可能会触发任意 DMA 请求来访问安全内存。更糟糕的是，即使内核不是恶意的，操作系统仍然存在因大量可能未正确验证的设备驱动程序中的漏洞而受到损害的风险[31,32,62]。

Malicious device attacks

设备可能是恶意的并发出任意 DMA 请求。一些设备有自己的集成 DMA 控制器和更多的可编程功能 [7-11] 供其所有者使用。此外，CXL [3] 等最先进的互连协议允许设备在不通知主机 CPU 的情况下访问内存池中的数据。因此，恶意设备可以窃取或篡改系统内存或 TEE 内存中的秘密，从而破坏内存隔离假设。

我们的系统重点关注TEE的DMA保护，并使用现有机制[38,66,72]来保护内存隔离，安全中断等。但是，我们不考虑对DRAM的物理攻击，例如冻结内存，内存窥探[14, 95]，内存拼接 [71]，以及 SoC 内部的旁道攻击 [55, 84, 92, 93]。这些攻击与我们的设计正交。

DETAILED DESIGN

我们提出了 sIOPMP，这是一种用于 TEE 系统的新型 I/O 保护机制，可支持无限的设备而不牺牲 I/O 带宽。 sIOPMP解决了先前工作中的两个关键问题：首先，它采用基于多级树的IOPMP检查器（MT检查器）来支持超过1000个优先级区域，而不会降低时钟频率。其次，它利用具有可安装 IOPMP 的扩展 IOPMP 表来容纳整个系统中的无限设备。此外，sIOPMP还采用零成本重新映射机制，在动态I/O工作负载下切换设备状态的热和冷。

Multi-stage-Tree-based IOPMP

Challenges of nowadays IOPMP

图 2 展示了 IOPMP 硬件模块的系统架构 [4]。 IOPMP 条目表存储优先级内存区域，用于对每个 DMA 请求执行权限检查，从低优先级到高优先级（第 2.2 节）。优先级区域比非优先级区域提供更大的灵活性[46, 72]，因为它们避免了不同区域之间的权限冲突，并使用更少的区域寄存器来隔离更多的内存范围。然而，当处理大量优先级区域时，直接的方法（例如线性检查）可能会降低时钟频率（因为优先级区域检查是组合逻辑电路），从而减少 I/O 带宽。

为了解决这个问题，sIOPMP提出了基于多阶段树的IOPMP检查器（MT检查器）：IOPMP管道和基于树的arbitration。

IOPMP pipeline

与 CPU 内核中的 PMP 不同，IOPMP 检查通常对带宽敏感而不是对延迟敏感的设备的 DMA 请求。因此，CPU侧安全检查时忽略的流水线设计可以应用在设备侧。 IOPMP 检查器将内存地址、请求的数据和 IOPMP 条目作为输入，如图 3(a) 所示。掩码过滤 IOPMP 条目以选择与当前 SID/DeviceID 绑定的条目。然后IOPMP检查器验证不同流水线阶段中的所有IOPMP条目并将中间结果存储在寄存器中。所有管道检查通过后，IOPMP 检查器生成最终的决定该内存访问是否被授权。设备侧的管道设计也提出了新的挑战。例如，如果我们想要阻止 DMA 事务（参见第 5.3 节），总线和 IOPMP 检查器之间的块状态可能不一致（例如，尽管我们阻止总线中的 DMA 事务，但可能仍然存在现有的 DMA）由于多级管道，IOPMP 检查器中的事务）。因此，我们添加一个监视器来维护总线和 IOPMP 检查器之间块状态的一致视图。

Tree-based arbitration

为了根据优先级区域检查权限，当前的设计（例如 Rocket 和 Boom）使用线性逻辑从低优先级到高优先级检查权限，如图 3 (b) 的顶部所示。然而，当存在大量优先级区域时，由于检查延迟较高，该方法效率不高。此外，由于其门逻辑电平数较长，还需要更多的缓冲器来维持压降（大于阈值）并满足时序要求，因此需要更多的LUT。在MT检查器中，我们提出了一种新颖的检查方案：基于树的arbitration，以将检查延迟减少到log(N)级别，如图3(b)的底部所示。通过基于树的arbitration，IOPMP 检查器根据优先级逐对比较权限并生成中间结果。然后，这些中间结果在树结构电路中被缩减。与其他可能在后端使用 EDA 工具优化检查电路的工作不同，基于树的仲裁是在 RTL 级别实现的，具有更多信息和人为参与的优化。例如，我们可以采用不同的树结构来满足时序（二叉树）和区域（N叉树）的不同要求。

事实上，基于多级树的IOPMP检查器结合了IOPMP管道和基于树的arbitration电路的优点，以加速IOPMP检查过程。流水线设计面临着检查所需的周期数和系统时钟频率之间的权衡。同时，基于树的arbitration电路也有条目数限制。 MT 检查器结合了两种设计，利用基于树的arbitration作为 IOPMP 管道的单元。因此，它可以在几个 IOPMP 管道中检查大量 IOPMP 条目。

Summary

我们分析了IOPMP检查器为何成为系统瓶颈，并通过两项关键技术对其进行了优化。流水线设计将大型IOPMP检查器分成较小的检查器，提高了设备​​的链路速率。同时，基于树的仲裁可以并行验证 IOPMP 条目，每个周期处理更多条目。通过结合这些技术，MT 检查器在不影响时钟频率和带宽的情况下扩展了 IOPMP 条目的总数。

Mountable IOPMP

尽管MT检查器设计可以最小化IOPMP条目的检查开销，但是由于硬件资源的限制，IOPMP条目的总数不能无限地增加。而且支持的设备数量也有限，不适合虚拟功能和插件设备。在考虑虚拟功能时，一台物理设备可以提供多个虚拟功能接口，因此无法确定最大使用设备数量。为了解决这个问题，我们提出了具有可安装 IOPMP 条目的扩展 IOPMP 表。这种设计来自于我们的观察，虽然无法确定设备总数，但系统中同时热点设备的数量始终是有限的。因此，我们可以为这些热点设备提供快速路径，但不限制设备总数。

图 4 显示了可安装 IOPMP 的设计。与IOPMP条目表或SRC2MD表不同，扩展IOPMP表保留在受保护的内存中，不能被未经授权的软件或设备访问（在RISC-V架构中，扩展IOPMP表可以受到PMP的保护[72]）。因此，在物理内存足够的情况下，扩展IOPMP表的大小没有硬件限制。

可安装的 IOPMP 条目包含扩展 SID/DeviceID (eSID)、关联内存域的索引以及其他 IOPMP 条目。当设备 ID 不在 SRC2MD 表中时使用这些，并且 sIOPMP 将启动称为冷设备切换的过程。在此过程中，IOPMP 检查器会生成 SID 缺失中断。安全监视器处理此中断，获取扩展 IOPMP 表中的可安装 IOPMP 条目，并将 eSID、内存域和 IOPMP 条目加载到实际硬件条目。此外，冷设备始终与最后一个内存域（MD62）配对，并且在冷设备切换期间应刷新该内存域中的IOPMP条目。由于冷设备很少使用，因此始终将其 IOPMP 条目保留在硬件中是一种浪费。

一旦 eSID 加载到 SRC2MD 表中，sIOPMP 就可以继续对该冷设备的 DMA 请求进行进一步检查。它首先将SRC2MD表中的eSID与DMA数据包中保留的ID进行比较。如果存在匹配，IOPMP 检查器将屏蔽属于该冷设备的 IOPMP 条目（最后一个内存域以及与该设备关联的其他内存域中的 IOPMP 条目）。最后，根据这些屏蔽的 IOPMP 条目检查内存访问权限。可安装 IOPMP 仅在第一个 DMA 请求中为冷设备引入额外的“安装”开销，并暂时为其提供 I/O 检查的快速路径。因此，如果只有一台冷设备同时运行，则该安装机制是理想的。

Summary

可安装的 IOPMP 解决了设备的 IOPMP 条目和 SID 数量的硬件限制。与原来的IOPMP设计不同，sIOPMP同时考虑了热设备和冷设备，并针对它们采取了不同的策略。可安装的IOPMP适用于冷设备，同时支持无限数量的设备。相比之下，最初的IOPMP设计错误地认为所有设备都是热设备，导致设备数量受到限制。

IOPMP Remapping

可安装IOPMP能够在整个系统中支持无限数量的固定热点设备。然而，由于热设备在不同的工作负载和时间可能会发生变化，sIOPMP提出了一种称为IOPMP重新映射的新机制，它可以在sIOPMP中的设备在热状态和冷状态之间切换。

默认情况下，sIOPMP 中定义的热设备仅与固定 SID 关联（​​例如，在我们的实现中为 0 到 62），任何 SID 超出这些固定值的设备都不能被视为热设备。这种限制在云计算中更加严重，因为热设备通常是可变的并且与活动虚拟机绑定。如果活动虚拟机使用的设备的SID大于最大SID，则sIOPMP仅将其视为性能下降的冷设备。为了解决这个限制，我们引入了 IOPMP 重新映射附加表称为DeviceID2SID，如图5所示。DeviceID2SID记录了实际设备ID和sIOPMP中使用的SID之间的映射。如果设备从冷状态变为热状态，我们可以重置DeviceID2SID表中​​的映射并为其分配新的热SID。

为了确保快速有效的 SID 查找过程（在关键路径中），我们利用观察结果，即尽管 deviceID 可能具有很大的跨度，但 SID 的数量是有限的（在我们的实现中<63）。因此，内容可寻址存储器 (CAM) 非常适合 DeviceID2SID 表。 CAM 将输入搜索数据与存储数据表进行比较，并返回匹配数据的地址。在DeviceID2SID表中​​，SID的数量是固定的。因此，SID被视为地址，设备ID被视为内容，可以是任意值。当收到DMA请求时，会在DeviceID2SID表中​​查找设备ID。如果匹配，检索SID将用于索引下面的SRC2MD表。否则，我们将此设备 ID 视为 eSID，并将其与 eSID 寄存器中的值进行匹配。目前，CAM 只有 63 个条目（即最大 SID 为 62），这不会引入任何额外的 I/O 检查周期。

此外，sIOPMP还采用不同的冷热设备切换策略。一般来说，主要有两种方法：隐式切换和显式切换。在显式切换中，预言机知道哪个设备处于热状态，哪个设备不是。因此，它可以显式设置设备 ID 到 SID 的映射。对于隐式切换，我们在DeviceID2SID表中​​实现了一个时钟算法（LRU近似算法），并带有一个额外的LRU位。当安全监视器频繁地将一个设备ID加载到eSID寄存器时，该设备应被视为热设备。安全监视器将根据LRU位驱逐DeviceID2SID表中​​的不活动设备，并为该设备映射一个热SID。因此，冷热设备切换是根据设备利用率隐式进行的。由于这些不同的策略，sIOPMP 非常适合动态 I/O 工作负载，并且可以自适应地调整设备的热和冷状态。

Summary

IOPMP重映射提供了在sIOPMP中在冷状态和热状态之间动态切换设备的能力。如果没有IOPMP重映射机制，sIOPMP中的设备状态是固定的，并且可能与真实设备状态不匹配。此外，IOPMP 重新映射利用了这样的观察结果：尽管设备 ID 可以很大，但最大 SID 是固定的。因此，它采用内容可寻址存储器（CAM）来存储DeviceID2SID表，这不会引入任何额外的SID搜索周期。

IMPLEMENTATION

Microarchitecture

sIOPMP 设计的微架构如图 6 所示，由两个主要组件组成：MT 检查器和几个配置表。 MT检查器作为位于前端总线之前的主节点。它的主要作用是拦截来自主设备的所有 DMA 请求，并根据 IOPMP 条目中指定的规则执行访问权限检查。另一方面，配置表充当外围总线内的从节点。有几个表，包括IOPMP Entry Table、SRC2MD Table、MDCFG Table以及SID2Addr和DeviceID2SID等辅助表。此外，sIOPMP模块也连接到中断总线。它允许 sIOPMP 在各种情况下触发中断并通知 CPU 内核，包括 IOPMP 违规或其他需要 CPU 干预的情况。

sIOPMP Violation

sIOPMP 使用两种方法，即数据包屏蔽和总线错误处理，来处理 IOPMP 违规，如图 7 所示。数据包屏蔽使用写选通 [28] 和读取清除信号来保护由恶意设备发送或发送到恶意设备的消息。如果数据包地址超出 IOPMP 检查器检查的允许范围，写选通信号将屏蔽请求数据包中的数据，而读清除信号会将响应数据包中的数据设置为零。写选通机制已经广泛应用于 TileLink [74] 和 AXI [89] 等现有总线协议中。然而，这些协议缺乏读取清除机制，因此当发生 sIOPMP 违规时，IOPMP 检查器必须清除响应数据包中的数据。此外，为了检查响应数据包，IOPMP 检查器使用一个名为 SID2Addr 的新表来记录地址和 SID 关系。至于总线错误处理，它需要一个额外的虚拟节点，当它检测到 IOPMP 违规时立即生成总线错误消息。

与这两种方法相比，数据包屏蔽需要额外的表来将SID转换为地址，这会花费额外的周期。另一方面，总线错误处理需要额外的虚拟节点，这可能会加剧总线流量。两种方法都需要记录相关的错误信息，例如地址、源ID和权限类型，并向安全监视器触发IOPMP违规中断。

Atomic Primitives for sIOPMP

sIOPMP 可能会遭受我们所说的安全漏洞：条目不一致和设备不一致。首先，图8说明了修改IOPMP条目时IOPMP状态下可能出现条目不一致的情况。这种不一致会创建一个允许攻击者访问旧内存区域和新内存区域的攻击窗口，从而引入漏洞。为了缓解这个问题，我们提出了 SID 块位图，它可以有效地阻止来自特定设备的 DMA 请求，以确保 IOPMP 条目的一致性。其次，冷设备切换时会出现设备不一致的情况，冷设备需要将其SID设置到eSID寄存器中，并将可挂载的IOPMP条目加载到硬件条目中。如果没有原子性保证，冷设备可能会无意中访问。在此过程中使用前一个设备。为了克服这个问题，我们阻止对冷设备的任何 DMA 请求，直到所有 sIOPMP 修改完成。值得注意的是，这两个原语都采用 per-SID 阻塞，这意味着它们不会影响其他设备的 I/O 性能。

Software Implementation

我们实现中的 sIOPMP 安全监控器是基于 Penglai [38] 构建的，Penglai 是一个专为 RISC-V 架构设计的 TEE 系统。最初，蓬莱TEE系统由于缺乏硬件支持，并没有考虑DMA保护。我们在蓬莱扩展了安全监控器来配置sIOPMP模块并为TEE提供DMA保护。

为了安全地管理每个 TEE 的硬件资源，我们采用基于功能的抽象。每个能力控制特定的硬件资源，并且只有所有者才有权操作相关的硬件。能力有两个基本操作：派生和转移。所有者可以从现有功能中派生出新功能，但权限会减少或范围会更小。例如，存储器能力可以从现有的存储器能力导出，但具有较窄的存储器范围或具有受限的特权。至于能力转移，所有者可以将所有权或副本（即仅读取权限）发送给另一个实体。

在系统启动时，所有功能最初都由安全监视器拥有。安全监视器可以选择性地将这些能力的所有权转移给引导系统。当用户打算创建 TEE 时，它会利用基于所有权的接口（例如 Create_T EE()）将设备和内存的所有权转移给 TEE。如图 9 所示。此后，TEE 可以调用 Device_map() 来映射特定设备的内存区域。使用基于所有权的接口，安全监视器可以轻松验证 TEE 的设备映射操作。

为了提高安全监控器的模块化程度，我们将功能分为两部分：硬件控制器和能力层。硬件相关的控制器包括用于中断隔离的中断控制器、sIOPMP 控制器用于设备隔离，PMP [72]控制器用于内存隔离。而能力层将所有硬件资源作为能力进行管理。只有特定功能的所有者才被授予访问相应硬件资源的权限。设备管理器和内存管理器为每个设备和内存区域保留所有权链，TEE 管理器保留功能到硬件的映射。

EVALUATION

Experimental Setup

我们在chipyard [13]中实现了sIOPMP，这是一个定制的RISC-V SoC生成器，设计用于评估全系统硬件。利用chipyard配置，我们可以通过选择不同的CPU内核和器件来方便地定制RISC-V SoC。表 2 显示了chipyard 平台中 sIOPMP 的总体配置。我们采用两种类型的CPU内核，Rocket [18]和Boom [22]，以及IceNet [26]、NVDLA [63]和DMA设备[27]等集成设备。我们还探索了 sIOPMP 的不同配置，包括其位置、管道数量、IOPMP 条目数量以及不同的 sIOPMP 违规机制。为了评估具有 sIOPMP 的完整系统设计的性能，我们在两个平台中模拟 sIOPMP：用于微基准测试的 Verilator [85] 和用于应用程序基准测试的 FireSim [50]。

IOPMP

由于 RISC-V SoC 中没有现有的 IOPMP 实现，因此我们从 Boom 和 Rocket 内核移植 PMP [72] 检查器作为基线，该检查器必须检查一个周期内序列化的所有 IOPMP 条目。

IOMMU

IOMMU 是保护内核免受恶意 DMA 侵害的常用方法。我们在真实的 Intel 服务器（Intel Xeon Gold 5317 CPU）中评估 IOMMU 的 I/O 性能，因为 RISC-V 中没有成熟的 IOMMU 实现。

SWIO

当前的机密虚拟机（如 SEV-SNP）利用反弹缓冲区 [94] 在设备和 TEE 之间传输机密数据。

sIOPMP/sIOPMP+IOMMU

我们的解决方案是一个增强的 IOPMP 模块，具有 MT 检查器、可安装的 IOPMP 和 IOPMP 重新映射。为了更好地比较或与其他方法一起工作，我们在 RISC-V 中实现了硬件原型，并在 X86 中实现了具有额外条目修改/检查成本的软件实现平台。 sIOPMP+IOMMU 表示系统同时采用IOMMU 和sIOPMP。

Microbenchmarks

Clock frequency

我们首先评估具有各种配置的 sIOPMP 的时钟频率，如图 10 所示。IOPMP 表示没有任何优化的基线设计，npipe 表示仅使用 IOPMP 检查器的管道设计，而 npipe-tree 结合了利用管道和树的 MT 检查器。为基础的仲裁。我们增加了IOPMP条目的数量，并对不同的IOPMP检查器进行时钟频率分析。我们的 FPGA 平台上可实现的最大时钟频率为 60MHz（带 NIC）。

在基线IOPMP设计中，时钟频率只能维持在60MHz至128条目，并且无法通过1024条目的时钟频率分析。如果我们只对IOPMP检查器采用流水线设计，IOPMP条目的数量将会增加，但与流水线阶段成正比。例如，2流水线IOPMP检查器只能维持256个条目的时钟频率，并且在1024个条目下仅实现10MHz时钟频率。然而，通过将其与基于树的仲裁结合使用，时钟频率可以在最多 512 个条目的情况下保持在 60MHz，并且当条目数达到 1024 时，时钟频率只会略有下降。如果我们使用 3 流水线和基于树的 IOPMP检查器，时钟频率可以维持超过1024个条目。

Pipeline latency

当我们在 MT 检查器中采用管道设计时，它可能会影响 DMA 事务延迟。我们创建了一个最坏的情况，其中 DMA 主设备触发突发 [90] 请求，而没有任何未完成的 [74] 或无序行为，并且设备立即响应 DMA 请求。在这种场景下，每个突发请求由8个节拍组成，每个节拍可以传输8字节的数据。此外，所有节拍不能交替或以无序的方式发出。我们还使用各种配置来评估 sIOPMP：不同的管道级别和 sIOPMP 违规机制。我们使用无管道、2 管道和 3 管道 MT 检查器，并通过数据包屏蔽或总线错误处理来处理 sIOPMP 违规（详细信息请参阅第 5.2 节）。

图 11 显示了不同配置中的 DMA 突发延迟。在此测试中，DMA 主设备触发 64 个连续的突发读/写请求，我们测量第一个请求和最后一个响应之间的延迟。对于 DMA 读取延迟，基线（无管道）64 个请求需要 1,510 个周期。具有总线错误处理功能的 2 管道 MT 检查器需要 1,575 个周期，因为它为每个请求增加一个额外的周期。具有数据包屏蔽功能的 2 管道 MT 检查器需要 1,634 个周期，因为它会插入发送和接收事务。对于 DMA 写入延迟，可以提前验证写入请求，因此总延迟低于 DMA 读取的延迟。基线需要 1,081 个周期，2 管道 MT 检查器分别需要 1,175 个周期和 1,189 个周期来进行总线错误处理和数据包屏蔽。除了正常的 DMA 请求之外，我们还测量了 sIOPMP 违规的错误检测延迟（图 11 中的右侧部分）。对于总线错误处理，一旦 IOPMP 检查器检测到非法请求，虚拟节点就可以生成 IOPMP 错误消息并停止突发请求。然而，对于数据包屏蔽，IOPMP检查器仅屏蔽数据包中的数据，设备节点必须在突发完成后自行处理这些屏蔽的数据包。

sIOPMP bandwidth

与延迟相比，我们更关心 MT 检查器对 DMA 带宽的影响。在此测试用例中，我们创建两个虚拟 DMA 节点以启用突出的 [74] 或无序行为并使总线带宽饱和。我们评估不同 IOPMP 配置和场景下的 DMA 带宽，如图 12 所示。y 轴表示每个周期传输的数据大小（每个节拍可以传输 8 个字节的数据，每个突发包含 8 个节拍）。在Read-Read场景下，两个DMA节点均触发64突发读。来自一个节点的突发请求可以与来自另一节点的突发请求进行管道传输。因此，采用 2 管道或 3 管道 MT 检查器时，仅存在可以忽略不计的开销（无管道为 5.18 字节/周期，2 管道为 5.08 字节/周期），并且当考虑更多时，可以进一步减少该开销。系统中的 DMA 节点。在写-写和读-写场景中，流水线设计不会给 DMA 吞吐量带来额外的开销，因为写请求只需要一个时钟响应，可以轻松地与其他请求进行流水线处理。总之，流水线设计不会牺牲 DMA 带宽，因为 DMA 突发请求可以以未完成和无序的行为进行流水线处理。

sIOPMP modification latency

与 IOMMU 或其他使用异步命令队列使 IOTLB 失效（延迟高达毫秒）的基于页面的机制相比，IOPMP 可以通过 MMIO 接口进行配置，更加高效和确定性。图 13 显示了不同数量的 IOPMP 条目的修改成本。如第 5.3 节中所述，在修改期间，我们需要阻止来自该设备的 DMA 请求，以确保内存视图的一致性。在我们的平台上，阻塞机制增加了 35 个 CPU 周期，每个 IOPMP 条目修改只需要 14 个 CPU 周期，这比带有 IOTLB 失效的 DMA 取消映射要快得多。此外，当考虑多个条目修改时，总成本仍然较低且具有确定性（例如，64 个 IOPMP 条目的 CPU 周期少于 1000 个）。

Hardware resource

我们还评估了具有不同数量 IOPMP 条目的 sIOPMP 的硬件资源消耗。图14显示了sIOPMP模块所需的额外LUT和FF，而LUT-tree和FF-tree意味着使用基于树的仲裁来优化资源成本。对于没有基于树的仲裁的 512 个条目的 sIOPMP，它需要额外的 17.3% 的 LUT 和 1.8% 的 FF，因为后端 EDA 工具将使用大量的 LUT 作为缓冲区达到时序和电压要求。而基于树的仲裁只需要额外1.21%的LUT和FF，这使得LUT的资源成本降低了93%。

Application Benchmarks

为了评估 sIOPMP 在真实 TEE 系统上的性能，我们扩展了蓬莱安全监视器以支持 sIOPMP。安全监控器可以提供多个隔离域，每个域都可以运行整个Linux内核并控制自己的设备。通过利用 sIOPMP，我们可以保护每个 TEE 的内存域免受未经授权的设备访问。此外，由于IOPMP条目具有优先级并且可以通过MMIO接口访问，因此我们可以将几个低优先级的sIOPMP条目委托给S模式（系统模式）。这允许内核直接利用 sIOPMP 进行细粒度和动态设备隔离（例如，在 DMA_unmap 中使用），但受 M 模式中配置的高优先级 sIOPMP 条目的调节。 sIOPMP可以与IOMMU一起工作。在此设置中，IOMMU 仅负责 I/O 地址映射，并将安全保证卸载给 sIOPMP。

Network bandwidth

我们使用 iperf [17] 基准测试测量最大 TCP 带宽，并将 sIOPMP 与最先进的技术进行比较：IOMMU、SWIO（用于 SEV-SNP）以及 sIOPMP 和 IOMMU 的混合系统。 IOMMU 和 SEV-SNP 的设置环境与之前的工作[53, 60]类似（即 Intel Xeon Gold 5317 CPU、AMD EPYC 7T83、100Gbps NIC）。 IOMMU在linux内核中有两种配置，延迟模式和严格模式。延迟模式会批量处理 DMA_unmap 操作并延迟 IOTLB 刷新操作，这会暴露恶意设备的攻击窗口。尽管有几个工作试图解决这个问题（例如，shadow buffer [59] 和 DAMN [60]），但它们是与 Linux 内核共同设计的，并且具有较大的 TCB。像 SEV-SNP [71] 这样的 TEE 系统需要通过虚拟机管理程序干预（SWIO）额外复制到反弹缓冲区 [94]。对于sIOPMP，我们实现了硬件原型和软件实现，其中硬件原型在FireSim平台上运行，软件实现在可以与IOMMU配合工作的Intel机器上进行模拟。 sIOPMP的软件实现支持全部功能并增加了额外的IOPMP条目修改/检查成本。根据§6.2所示的结果。我们使用两种配置评估 sIOPMP 的性能：无管道和 2 管道。

图 15 显示了与没有任何 I/O 保护机制的基准系统相比，不同 I/O 保护机制下的网络带宽下降情况。与没有任何 I/O 保护的基线相比，sIOPMP 和 sIOPMP-2pipe 对带宽的影响可以忽略不计（小于 3%），这要归功于快速且确定性的 IOPMP 条目修改。此外，DMA 请求多一个周期不会影响网络带宽，因为 DMA 请求可以与其他请求一起进行管道传输。相比之下，由于 IOTLB 失效，IOMMU-strict 会给单个 CPU 核心带来 25% ∼ 38% 的网络带宽开销，为多个核心带来 20% ∼ 27% 的网络带宽开销。 IOMMU-deferred 的开销较小，但仍然留下攻击窗口。

此外，sIOPMP 可以平衡 IOMMU 的安全性和性能之间的权衡。当sIOPMP和IOMMU一起工作时，安全检查可以卸载到sIOPMP，IOMMU只负责设备地址转换。在这种情况下，IOMMU 可以推迟 IOTLB 失效，但 sIOPMP 将在每个 dma_unmap 操作中立即重置这些条目，而不会暴露任何攻击窗口。评估结果（图 15）显示，sIOPMP+IOMMU 与 IOMMU-deferred 具有相似的性能（仅比 IOMMU 提高 19%），因为与 IOTLB 失效（异步）相比，IOPMP 条目修改成本较小且具有确定性。此外，为了取消映射大尺寸的连续设备内存，sIOPMP 可以在基于范围的级别进行操作，而无需遍历页表等复杂操作。总之，IOMMU 可以将安全检查卸载到 sIOPMP，以提高整体性能以及严格的 I/O 隔离。

虽然一些 TEE 系统提出了 TEE-IO [15, 45] 机制，但对于现成的机器仍然不可用。当前的 TEE 系统（例如 SEV）仍然利用 SWIO，这需要在虚拟机管理程序干预下将额外的内存复制到反弹缓冲区（即 swiotlb）。我们比较了使用 virtio 的普通虚拟机和使用 SWIO 的机密虚拟机的最大网络吞吐量。由于 SWIO 需要额外的内存副本（管理程序无法直接访问机密 VM 中的私有内存），因此牺牲了 23% ∼ 24% 的网络带宽。值得注意的是，SWIO机制还存在其他缺点，例如由于虚拟机管理程序的干预而花费更多的CPU资源以及缺乏设备直通支持。

即使下一代CVM机器中采用了TEE-IO机制，在动态I/O隔离场景下，它仍然面临着与IOMMU相同的问题。虽然 TEE-IO 支持 CVM 中加密内存的直接内存访问，但它仍然依赖 RMP 进行 I/O 隔离。由于 RMP 是 IOMMU 组件的一部分，因此 RMP 条目失效的成本很高（使用异步命令）。如果我们使每个 dma_unmap 的 RMP 条目无效，它会遇到与 IOMMU-strict 相同的性能下降 (>20%)。

Distributed memcached

为了评估 sIOPMP 在实际数据中心工作负载中的性能，我们将 memcached 与分布式 memcached 负载生成器结合使用 [87]。此工作负载涉及 CPU、内存和网络组件之间的交互。不过，由于sIOPMP是核外模块，因此不会影响CPU端的执行。图 16 显示，在相同的 50% 或 99% 延迟要求下，sIOPMP 不会牺牲 memcached 吞吐量 (QPS)。此外，在考虑管道延迟时，它不会增加实际云应用程序的中值延迟和尾部延迟。

Cold device switching

我们评估了使用可安装 IOPMP 进行冷设备切换的开销，如第 4.2 节中所述。安全监视器处理 sIOPMP 中断并将可安装的 IOPMP 条目和 eSID 加载到硬件寄存器。整个冷设备切换过程在我们的平台上需要341个CPU周期（切换8个IOPMP条目）。

图 17 显示了不同配置中冷设备切换对 I/O 吞吐量的影响。我们在此测试用例中使用两台设备：一台是热设备（长时间运行），另一台是冷设备（间歇运行）。我们改变这两个设备的 DMA 请求比率。例如，1:100 表示每来自热设备的 100 个请求，来自冷设备的 1 个 DMA 请求。通过这种方式，我们可以测量冷设备切换如何影响不同工作负载中热设备的 I/O 吞吐量。如果我们在sIOPMP中正确设置设备状态，则意味着热设备使用SRC2MD表中固定的SID，而冷设备使用eSID，该eSID将被交换到扩展IOPMP表中。在此设置中，冷设备切换不会影响热设备的 I/O 吞吐量（无阻塞）。然而，如果我们错误地设置设备状态，就像在 sIOPMP 中将这两个设备都视为冷设备一样，“热”设备的 I/O 吞吐量将由于频繁的切换而降低。例如，当两个设备的 DMA 请求比例为 1:10 时，冷设备切换会浪费“热”设备 85% 的 I/O 吞吐量。评估结果表明，为了在 sIOPMP 中获得更好的性能，我们需要根据不同的设备工作负载正确设置设备状态（使用 IOPMP 重新映射）。

DISCUSSION

The number of IOPMP entries and hot devices

在我们的实现中，sIOPMP 支持 1000 个 IOPMP 条目和 64 个热设备。此配置适用于数据中心当前的机器。如今，大多数 CPU 的核心数都少于 64 个；因此，同一时间的热设备数量通常小于 64 个。然而，对于 sIOPMP 条目，一个设备可能会使用多个 I/O 区域，因为当前的 DMA 控制器支持分散-聚集模式 [41, 44]。 I/O 区域的数量应等于 DMA 控制器中分散缓冲区的数量（当前小于 1024）。使用这些设置，sIOPMP 可以与数据中心中的当前机器很好地配合使用。然而，这些设置在sIOPMP设计中并不是固定的，我们可以根据机器的演变来改变设置。例如，现代 CPU 可能支持 128 个核心，而我们在 sIOPMP 中可能需要 128 个热设备。

Limitation of other page-based I/O isolation mechanisms

目前的TEE系统除了传统的IOMMU之外还提出了额外的I/O检查模块。例如，SEV-SNP采用反向映射表（RMP）来保证页面映射的完整性，CCA利用粒度保护检查 (GPC)，用于验证设备和访问内存的 PAS 标签。然而这些方法仍然使用分页机制并集成到IOMMU中。他们遇到了与传统IOMMU类似的问题，例如IOTLB失效的高开销、没有子页面隔离以及额外的表遍历[35]。因此，基于页面的 I/O 隔离机制在具有频繁 dma_unmap 操作（例如网络）的动态工作负载中并不是低效的。另一方面，sIOPMP 继承了基于范围的隔离，不需要任何像 IOTLB 失效这样的异步操作。因此，它可以很好地适应静态和动态场景。

Comparison of sIOPMP with other permission check works on the CPU side

还有其他工作如 MMP [91]、raksha [33]、RangeCache [82] 也采用了对访问内存地址的权限检查，并提出了几种不同的方式来构造范围，sIOPMP 有三个关键改进：首先，sIOPMP 利用了特定于 I/O 场景的非常轻量级的基于区域的隔离机制。硬件成本和运行时开销极低。相比之下，MMP和Range Cache主要是为CPU设计的，需要考虑更复杂的隔离场景并使用更复杂的结构（例如不同类型的trie表条目）。其次，只有sIOPMP采用优先区域。优先区域比非优先区域提供更大的灵活性。第三，sIOPMP 引入了一些微架构优化，例如基于树的管道检查器，这在先前的系统中没有被探索过。

CONCLUSION

本文提出了 sIOPMP，一种适用于 TEE 系统的可扩展且高效的 I/O 保护机制。 sIOPMP 使用基于多级树的 IOPMP 检查器，支持 1000 个 IOPMP 条目，而不会影响时钟频率。它还采用可挂载的IOPMP和IOPMP重映射机制，平衡冷热设备之间的性能和可扩展性。评估结果表明，sIOPMP 在基准测试和实际系统中引入的性能开销可以忽略不计。