2024年5月22日
第22卷，第2期

保密容器组

在 Azure 容器实例上实现保密计算

Matthew A. Johnson、Stavros Volos、Ken Gordon、Sean T. Allen、Christoph M. Wintersteiger、Sylvan Clebsch、John Starks、Manuel Costa

自从 Amazon（2006 年的 Amazon Web Services）、Microsoft（2008 年的 Azure）和 Google（2008 年的 Google Cloud Platform）推出大规模 IaaS（基础设施即服务）产品以来，云计算一直呈持续发展趋势，它允许客户通过规模经济来利用能力和成本优势。这通过虚拟化³成为可能，其中 VM（虚拟机）通过使用 hypervisor（虚拟机监控器）根据多个租户表达的使用需求来协调他们之间的共享，从而实现对大型裸机计算架构（主机）的有效利用。虽然 VM 为用户提供了一种快速获取额外计算能力并最大化利用现有硬件（和/或通过使用公共云来避免维护峰值容量的成本）的方法，但仍然需要配置、部署、管理和维护它们。

近年来，Docker 和 Kubernetes 等基于容器的技术应运而生，以简化软件应用程序生命周期的管理。它们为创建一组机器配置（称为容器）提供了一个轻量级解决方案，这些容器可以通过自动化流程作为一组部署到硬件（虚拟化或物理）上。容器技术提供了多个独立的用户空间实例，这些实例通过内核软件相互隔离。与 VM 不同，容器直接在主机系统上运行（共享其内核），因此，不需要模拟设备或维护大型磁盘文件。此外，符合 OCI（开放容器倡议）分发规范¹³的容器定义将依赖项指定为层，这些层可以在不同的容器之间共享，从而使其适用于缓存，进而加快部署速度，同时降低多个容器的存储成本。

容器化技术在本地系统上的成功促使主要云提供商开发了自己的 CaaS（容器即服务）产品，这些产品为客户提供了在公共云中维护和部署容器的能力。在 CaaS 产品中，容器在每个组的 UVM（实用程序虚拟机）中运行，这提供了在同一主机上运行的不同租户的容器之间的 hypervisor 级别的隔离。虽然主机上运行的容器管理器和容器 shim 负责从容器注册表中拉取镜像、启动 UVM 并编排容器执行，但在 UVM 中运行的代理（guest agent，访客代理）根据主机端容器 shim 的指示协调容器工作流程。

云计算为需要保密性的系统带来了挑战⁷，因为所涉及的三个群体有相互竞争的需求

• CSP（云服务提供商） – 公共云的所有者和运营商。

• 租户 – CSP 的客户，他们使用云来托管应用程序。

• 用户 – 租户的客户或员工，他们使用租户的云应用程序。

虽然 VM 和 VM 隔离的容器组在租户之间提供了强大的隔离，但它们由 CSP 部署并由 CSP 的 hypervisor 协调。因此，在现有的云产品中，主机操作系统（包括容器管理器和容器 shim）和 hypervisor 位于租户的 TCB（可信计算基）中，并且包含租户需要信任的所有硬件和软件。通常，TCB 应该尽可能小。因此，对保密计算²²的研究提出通过利用硬件强制执行的 TEEs（可信执行环境）来缩小 TCB 的规模。^{2,4,5,6,8,10,11,16,17}

TEEs 将应用程序的代码和数据与系统的其余部分（包括特权组件）隔离。即使主机的软件被破坏或被恶意实体控制，它们也能保护用户工作负载的完整性和保密性。主要 CPU 供应商提供的 TEE 可以是基于进程的，例如 Intel SGX；¹⁹ 也可以是基于 VM 的，例如 AMD SEV-SNP、⁹ Intel TDX²⁰ 和 ARM CCA。²¹ 基于 VM 的 TEE 提供 VM 的硬件级隔离，防止主机操作系统和 hypervisor 访问 VM 的内存和寄存器。

