2023年7月5日
第21卷，第3期

CXL 内存保护的灵活性如何？

用手术刀代替大锤

Samuel W. Stark，A. Theodore Markettos，Simon W. Moore

起初，有 PCIe。实际上，在 2003 年 PCIe 取代 PCI 和 PCI-X 之前，还有许多其他的总线标准，例如 ISA 和 VME，但 PCIe 大致是它们的超集。它们都是互连技术，允许主机（例如，主系统 CPU）配置和操作连接的外部设备，并将它们的内存映射到共享地址空间。

随着时间的推移，计算变得越来越庞大和复杂，外部设备本身也变成了完整的系统。GPU（图形处理单元）是最好的例子，它们从硬连线的图形卸载设备发展成为功能齐全的通用处理器，与主机协同工作和通信以解决问题。

主机和设备之间的协同处理因 PCIe 缺乏一致的内存共享而变得复杂。当 CPU 核心共享内存时，它们使用缓存一致性协议来确保它们可以拥有快速的本地副本（缓存），同时保持内存的一致视图——即使其他核心写入内存也是如此。PCIe 不支持这种共享；它只允许主机和设备之间的块传输。各公司创建了后续协议——CCIX、OpenCAPI 和 Gen-Z——来支持这一点，但它们都已经消亡或被英特尔的 CXL（Compute Express Link）所取代。

CXL 在 PCIe 之上为加速器设备缓存主机内存 (CXL.cache) 和为主机缓存设备内存 (CXL.mem) 提供了新协议。业界目前专注于 CXL.mem 内存扩展设备。首批 CXL 兼容 CPU（于 2022 年 11 月发布）支持“用于内存扩展的 CXL 1.1+”¹，并且尚未发布 CXL 加速器——只有 CXL.mem 设备，例如三星的 512GB RAM 扩展¹⁹。于 2022 年 8 月发布的 CXL 3.0 增加了对连接多个主机到多个共享 GFAM（全局 Fabric 连接内存）设备的 Fabric 拓扑的支持。这促进了分离式内存，在分离式内存中，以任意拓扑连接的任意数量的端点可以请求、使用和一致地共享任意数量的内存。

如果分离式内存是未来，我们最大的问题是保护。当如此多的端点都连接到并共享相同的内存时，如何将它们限制为仅访问它们需要的内存？它们可能正在运行不受信任的软件，或者它们本身就是不受信任的硬件。在这种威胁环境中，内存保护如何工作？CHERI（Capability Hardware Enhanced RISC Instructions，能力硬件增强 RISC 指令集）项目已经表明，架构能力可以提供灵活、细粒度的内存保护²¹。CXL 当前的内存保护与之相比如何？能力系统能否在 CXL 具有恶意行为者的分布式环境中工作？首先，让我们检查 CXL 的保护机制，看看它们如何处理现实世界的安全问题。

保护系统

在大多数情况下，软件通过多层抽象使用物理资源。每一层都将传入的请求转换为下一层期望的格式，并且还可以提供保护。一个简单的例子是 MMU（内存管理单元），它将内存请求从虚拟内存转换为物理内存¹³。操作系统为每个进程提供不同的虚拟地址到物理地址的映射，MMU 确保进程只能访问操作系统已映射的物理内存。概括地说，保护系统确保行为者只能访问有效的资源。

系统可以提供的保护受到其行为者和资源粒度的限制；因此，多层抽象的保护非常重要。例如，MMU 只能在进程级别进行洞察。进程内部的软件对有效性有更严格的定义（例如，“我不会访问越界的数组元素”），MMU 不理解这些定义（它不知道也不关心数组在哪里），因此无法提供帮助。相反，可以在 MMU 之上添加另一层，例如语言运行时 (JVM, .NET) 或基于硬件的检查 (CHERI²¹)，它们具有更多信息，并确保更细粒度的有效性。

不同的抽象级别可以添加不同的行为者和资源集。例如，操作系统负责确保其进程正确访问文件，并负责通过文件系统驱动程序实际执行这些访问。如果这些文件位于网络文件系统上，则服务器可能必须同时处理多个客户端，并检查它们是否正确访问文件。单个操作系统不知道其他客户端，服务器也不知道操作系统内部运行的进程，因此在两个级别都进行保护和检查是必要的。