对于 CaaS，容器执行由主机端的 shim 编排，该 shim 与 guest agent 通信，guest agent 协调 UVM 中容器组的活动。UVM 可以在 TEE enclave（安全区）中进行硬件隔离，但容器镜像仍然由主机控制，它们被挂载的顺序、容器环境变量、通过容器 shim 和 guest agent 之间的桥梁发送到容器的命令等等也由主机控制。这意味着受损的主机可以通过注入恶意容器来克服 VM 的硬件隔离。这种攻击风险（无论是来自 CSP 的恶意或受损员工，还是外部威胁）限制了容器化在云中用于金融和医疗保健等敏感工作负载的程度。

解决此问题的简单方法是在同一个基于 VM 的 TEE 中运行 guest agent 和容器 shim。这会将 CSP 从租户的 TCB 中移除，但也会剥夺 CSP 编排和自动化容器工作流程的能力。它还将租户留在用户的 TCB 中。这是因为容器镜像由租户控制，它们被挂载的顺序、容器环境变量以及发送到容器的命令也由租户控制。保密容器的用户（例如，银行客户或向医生提供数据的患者）必须信任租户已经并将只运行预期的命令。最后，这使得镜像完整性和数据保密性/完整性问题仍然未解决。

为了在保持 CSP 和租户都不在用户的 TCB 中的同时提供镜像和数据完整性，我们构建了 Parma，它为 Azure 容器实例上的保密容器提供动力。它在支持基于 VM 的 TEE 的处理器（即 AMD SEV-SNP 处理器）上运行的先进容器堆栈上实现了保密容器抽象。Parma 提供了即取即用的体验，并且能够运行从（未修改的）容器注册表中拉取的未修改的容器，同时提供以下强大的安全保证

• 容器证明和完整性。 只有客户指定的容器才能在 TCB 中运行，TCB 会检测到任何容器篡改手段，并将导致容器组部署失败（如果执行策略完好无损）或远程证明无效（因为证明的策略不同）。

• 用户数据保密性和完整性。 只有 TCB 才能访问用户的数据，TCB 会通过提供给用户的证据来检测到任何数据篡改手段。

图 1 显示了 Parma 如何使用执行策略来强制执行用户约束并为容器组提供安全性。执行策略是保密 VM 的一个组件，它在初始化时经过证明，并描述了租户明确允许 guest agent（由 CSP 运营）在在该 VM 上运行的容器组中执行的所有操作。图 1(a) 显示了 Parma 如何将用户 TCB 限制为容器组本身，将其与主机操作系统和 hypervisor 隔离。图 1(b) 显示了一个不成功的挂载操作（由主机请求并被访客拒绝），其中容器镜像的某个层没有与策略中枚举的哈希匹配的 dm-verity（设备管理器“verity”目标）根哈希。

Confidential Container Groups: Implementing confidential computing on Azure container instances

Parma 为容器的根文件系统（由容器镜像层和可写暂存空间组成）和用户数据提供强大的保护，防止 CSP 的侵害。对于容器镜像层（由不受信任的容器管理器以明文形式拉取并存储在主机端块设备中），Parma 将设备挂载为受完整性保护的只读文件系统，并依靠文件系统驱动程序在访问文件系统时强制执行完整性检查。对于存储在块设备（例如，容器根文件系统的可写暂存空间）或 blob 存储（例如，保存用户数据的远程 blob）中的隐私敏感数据的保密性和完整性，Parma 依赖于块级加密和完整性来解密内存映射的块，从而保证数据仅以明文形式出现在 VM 的硬件保护内存中。

最后，Parma 通过强制执行租户指定的执行策略来提供根植于安全硬件的容器证明。guest agent 已经得到增强，可以强制执行执行策略，以便它只执行那些租户明确允许的命令（由不受信任的容器 shim 提交），如图 1 所示。该策略通过将其度量编码到证明报告中作为 UVM 初始化时的不可变字段来证明。

由于包含了执行策略，硬件发布的证明描述了容器组的初始状态及其所有允许的状态转换。然后，下游用户可以使用该证明进行需要建立安全保证的操作。例如，远程验证者可以将密钥（管理用户加密数据）仅发布给那些可以出示证明报告的容器组，该报告编码了预期的执行策略和 UVM 的度量。

架构

本节介绍实现这种新的保密容器抽象的 Parma 架构，该架构使用经过证明的执行策略。首先描述了容器平台，它是 Parma 设计和实现的基础，然后详细描述了威胁模型。本节还介绍了威胁模型下的安全保证，并描述了 Parma 如何通过一系列设计原则提供这些保证。

Parma 的指导原则是提供容器组状态的归纳证明，该证明根植于 PSP（平台安全处理器）生成的证明报告。CPLAT（容器平台）的标准组件和生命周期在很大程度上保持不变，除了 guest agent，其行为受到执行策略的约束。因此，受约束的系统未来状态可以根植于访客初始化期间执行的度量。

容器平台

图 2 说明了容器流程。顶部的顺序图显示了导致 VM 隔离容器的过程。五边形对应于以下步骤：（i）拉取镜像；（ii）启动 pod；（iii）创建容器；（iv）启动容器。此图中的圆圈概述了工作流程中的多个攻击点：容器 shim 可能会在 UVM 创建期间传递受损的（1）UVM 镜像或（2）guest agent。容器管理器可以（3）更改或伪造恶意层 VHD（虚拟硬盘）和/或（4）将任意层组合挂载到 UVM 上。容器 shim 可以传递（5）用于创建容器文件系统的任何层集，以及（6）任何环境变量或命令组合。受损的主机操作系统可以（7）篡改本地存储；（8）攻击 UVM 的内存；或（9）操纵远程通信。此列表并非详尽无遗。

CPLAT 是一组围绕 containerd 功能构建的组件，containerd 是一个守护程序，它管理完整的容器生命周期，如图 2 所示，从镜像拉取和存储到容器执行和监督，再到低级存储和网络连接。containerd 支持 OCI 镜像和运行时规范¹³，并为 Docker、Kubernetes 和各种公共云产品等多种容器产品提供基础。客户端通过客户端接口与 containerd 交互。containerd 支持运行裸机容器（即直接在主机上运行的容器）以及在 UVM 中运行的容器。

VM 隔离容器是这里的重点。CPLAT 与在主机操作系统中运行的自定义容器 shim 接口连接。容器 shim 与（i）主机服务交互以启动启动新 pod 所需的 UVM，以及（ii）在 UVM 中运行的 guest agent 交互。guest agent 负责创建容器并生成一个进程来启动容器。本质上，容器 shim 到 guest agent 的路径允许在主机操作系统中运行的 CPLAT 组件在隔离的访客 VM 中执行容器。使用 CPLAT 在 Linux 上执行 VM 隔离容器涉及四个高级步骤（如图 2 所示），相当于图 3 中的四个命令。

威胁模型

Parma 旨在解决强大的攻击者控制整个主机系统的情况，包括 hypervisor 和主机操作系统，以及其中运行的所有服务。也就是说，我们信任 CPU 封装，包括 PSP 和 AMD SEV-SNP 实现，它们提供了访客地址空间与系统软件的硬件级隔离。我们还信任 PSP 上运行的固件及其对访客 VM 的度量，包括 guest agent。

这样的攻击者可以

• 篡改容器的 OCI 运行时规范。

• 篡改存储只读容器镜像层和可写暂存层的块设备。

• 篡改容器定义，包括 overlay 文件系统（即更改顺序或注入恶意层）；添加、更改或删除环境变量；更改租户命令，以及从 UVM 到容器的挂载源和目标。

• 添加、删除和任意修改网络消息（即完全控制网络）。

• 请求在 UVM 和单个容器中执行任意命令。

• 从 UVM 和正在运行的容器请求调试信息，例如访问 I/O、堆栈或容器属性。

这些能力将允许攻击者在没有 Parma 保护的情况下访问访客操作系统的地址空间。

安全架构

在此威胁模型下，目标是为容器和客户数据提供强大的保密性和完整性保证。我们使用了以下原则来设计提供这些保证的安全架构。

基于硬件的 UVM 隔离

VM 的内存地址空间和磁盘必须通过硬件级隔离来防止 CSP 和其他 VM 的访问。Parma 依赖于 SEV-SNP 硬件保证，即主机系统软件无法访问 UVM 的内存地址空间。

UVM 度量

UVM、其操作系统和 guest agent 在初始化期间由 TEE 进行加密度量，租户容器可以随时通过安全通道请求此度量。AMD SEV-SNP 硬件执行度量并将其编码到签名的证明报告中。¹