CXL 及其缺陷

CXL 像 PCIe 一样，使用主机-设备模型。每个 CXL 主机控制一组连接的外部设备，并将它们暴露的所有内存映射到 HPA（主机物理地址空间）。主机也可以将其自己的内存映射到 HPA 中，并且像 GPU 这样的加速器设备可以通过 CXL.cache 访问它，但目前的设备只是通过 CXL.mem 向主机暴露 RAM。CXL 3.0 升级了 CXL.mem，允许主机通过多头和 GFAM 设备共享内存区域。

多头 CXL.mem 设备连接到多个主机，并且可以将物理内存的相同区域同时映射到所有主机的 HPA 中。这些主机都可以缓存这些区域的部分内容，并且设备负责确保一致性（参见图 1）。例如，如果主机 1 尝试写入区域 A 中的缓存行，则设备意识到主机 2 和主机 3 共享区域 A，并告诉它们使该缓存行无效。不幸的是，每个主机只能访问 16 个区域⁸（第 2.5 节），因此它们必然会很大——数量级为千兆字节或数百兆字节。

GFAM 设备更进一步，它不附加到特定的主机。任何主机都可以将 GFAM 内存映射到其 HPA 中，并且该 HPA 中的任何端点（主机或设备）都可以直接与 GFAM 通信并访问该内存。GFAM 为每个端点配置了单独的转换表，因此每个端点可以访问八个物理内存区域⁸（第 7.7.2.4 节）。这些区域可能重叠，允许内存共享，或者它们可能是隔离的。如图 2 所示，映射了 10GiB 的 GFAM，但主机和加速器配置为每个只能看到 6GiB，其中有 2GiB 的共享区域。同样，由于每个端点的范围很少，因此它们将很大。内存组⁸（第 7.7.2.5 节）可以在这些范围中打孔并隐藏特定的块，但孔的大小至少为 64MB⁸（表 7-67，最小块大小）。

两种类型的内存都通过非详尽的转换提供保护：端点请求其 HPA 中的地址，这些地址被转换为本地设备地址，并且该转换可能会失败（即，端点可能没有在该地址映射内存）。这些机制类似于 MMU，提供不灵活的粗粒度保护。每个端点最多可以访问每个设备 16 个内存范围。更改映射和转移访问权限的唯一方法是说服 Fabric 管理器，它没有为此定义接口⁸（第 7.6.1 节）。

CXL 3.0 还引入了无序 I/O 请求，允许加速器访问其他设备的内存，但没有标准化的方法来保护这些访问。可能可以阻止特定设备完全交互（例如，通过 PCIe 访问控制服务）或添加类似 MMU 的保护（例如，通过 PCIe 地址转换服务），但这些以及 CXL 的其他保护模型一样，都是不灵活且粗粒度的。

CXL 的保护并不理想。端点可以配置为访问和共享大型内存区域，但不能共享许多小型内存区域。端点不能相互授予内存访问权限；它们必须通过中介。设备到设备的访问必须依赖于供应商定义的保护（如果有的话）。这与现实世界的威胁相比如何？

数据中心中的威胁

首先，我们可以从 AWS（亚马逊网络服务）于 2022 年 11 月发布的关于其 Nitro 平台的白皮书中了解数据中心威胁模型²。云系统必须在同一硬件上运行来自许多互不信任的客户端的工作负载。在 Nitro 之前，AWS 会将所有客户端工作负载作为 VM（虚拟机）运行在虚拟机监控器之上，虚拟机监控器向每个 VM 公开隔离的虚拟化资源。例如，虚拟机监控器将为每个 VM 实现网络卡的软件模型，以便它可以控制 VM 可以访问哪些网络。Nitro 系统的关键影响是将这种虚拟化从虚拟机监控器移到硬件中。

每个 Nitro 系统都由自定义的 Nitro 控制器 PCIe 卡控制。这是硬件信任根，负责在运行客户端工作负载之前配置系统主板（即，CPU、主板和 RAM）和其他外围设备。网络和存储通过其他 AWS 设计的 Nitro PCIe 卡访问，Nitro 控制器可以使用 PCIe SR-IOV（单根 I/O 虚拟化）¹⁶将这些卡拆分为虚拟功能，从而为每个 VM 提供隔离的资源。