可验证的执行策略

必须为租户提供一种机制来验证容器组中活动执行策略（请参阅后面关于执行策略的部分）是否是预期的策略。执行策略由租户独立定义和度量，然后提供给 CaaS 部署系统。主机度量策略（例如，使用 SHA-512）并将此度量放置在报告的不可变的主机数据中。¹ 策略本身由容器 shim 传递给 UVM，在那里它再次由租户和用户度量，以确保其度量与报告中编码为主机数据的度量相匹配。

受完整性保护的只读文件系统

任何块设备或 blob 存储都作为受完整性保护的文件系统挂载在 UVM 中。文件系统驱动程序在访问文件系统时强制执行完整性检查，确保主机系统软件无法篡改数据和容器镜像。在 Parma 中，容器文件系统表示为层的有序序列，其中每个层都作为单独的设备挂载，然后组装成 overlay 文件系统。首先，Parma 在挂载每个层时验证设备的 dm-verity 根哈希是否与策略中枚举的层匹配。其次，当容器 shim 请求挂载组装多个层设备的 overlay 文件系统时，Parma 验证层的特定排序是否在执行策略中为一个或多个容器明确列出。

加密和受完整性保护的读/写文件系统

任何保存隐私敏感数据的块设备或 blob 存储都作为加密文件系统挂载。文件系统驱动程序在访问文件系统时解密内存映射的块。解密的块存储在硬件隔离的内存空间中，确保主机系统软件无法访问明文数据。容器的可写暂存空间使用 dm-crypt 和 dm-integrity 挂载，这由执行策略强制执行。可写暂存空间的加密密钥是临时的，最初在硬件保护内存中配置，并在设备挂载后擦除。

远程证明

远程验证者（例如，租户、用户、外部服务、证明服务）需要验证证明报告，以便他们可以与在 UVM 中运行的容器组建立安全通信通道。他们还需要验证 UVM 是否启动了预期的操作系统、正确的 guest agent，以及 guest agent 是否配置了预期的执行策略。

在 Parma 中，UVM（包括特权容器）可以使用 PSP 和 UVM 之间建立的安全通道请求证明报告。¹ 请求者生成一个临时令牌，例如，TLS（传输层安全）公钥对或密封/包装公钥，该令牌作为运行时声明在报告中呈现。令牌的加密摘要被编码为报告数据。然后，远程验证者可以验证

• 报告是否已由真正的 AMD 处理器使用根植于 AMD 根证书颁发机构的密钥签名。

• 访客启动度量和主机数据是否与预期的 VM 度量和预期执行策略的摘要匹配。

• 报告数据是否与作为附加证据呈现的运行时声明的哈希摘要匹配。

一旦验证完成，信任 UVM（包括访客操作系统、guest agent 和执行策略）的远程验证者就会信任 UVM 及其中的容器组不会泄露从中生成公钥令牌的私钥（例如，TLS 私钥、密封/包装私钥）。远程验证者可以相应地使用运行时声明。例如

• TLS 公钥可用于与经过证明的容器组建立 TLS 连接。因此，远程验证者可以信任不存在重放或中间人攻击。

• 密封公钥可用于密封（通过加密）仅供经过证明的容器使用的请求或响应。

• 包装公钥可供密钥管理服务使用，以包装和发布 VM 的容器组解密远程 blob 存储所需的加密密钥。因此，远程验证者可以认为只有可信且经过证明的容器组才能解包加密密钥。图 4 说明了这个过程，这是一个典型的证明工作流程。

在图中，容器（圆圈中的密钥）尝试获取和解密用户数据，以供组中的其他容器使用。密钥之前已使用定义的密钥发布策略预置到密钥管理服务中。它遵循以下步骤：（1）UVM 中的容器请求 PSP 发布证明报告，其中包括 RSA（Rivest-Shamir-Adleman）公钥作为运行时声明。（2）报告和附加证明证据提供给证明服务，证明服务验证报告是否有效，然后提供一个证明令牌，该令牌代表平台、初始化和运行时声明。（3）最后，证明令牌提供给密钥管理服务，密钥管理服务仅在令牌的声明满足密钥发布策略声明时，才使用提供的 RSA 公钥包装的用户密钥返回给容器。

执行策略

如本文前面所述，我们不信任容器 shim，因为它可能受到攻击者的控制。这意味着容器 shim 请求 guest agent 在 UVM 内部进行的任何操作都是可疑的（有关恶意主机操作的列表，请参阅威胁模型部分）。即使容器组的当前状态有效，主机也可能选择在未来破坏它，因此证明报告不能用作访问安全用户数据的门禁。证明报告本身仅记录正在使用的 UVM 操作系统、guest agent 和容器运行时版本。它没有对主机随后将编排的容器组提出任何声明。

例如，主机可以按照证明服务预期的那样启动用户容器组，直到它获得一些期望的安全信息。然后，它可以加载一系列容器，这些容器会将容器组暴露于远程代码执行攻击。在初始化期间获得的证明报告无法防止这种情况。即使通过向 PSP¹ 提供额外的运行时数据来更新它也无济于事，因为漏洞是在外部服务使用证明报告后由主机添加的。

执行策略的概念解决了这个漏洞。执行策略由租户编写，描述了在容器组的整个生命周期中允许 guest agent 执行哪些操作。guest agent 已被更改为在执行表 1 中的任何操作之前咨询此策略，并向策略提供用于做出决策的信息。这些操作中的每一个在执行策略中都有一个相应的执行点，它将允许或拒绝该操作。在我们为保密 ACI 实现 Parma 的过程中，策略是使用 Rego 策略语言定义的。¹⁴ 在 Rego 中实现的示例执行点如图 5 所示。

表 1 中显示的策略操作是需要由执行策略强制执行的操作。每个操作都提供了命令的列出属性作为强制查询的一部分。该列表特定于我们的实现，但鉴于围绕 containerd 的标准化，它应适用于大多数场景。首先，一些操作与容器的创建有关。通过确保 guest agent 挂载的任何设备都具有策略中列出的 dm-verity 根哈希，并且它们以与特定容器一致的层顺序组合成 overlay 文件系统，我们首先确定容器文件系统是正确的。然后可以启动容器，进一步确保环境变量和启动命令符合策略，并且从 UVM 到容器的挂载是预期的（以及其他特定于容器的属性）。其他操作以类似的方式进行，约束容器 shim 对 guest agent 的控制。

我们实现的一个新颖功能是策略能够操纵其自身的元数据状态（由 guest agent 维护）。这为执行策略提供了一种经过证明的机制来构建容器组状态的表示，从而允许更复杂的交互。例如，在图 5 所示的规则中，用于挂载设备的执行点为设备创建了一个元数据条目，该条目将用于防止其他设备挂载到相同的目标路径。

对 guest agent 进行此小更改的结果是，容器组的状态空间受到状态机的限制，其中状态之间的转换对应于前面描述的操作。每个转换都是原子执行的，并附带一个执行点。

安全不变量

状态机从一个完全度量和证明的系统开始，包括执行策略及其所有执行点，信任根是 PSP 硬件（n = 1）。表 1 中强制执行的命令集旨在管理容器组中的所有状态转换。由于此策略是证明的一部分，因此初始状态的安全属性在每次转换时都会保留。

这种安全性带有一些注意事项。首先，Parma 无法保护用户免受租户已度量并包含在其策略中的受损容器的侵害。它保护租户免受 CSP 方面的恶意行为，并强制租户仅采取执行策略中明确列出的那些操作，这些操作可供用户进行度量。Parma 无法保护租户免受自身侵害。其次，提供的安全性只有在租户及其用户使用证明报告的程度上才值得。也就是说，用户必须验证从 Parma 收到的证明报告是否绑定到 UVM 和执行策略，该策略以可接受的方式使用数据。

评估

图 6 显示了来自 Nginx 基准测试的延迟直方图。表 2 中的结果来自 redis、SPEC2017 和 Triton 基准测试。redis 值是以每秒千次请求为单位的几何平均值——越高越好。此处报告的 SPEC2017 值是可报告基准测试运行的基本比率——越高越好。Nvidia Triton 的报告值是每秒推理次数——越高越好。在所有情况下，与单独使用 SEV-SNP 相比，引入 Parma 的影响可以忽略不计。