当运行许多 VM 时，仍然需要一个最小的虚拟机监控器来配置 MMU 并将每个 VM 链接到其专用的虚拟功能。Nitro 系统还可以运行裸金属（没有虚拟机监控器的单个客户端工作负载）。即使客户端工作负载不受信任，Nitro 卡仍然虚拟化对网络和存储的访问。

AWS 信任 Nitro 控制器来启动系统，信任 Nitro 卡来虚拟化网络/存储，并信任虚拟机监控器/MMU 来强制 VM 之间的隔离。客户端工作负载不可信，如果它们运行的是裸金属，那么来自系统主板的任何通信也不可信。从 CXL 的角度来看，这意味着主机可能是恶意的（运行裸金属）或负责许多恶意工作负载（运行 VM）。在后一种情况下，CXL 没有任何可以帮助虚拟化的结构。实际上，CXL 根本不考虑虚拟化——字面上说，规范中没有虚拟化和类似术语。

数据中心有更复杂的情况。加速器设备（例如 GPU）有时依赖于直接共享内存以获得高性能。Nvidia 的 Magnum I/O API¹⁸ 允许 GPU 直接访问 NVMe 存储设备 (GPUDirect Storage)、与其他 GPU 共享内存 (NVSHMEM) 以及将其内存暴露给其他外围设备 (GPUDirect RDMA)，包括 InfiniBand 适配器 (nvidia-peermem)。

虽然一些 GPU 名义上通过 SR-IOV 支持虚拟化，但 AWS 并未利用这一点——客户端工作负载被赋予完整的 GPU 数量并直接控制它们（客户端甚至控制 GPU 驱动程序³）。这扩大了威胁模型。不仅 GFAM 在 HPA 之间共享内存，而且单个设备（包括加速器）也可能将其内存暴露给由恶意客户端控制的端点。

CXL 不处理这种用例。它隐含地假设主机和设备是值得信任的。如果主机有虚拟机监控器来约束它们，那么主机可能是值得信任的，并且设备可能会被仔细选择以获得信任，但是如果任何设备或主机不可靠（例如，运行裸金属客户端工作负载），则需要更好的保护。

消费者领域的威胁

恶意设备的威胁并非数据中心独有——事实上，对于消费者来说情况更糟！台式机和笔记本电脑有大量外部端口用于连接任意硬件，包括高性能加速器，例如外部 GPU。加速器利用包装了 PCIe 的高速 Thunderbolt 连接，使外部硬件可以访问内部 PCIe 内存映射。已经证明了通过 Thunderbolt 对基于 PCIe 的系统的攻击¹⁵，表明即使启用了 IOMMU 等保护，恶意硬件也可以访问旨在用于其他设备的敏感内存。

更糟糕的是，直接的设备到设备内存访问也正在进入消费系统。现代游戏机依赖于从存储到 GPU 可访问内存的高速传输，微软的 DirectStorage API 使其在 PC 上更接近现实。虽然在撰写本文时，它仍然通过系统 RAM 中的缓冲区复制数据，但高性能渲染系统（例如，游戏和视频编辑）最终将利用直接访问似乎是不可避免的——尤其因为它在数据中心中已经成为可能。

CXL 即将进入消费市场，因此它需要处理这个问题。在 AMD 于 2022 年 10 月举行的“Meet the Experts”网络研讨会⁴上，一位 AMD 代表表示，它可能会在五年内进入消费设备，最初的重点是连接持久性存储和 RAM。从持久性存储加载是当前设备到设备传输的主要用例，因此 CXL 需要尽早考虑恶意设备。

就目前而言，CXL 的内存保护充其量是不灵活的。它能够隔离大型内存区域中的端点，但仅此而已。它没有能力为在同一端点上运行的工作负载进行虚拟化，并且无法保护设备免受彼此的侵害。

基于能力的 CXL 保护

CHERI²¹ 是一种基于能力的保护系统，已被证明对于灵活、细粒度（数十字节）的内存保护和隔离（通过将程序和库彼此隔离）都非常有用²²。这似乎解决了 CXL 的所有安全问题。CXL 可以采用基于能力的系统吗？