基准测试工具用于评估几种典型的容器化工作负载，以降低计算吞吐量、网络吞吐量和数据库事务速率，以确保 Parma 不会引入显着的计算开销。在所有情况下，Parma 都为容器化工作负载提供了保密性，且性能成本极低（通常比在 enclave 中运行的额外开销不到百分之一）。

使用三种配置进行了实验，如表 2 所示

• Base – 在 SEV-SNP enclave 外部运行的基线基准测试容器。

• SEV-SNP – 在 SEV-SNP enclave 中运行的相同容器。

• Parma – 再次在 enclave 中运行的相同容器，并带有经过证明的执行策略。

每个基准测试实验使用两台机器

• Dell PowerEdge R7515，配备 AMD EPYC 7543P 32 核处理器和 128 GB 内存，用于托管容器运行时。该机器运行 Windows Server 2022 Datacenter (22H2) 和 Azure Container Instances CPLAT 的离线版本（即 containerd、cri 和 hcsshim）。UVM 运行了修补版本的 5.15 Linux，其中包括 AMD 和 Microsoft 补丁，以提供 AMD SEV-SNP 增强功能。

• 基准测试客户端（以避免任何基准测试软件对评估的影响），配置相同，通过 10-Gbit 以太网连接到同一子网上的 Dell PowerEdge。该机器运行 Ubuntu 20.04，Linux 内核 5.15。

nginx

Web 服务是容器化的常见用例，因此我们使用 wrk2¹⁸ 基准测试工具对流行的 Nginx Web 服务器进行了基准测试。每个测试在 10 个线程上运行 60 秒，模拟 100 个并发用户，每秒发出 200 个请求（每个测试总共 12,000 个请求）。对三种配置中的每一种重复测试 20 次，并测量延迟。结果如图 6 所示。直方图由收集的所有延迟样本组成。正如预期的那样，引入 SEV-SNP 会导致延迟增加，并且在添加执行策略时延迟略有增加。

redis

内存中的键/值数据库 redis 为容器化计算提供了另一个有用的基准。它支持各种数据结构，例如哈希表、集合和列表。基准测试使用了提供的 redis-benchmark，其中包含 25 个并行客户端和一部分测试，结果如表 2 所示。查看所有操作的几何平均值，我们看到在 AMD SEV-SNP enclave 中运行增加了 18% 的性能开销，而使用 Parma 时又增加了 1%。性能开销可归因于大型工作集导致的 TLB 压力增加，这些工作集在 TLB 中表现出较差的时间重用，并触发页表遍历。在启用 SEV-SNP 的系统中，页表遍历会产生额外的元数据检查（在反向页表中），以确保页面确实归 VM 所有。

SPEC2017

还通过使用 SPEC2017 intspeed 基准测试¹⁵测量计算性能开销来评估 Parma。这些基准测试程序在裸机硬件上编译和运行。容器化后，为它们提供了 32 个核心和 32 GB 的内存。如表 2 所示，AMD SEV-SNP 平均增加了 13% 的性能开销，而 Parma 在此基础上又增加了不到 1%。

Nvidia Triton 推理服务器

最后，通过运行基于 Nvidia Triton 推理服务器的 ML（机器学习）推理工作负载来评估 Parma。¹² 模型（离线训练）及其参数用于通过 REST API 提供请求服务。

保密 ML 推理服务器部署在一个包含两个容器的容器组中：一个（未修改的）Triton 推理容器和一个 sidecar 容器，该 sidecar 容器使用 dm-crypt 和 dm-integrity 挂载加密的远程 blob（保存 ML 模型）。（sidecar 容器还实现了图 4 中描述的证明工作流程，以发布加密密钥。）文件系统（和预先计算的 ML 模型）可供 Triton 推理容器使用。

Nvidia 的 perf-analyzer 系统用于评估推理服务器。这允许测量由 SEV-SNP 和 Parma 引入的开销，如表 2 所示。对于三种配置（Base、SNP 和 Parma）中的每一种，运行了四个实验，其中一到四个并发客户端发出连续的推理请求。与之前一样，来自 Parma 的额外开销约为百分之一。这些开销与之前在 redis 部分中描述的 TLB 压力增加具有相同的根本原因。

结论

此处介绍的实验表明，Parma（驱动 Azure 容器实例上保密容器的架构）除了底层 TEE（即 AMD SEV-SNP）增加的性能开销外，仅增加了不到百分之一的额外性能开销。重要的是，Parma 确保了容器组所有可到达状态的安全不变量，该不变量根植于证明报告。这允许外部第三方（通过远程证明）与容器安全地通信，从而实现各种需要保密访问安全数据的容器化工作流程。公司获得了在云中运行其最保密工作流程的优势，而无需在其安全要求上妥协。租户获得灵活性、效率和可靠性；CSP 获得更多业务；用户可以信任他们的数据是私密的、保密的和安全的。

参考文献

1. Advanced Micro Devices. 2020. AMD SEV-SNP: strengthening VM isolation with integrity protection and more; https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf.

2. Bahmani, R., Brasser, F., Dessouky, G., Jauernig, P., Klimmek, M., Sadeghi, A.-R., Stapf, E. 2021. CURE: a security architecture with CUstomizable and Resilient Enclaves. In 30th Usenix Security Symposium; https://www.usenix.org/system/files/sec21summer_bahmani.pdf.

3. Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer, R., Pratt. I., Warfield, A. 2003. Xen and the art of virtualization. In Proceedings of the 19th Symposium on Operating Systems Principles, 164-177; https://dl.acm.org/doi/10.1145/945445.945462.

4. Brasser, F., Gens, D., Jauernig, P., Sadeghi, A.-R., Stapf, E. 2019. SANCTUARY: ARMing TrustZone with user-space enclaves. In Proceedings of Network and Distributed System Security Symposium; https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_01A-1_Brasser_paper.pdf.

5. Champagne, D., Lee, R. B. 2010. Scalable architectural support for trusted software. In the 16th International Symposium on High-Performance Computer Architecture; https://ieeexplore.ieee.org/document/5416657.

6. Costan, V., Lebedev, I., Devadas, S. 2016. Sanctum: minimal hardware extensions for strong software isolation. In Proceedings of the 25th Usenix Conference on Security Symposium, 857-874; https://dl.acm.org/doi/10.5555/3241094.3241161.

7. Delignat-Lavaud, A., Fournet, C., Vaswani, K., Clebsch, S., Riechert, M., Costa, M., Russinovich, M. 2023. Why should I trust your code? acmqueue 21(4); https://queue.org.cn/detail.cfm?id=3623460.

8. Evtyushkin, D., Elwell, J., Ozsoy, M., Ponomarev, D., Ghazaleh, N. A., Riley, R. 2014. Iso-X：用于硬件管理的隔离执行的灵活架构。载于第47届IEEE/国际微体系结构研讨会论文集, 190-202; https://dl.acm.org/doi/10.1109/MICRO.2014.25。

9. Kaplan, D. 2023. 云中的硬件虚拟机隔离。acmqueue 21(4); https://queue.org.cn/detail.cfm?id=3623392。

10. Lee, D., Kohlbrenner, D., Shinde, S., Asanović, K., Song, D. 2020. Keystone：用于构建可信执行环境的开放框架。载于第15届欧洲计算机系统会议论文集, 1–16; https://dl.acm.org/doi/abs/10.1145/3342195.3387532。

11. McCune, J. M., Parno, B. J., Perrig, A., Reiter, M. K., Isozaki, H. 2008. Flicker：用于TCB最小化的执行基础设施。2008. SIGOPS 操作系统评论 42(4), 315-328; https://dl.acm.org/doi/10.1145/1357010.1352625。

12. Nvidia Triton 推理服务器。Nvidia 开发者; https://developer.nvidia.com/nvidia-triton-inference-server。

13. 开放容器倡议技术监督委员会。2021. 开放容器倡议分发规范; https://specs.opencontainers.org/distribution-spec/?v=v1.0.0。

14. 开放策略代理。策略语言; https://www.openpolicyagent.org/docs/latest/policy-language/。

15. SPEC 2017. https://www.spec.org/cpu2017/。