能力是不可伪造的令牌，它编码了访问资源的权限。给定一个能力，行为者可以访问资源，派生具有降低权限的该资源的新能力，将它们转移给其他行为者，并且如果这些行为者不再需要访问权限，则可能会撤销它们。由于访问权限直接编码在令牌中，因此能力非常灵活：很容易为新情况派生具有极其具体访问权限的新能力。派生大量能力确实有一个缺点：撤销能力——递归删除所有派生——可能会更困难。让我们检查几个例子。

中心信任系统

能力必须是不可伪造的。当使用能力时，系统需要某种方法来验证它是否未被伪造。强制执行此操作的最简单方法是将所有能力存储在集中的可信库或中心信任系统中，并在其中执行所有能力修改。

FreeBSD Capsicum²⁰ 是一个例子，它通过用能力替换 Unix 文件描述符来保护文件免受进程的影响。进程可以打开它需要的文件，使用更细粒度的权限限制其访问，然后进入能力模式以使用这些文件沙盒化自身。与文件描述符类似，能力存储在操作系统内存中的表中。用户空间程序必须使用系统调用来请求操作系统操作它们，而不是直接创建或修改它们。操作系统信任自身能够正确修改能力（例如，从不添加权限，只删除权限），因此能力无法伪造。虽然 Capsicum 不执行撤销，但在原则上，它只需要搜索表，甚至跟踪能力元数据中的父系关系。这提供了比普通 Unix 更好的安全性，但系统调用和上下文切换到操作系统可能会很慢。

CHERI 采用了不同的方法。CHERI 没有在软件中实现可信库，而是在硬件中实现它，并添加了用于快速能力操作的机器指令。CHERI 用能力替换指针——胖指针，其中包括指针可能指向的地址范围。此范围确保指针保持在其原始出处^6,12内，并且可以进一步限制（例如，您可以分配一个数组，派生一个数组元素的能力，并将该能力传递给函数，而无需暴露数组的其余部分）。

寄存器和内存使用标签位来标记有效的能力，硬件控制标签位以防止伪造。由于所有指针都具有此元数据，包括代码指针，因此即使是最小的软件组件（例如，单个函数）也可以仅使用它们需要的内存进行沙盒化。更大的库，即使是那些在没有 CHERI 支持的情况下编译的库，也可以使用隔间进行沙盒化²²。在任何地方存储能力的成本是撤销需要搜索所有地方²³，尽管开销低于您可能预期的¹⁰。CHERI 确保逻辑软件组件只能访问它们已被明确授予访问权限的虚拟内存范围。

这如何帮助 CXL？眼尖的读者可能会注意到，GFAM 已经使用类似于 Capsicum 的系统——每个端点（即，行为者）最多有八个转换表条目（即，能力），这些条目授予对内存的访问权限。这证明了在这种上下文中集中式系统的缺陷：能力的数量（以及隐含的粒度）可能会受到硬件资源的限制。这更适合于保护主机内存免受有限数量的设备的影响，例如¹⁴，但 GFAM 试图跟踪授予数千个行为者的所有能力。为了缓解这种情况，可以将能力存储在通过 CXL.mem 暴露的内存中，或者为每个端点提供一些专用的能力内存，例如 Capsicum 的表。两种情况都需要在端点之间分配信任。

分布式信任系统

Barrelfish^5,17 和 SemperOS¹¹ 是分布式操作系统，实现为在单独核心上运行并使用消息传递进行通信的单独实例。Barrelfish 使用能力来保护操作系统资源，例如消息传递和线程原语、物理内存范围等。SemperOS 使用能力来构建内存文件系统。

能力操作的可信库分布在操作系统核心之间，但旨在提供与中心信任系统相同的语义。最重要的是，任何核心都可以从任何其他核心中的能力派生，因此撤销可能需要触及所有核心。这要求所有行为者彼此信任。它比中心信任系统更难以推理，但它扩展性更好——特别是如果跨行为者操作不常见的话。

对于 CXL，如果所有端点都值得信任，这可能是合适的。例如，如果数据中心中的所有端点都使用类似 CHERI 的硬件来操作能力，则这可能会奏效。然而，在规模上，撤销可能会成为更大的问题，而且 CXL 无论如何都不能仅仅依赖此模型——恶意端点的威胁太大了。