16. Suh, G. E., Clarke, D., Gassend, B., van Dijk, M., Devadas, S. 2003. AEGIS：用于防篡改和抗篡改处理的架构。载于第17届年度国际超级计算会议论文集, 160–171; https://dl.acm.org/doi/10.1145/782814.782838。

17. Sun, H., Sun, K., Wang, Y., Jing, J., Wang, H. 2015. TrustICE：移动设备上硬件辅助的隔离计算环境。载于第45届年度IEEE/IFIP国际可靠系统和网络会议论文集, 367-378; https://dl.acm.org/doi/abs/10.1109/dsn.2015.11。

18. Tene, G. wrk2. Github; https://github.com/giltene/wrk2。

19. 英特尔。SGX。软件保护扩展。 https://software.intel.com/en-us/sgx (访问于 2019年12月13日)。

20. Cheng, P-C, Ozga, W., Valdez, E., Ahmed, S., Gu, Z., Jamjoom, H., Franke, H, 和 Bottomley, J.. Intel TDX 解密：自顶向下的方法。2023. arXiv:2303.15540

21. Li, X., Li, X., Dall, C., Gu, R., Nieh, J., Sait, Y., 和 Stockwell, G.. Arm 机密计算架构的设计与验证。载于第16届USENIX操作系统设计与实现研讨会 (OSDI 22)。加利福尼亚州卡尔斯巴德。

22. Schuster, F., Costa, M., Fournet, C., Gkantsidis, C., Peinado, M., Mainar-Ruiz, G., Russinovich, M. VC3：使用 SGX 在云中进行可信数据分析。IEEE 安全与隐私研讨会 2015. 加利福尼亚州圣何塞。

Matthew A. Johnson 是微软 Azure Research 位于英国剑桥的首席研究工程师，拥有机器学习背景，近期专注于人工智能的安全、保密性和隐私。他的工作包括 Parma 和 rego-cpp，这是 Rego 策略语言的 C++ 实现。

Stavros Volos 是微软 Azure Research 位于英国剑桥的首席研究员，他在那里从事新型可信执行和硬件/软件协同设计，以实现侧信道保护。他的一般研究兴趣在于计算机系统领域，重点是计算机体系结构和安全。

Ken Gordon 是微软 Azure Confidential Computing 位于英国剑桥的首席研究工程师。他负责 Azure 容器实例的保密方面。其他工作包括将 Google 的 Privacy Sandbox 移植到 Confidential ACI。

Sean T. Allen 在撰写本文时是微软 Azure Research 的首席研究工程师，他是 Parma 团队的核心成员。他现在是 Movable Ink 的首席工程师。

Christoph M. Wintersteiger 在撰写本文时是微软研究院剑桥分院的研究员，他的工作包括 Z3 定理证明器、Confidential Consortium Framework 和 Parma。他现在是 Imandra, Inc. 的高级计算机科学家，在那里他开发新的形式化软件验证技术和决策程序。

Sylvan Clebsch 是微软 Azure Research 位于美国德克萨斯州奥斯汀的高级首席研究工程师。他的工作包括 Confidential Consortium Framework、Verona 和 Pony 编程语言。

John Starks 是微软核心操作系统组的软件架构师。他主要从事硬件虚拟化及其在安全、资源隔离和软件兼容性方面的应用。

Manuel Costa 是微软的副总裁和杰出工程师，他在那里领导 Azure Research 的安全和隐私部门。他对推进安全和隐私、操作系统、网络和编程语言领域的最新技术感兴趣。

最初发表于 Queue vol. 22, no. 2—
在数字图书馆中评论本文

更多相关文章

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

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

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

Gobikrishna Dhanuskodi, Sudeshna Guha, Vidhya Krishnan, Aruna Manjunatha, Michael O'Connor, Rob Nertney, Phil Rogers - 创建首个机密 GPU
当今数据中心 GPU 具有悠久而传奇的 3D 图形传统。在 20 世纪 90 年代，用于 PC 和游戏机的图形芯片具有用于几何、光栅化和像素的固定流水线，使用整数和定点算术。1999 年，NVIDIA 发明了现代 GPU，它将一组可编程核心置于芯片的核心，从而能够高效地生成丰富的 3D 场景。