去中心化系统

即使调用集中的可信库来操作能力是不可能或不切实际的，并且行为者不能被信任来正确操作能力，仍然有希望。去中心化能力，例如 macaroons⁷，可以传递给不受信任的行为者，并在这些行为者尝试使用它们时检查其有效性。

Macaroons 提供对资源的访问，该访问通过仅附加的限制条件列表来减少。macaroon 以标识符（例如“访问事务详细信息”）和签名开头，签名是通过使用密钥对标识符进行哈希处理而生成的。当添加限制条件（例如“用于 Alice 的帐户”或“直到美国东部时间下午 5 点”）时，该限制条件将与当前签名进行哈希处理以生成新签名。旧签名被丢弃且无法重建——哈希无法撤消。给定一个具有一组限制条件的 macaroon，在没有密钥的情况下，不可能删除限制条件并重新计算正确的签名。因此，敌对用户不可能伪造具有较少限制条件（即，更多权限）的 macaroon。

去中心化能力尚未集成到低级软件或硬件中。Macaroons 最初是为 Web 设计的，因此它们具有基于文本的线路格式和第三方身份验证功能，而基于二进制的互连不需要这些功能。这对于网络层来说很好（例如，Michael Dodson 将 macaroons 与 CHERI 结合使用，用于通过不安全的网络进行细粒度的内存映射 I/O 访问⁹），但领域优化的表示形式将更节省空间。

撤销也很有趣。能力可以附带超时限制条件并需要刷新，或者可以通过丢弃其密钥来撤销一组能力（及其所有派生）。这将允许 CXL 端点自行存储和（尝试）操作其能力，并让 CXL.mem 设备撤销它们，所有这些都无需信任它们。去中心化能力对敌对行为者具有鲁棒性，不需要集中式资源，并且值得进一步研究。

结论

物理内存通过多层抽象进行访问。在不同的层应用保护至关重要，这些层了解不同的行为者并在不同的粒度级别使用资源。CHERI 和 MMU 在软件和进程级别提供强大的保护，但 CXL 的保护模型存在问题。它允许内存共享，但只能共享少量大型范围，而不是许多小型范围。它没有为行为者提供彼此共享新内存范围的方式，而是依赖于中心化的、未充分指定的 Fabric 管理器。能力本质上是灵活的——它们可以保护大型和小型内存范围，并且可以在行为者之间直接传输，而无需中心化机构——因此它们应该能够解决这些问题。

CXL 最初的目标是数据中心，其中许多端点共享分离式内存。保护是粗粒度的，并且不考虑虚拟化。在同一主机上运行的 VM 必须依赖于类似的粗粒度虚拟机监控器和基于 MMU 的隔离。细粒度的能力可以允许单个 VM 直接共享小型内存区域。用于大型内存区域的能力也可以在 CXL 层强制执行 VM 隔离，类似于 CHERI。

在数据中心和消费系统中，设备到设备的内存共享对于高性能变得至关重要。CXL 根本不尝试保护设备免受彼此的侵害，考虑到恶意设备已经可以多么强大，这尤其令人担忧。能力将为安全地暴露设备内存区域提供一致的接口。去中心化能力对恶意行为者具有鲁棒性，并且可以维持不可信硬件的狂野西部中的和平。在具有可信组件的数据中心中，分布式信任系统甚至可以放弃与去中心化能力相关的密码学，以降低开销。

去中心化和分布式能力具有很大的潜力，但它们尚未在这种环境中得到应用，需要进一步研究。即便如此，它们也可以极大地惠及 CXL。CXL 是一种新的互连标准，它提供了从一开始就构建更好的安全性而不是稍后进行改造的机会。领域优化的去中心化能力系统可以创造奇迹，为 CXL 提供细粒度的内存共享，并改进虚拟化和设备到设备的安全。互连需要更加重视安全性，我们相信能力可以为 CXL 及其他领域提供灵活而强大的安全性。

致谢

我们要感谢由 Robert Watson 领导的 CHERI 项目团队，感谢他们展示了能力在内存安全方面的潜力，没有他们的工作，这项工作就不可能存在。CHERI 团队在本文的开发过程中也提供了重要的反馈，对此我们深表感谢。这项工作得到了剑桥大学哈丁杰出研究生学者计划以及 EPSRC 资助 EP/V000381/1 (CAPcelerate) 的支持。

参考文献

1. Advanced Micro Devices, Inc. 2022. Offering unmatched performance, leadership energy efficiency, and next-generation architecture, AMD brings 4th gen AMD EPYC processors to the modern data center; https://www.amd.com/en/pressreleases/2022-11-10-offering-unmatched-performanceleadership-energy-efficiency-and-next.

2. Amazon Web Services. 2023. The security design of the AWS Nitro System. AWS whitepaper; https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html.

3. Amazon Web Services; https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-nvidia-driver.html.

4. AMD Meet the Experts Webinars. How AM5, DDR5 memory, and PCIe 5.0 support pave the way for next-gen gaming experiences; https://webinars.amd.com/wcc/eh/3751456/lp/3915027/ how-am5-ddr5-memory-and-pcie-50-support-pave-the-way-for-next-gen-gaming-experiences.

5. Baumann, A., et al. 2009. The Multikernel: a new OS architecture for scalable multicore systems. In Proceedings of the SIGOPS 22nd Symposium on Operating Systems Principles, 29–44; https://dl.acm.org/doi/10.1145/1629575.1629579.

6. Beingessner, A. 2022. Rust's unsafe pointer types need an overhaul. Faultlore; https://faultlore.com/blah/fix-rust-pointers/.

7. Birgisson, A., et al. 2014. Macaroons: cookies with contextual caveats for decentralized authorization in the cloud. In Network and Distributed System Security Symposium; https://www.ndss-symposium.org/ndss2014/programme/macaroons-cookies-contextual-caveats-decentralized-authorization-cloud/.

8. CXL Consortium. 2022. Compute Express Link (CXL) Specification, revision 3.0, version 1.0. https://www.computeexpresslink.org/download-the-specification.

9. Dodson, M. G. 2021. Capability-based access control for cyber physical systems. Thesis, University of Cambridge, Computer Laboratory; https://www.repository.cam.ac.uk/items/784cbc11-00ad-448d-96c0-a9ccaa451f4b.

10. Filardo, N. W. 2020. Cornucopia: temporal safety for CHERI heaps. In IEEE Symposium on Security and Privacy, 608–625. https://ieeexplore.ieee.org/document/9152640.

11. Hille, M., Asmussen, N., Bhatotia, P., Härtig, H. 2019. SemperOS: a distributed capability system. In 2019 Usenix Annual Technical Conference, 709–722; https://www.usenix.org/conference/atc19/presentation/hille.

12. Jung, R. 2018. Pointers Are Complicated, or: What's in a Byte? Ralf's Ramblings; https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html.

13. Kernel Development Community. Virtual memory primer; https://linuxkernel.org.cn/doc/html/latest/admin-guide/mm/concepts.html#virtual-memory-primer.

14. Markettos, A. T., Baldwin, J., Bukin, R., Neumann, P. G., Moore, S. W., Watson, R. N. M. 2020. Position paper: defending direct memory access with CHERI capabilities. In Hardware and Architectural Support for Security and Privacy. Article No. 7, 1–9; https://dl.acm.org/doi/10.1145/3458903.3458910.

15. Markettos, A. T., Rothwell, C., Gutstein, B. F., Pearce, A., Neumann, P. G., Moore, S. W., Watson, R. M. N. 2019. Thunderclap: exploring vulnerabilities in operating system IOMMU protection via DMA from untrustworthy peripherals. In Proceedings of the Network and Distributed System Security Symposium; 10/gjh62d.

16. Microsoft. 2021. An introduction to single root I/O virtualization (SR-IOV); https://learn.microsoft.com/en-us/windows-hardware/drivers/network/single-root-i-o-virtualization--sr-iov-.

17. Nevill, M. 2012. An evaluation of capabilities for a multikernel. Master's thesis, ETH Zurich; https://barrelfish.org/publications/nevill-mastercapabilities.pdf.

18. Nvidia Magnum IO; https://www.nvidia.com/en-us/data-center/magnum-io/.

19. Samsung Semiconductor. 2022. Samsung Electronics introduces industry's first 512GB CXL memory module; https://news.samsung.com/global/samsung-electronicsintroduces-industrys-first-512gb-cxl-memory-module.

20. Watson, R. N. M., Anderson, J., Laurie, B., Kennaway, K. 2012. Capsicum: practical capabilities for Unix. Communications of the 55(3), 97–104; https://dl.acm.org/doi/10.1145/2093548.2093572.

21. Watson, R. N. M., Moore, S. W., Sewell, P., Neumann, P. G. 2019. An introduction to CHERI. University of Cambridge, 43; https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf.

22. Watson, R. N. M., et al. 2015. CHERI: a hybrid capability-system architecture for scalable software compartmentalization. In IEEE Symposium on Security and Privacy, 20–37; https://ieeexplore.ieee.org/document/7163016.

23. Xia, Hongyan, et al. 2019. CHERIvoke: characterising pointer revocation using CHERI capabilities for temporal memory safety. In Proceedings of the 52nd Annual IEEE/ International Symposium on Microarchitecture, 545–557; https://dl.acm.org/doi/10.1145/3352460.3358288.

Samuel W. Stark 是剑桥大学计算机科学与技术系的博士生和哈丁学者，在 Simon Moore 的指导下研究能力在共享内存系统中的更广泛应用。他在剑桥大学的 MPhil 项目评估了 CHERI 对向量化加载/存储指令的影响，并赢得了 2022 年英国 RISE 学生竞赛。他对 GPU 特别感兴趣，这源于他在游戏行业的工作，他希望在离开学术界后从事对情感产生积极影响的媒体工作。

A. Theodore Markettos 是剑桥大学计算机科学与技术系的高级研究助理。他共同领导 CAPcelerate 项目，该项目研究使用能力来保护分布式不可信加速器。他拥有广泛的研究兴趣，从操作系统和软件到 FPGA、硬件设计和电子制造。

Simon W. Moore 是剑桥大学计算机科学与技术系计算机工程教授，他在计算机体系结构领域进行研究和教学，特别关注安全且经过严格工程设计的处理器和子系统。

最初发表于 Queue 杂志第 21 卷，第 3 期—
在数字图书馆中评论这篇文章

更多相关文章

Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用可信联邦学习的可信 AI
安全性、隐私性、问责制、透明度和公平性的原则是现代人工智能法规的基石。经典的 FL 设计非常强调安全性和隐私性，但牺牲了透明度和问责制。CFL 通过将 FL 与 TEE 和承诺相结合，弥补了这一差距。此外，CFL 还带来了其他理想的安全属性，例如基于代码的访问控制、模型机密性和推理期间的模型保护。机密计算的最新进展，例如机密容器和机密 GPU，意味着现有的 FL 框架可以无缝扩展以支持低开销的 CFL。

Raluca Ada Popa - 机密计算还是密码计算？
通过 MPC/同态加密与硬件飞地进行安全计算，在部署、安全性和性能方面存在权衡。关于性能，您考虑的工作负载非常重要。对于简单的工作负载，例如简单的求和、低阶多项式或简单的机器学习任务，这两种方法都可以在实践中使用，但对于丰富的计算，例如复杂的 SQL 分析或训练大型机器学习模型，目前只有硬件飞地方法在许多实际部署场景中足够实用。

Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 机密容器组
此处展示的实验表明，Parma，即驱动 Azure 容器实例上的机密容器的架构，除了底层 TEE 增加的性能开销外，仅增加了不到百分之一的额外性能开销。重要的是，Parma 确保了容器组在证明报告中所有可达状态的安全不变性。这允许外部第三方与容器安全通信，从而支持各种需要机密访问安全数据的容器化工作流程。公司可以在云中运行最机密的工作流程，而无需在其安全要求上妥协，从而获得优势。

Charles Garcia-Tobin, Mark Knight - 使用 Arm CCA 提升安全性
机密计算在提高通用计算平台安全性方面具有巨大潜力，通过将监管系统从 TCB 中移除，从而减小 TCB 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要在平台硬件和软件方面进行创新，但这些创新有可能增强对计算的信任，尤其是在第三方拥有或控制的设备上。机密计算的早期消费者将需要就他们选择信任的平台做出自己的决定。