PDF云中的硬件 VM 隔离
利用 AMD SEV-SNP 技术实现机密计算
David Kaplan
当您租用公寓时，有权对隐私抱有一定的期望是合理的。房东为您提供住宿场所以换取租金，您不希望房东窥探您的物品、在您的卧室里安装摄像头等。当您在云中租用 VM（虚拟机）时，为什么期望应该有所不同呢？
公共云提供了一项重要的服务，即提供计算能力以换取金钱。虽然云提供商可以说尽力隔离您的数据，特别是与其他租户隔离，但通常在硬件中没有任何东西可以真正将您的所有数据与提供商自身隔离。诸如网络加密和加密硬盘之类的标准技术可以分别保护传输中的数据和静态数据，但这些技术不能保护正在主动处理的数据（即使用中的数据）。云提供商软件中的错误、恶意内部人员或意外的崩溃转储都可能以通常无法检测到的方式泄露您的私有数据。这些风险使许多行业无法迁移到云端……直到现在，这要归功于一种名为“机密计算”的新技术。
虚拟机的机密计算
机密计算16 是一个通用术语，用于描述旨在保护 VM 等工作负载免受所有其他软件（包括 HV（hypervisor，虚拟机监控程序））侵害的技术。这与 CPU 的传统信任模型有很大的不同。从历史上看，CPU 的构建使用的是基于环的安全模型，其中较高特权环可以访问较低特权环中的所有内容。这对于操作系统和许多典型环境非常有效。
借助机密计算，此模型进行了修改，使得管理员代码（例如 HV）在管理系统资源和调度的同时，不再拥有对系统的完全访问权限。例如，HV 可能会选择运行一个 VM 还是另一个 VM，以及为每个 VM 分配多少内存，但它无法查看或修改该内存的内容。
机密计算在工作负载所有者与物理机器所有者不同的环境中非常有用。这可能是因为您对安全有意识，或者担心其他租户利用云基础设施中的漏洞的风险，或者仅仅是因为 VM 中数据的类型。客户数据、财务信息、健康信息等都是高度敏感的，并且通常受到严格的监管或合规性控制。机密计算降低了这些数据在云中泄露的风险。
AMD SEV-SNP 概述
AMD 于 2017 年首次推出 SEV（安全加密虚拟化）12 技术，开始提供对机密计算的支持。SEV 技术随着时间的推移不断发展，以支持更高的安全性和灵活性。本文重点介绍该技术的第三代，称为具有安全嵌套分页功能的 SEV，或 SEV-SNP。AMD SEV-SNP1 可在第三代及更高版本的 AMD EPYC 处理器中使用，这些处理器于 2021 年初开始出货。
SEV-SNP 利用现有的 AMD-V 技术，该技术为虚拟化提供特殊的硬件支持和加速。SEV-SNP 旨在保护 VM 免受所有外部实体（包括裸机虚拟机监控程序、BIOS（基本输入/输出系统）、其他 VM，甚至外部 I/O 设备）的侵害。虽然 SEV-SNP 需要操作系统和 HV 级别的特殊软件支持，但它不需要对应用程序进行任何更改。今天在云 VM 中运行的 Web 服务器可以轻松地移动到 SEV-SNP VM 中，而无需重新编译，这通常被称为“lift-and-shift”（直接迁移）。
SEV-SNP 的基础知识
SEV-SNP 支持机密计算的几个关键原则，包括对机密性、完整性和证明的需求。对机密性的需求应该是显而易见的，因为它在机密计算的名称中。实际上，这意味着限制对 SEV-SNP VM 内部数据的访问。这主要是通过内存加密来实现的，如图 1 所示。AMD EPYC 处理器在每个片上内存控制器中都包含一个高带宽 AES-128（或第四代 AMD EPYC 中的 AES-256）加密引擎。该引擎旨在快速加密/解密 CPU 和 DRAM（动态随机存取存储器）之间的所有数据。每个 SEV-SNP VM 在 VM 启动时都会分配一个唯一的随机加密密钥，并且硬件严格控制该密钥的使用，确保只有正确的 VM 才能看到明文。
虽然 VM 内部的大多数数据通常应保持私有，但 VM 有时确实需要与 HV 或设备通信。在 SEV-SNP 架构中，这是通过共享内存页完成的。VM 可以使用页表位（C 位或加密位）选择哪些内存页是私有的或共享的。私有页（C 位=1）始终使用 VM 特定的加密密钥加密，而共享页（C 位=0）可以使用未加密或使用 HV 密钥加密。
SEV-SNP 的另一个关键原则是数据完整性，这意味着确保不受信任的代码（如 HV）不得以任何方式修改访客内存。即使访客内存已加密，攻击者也可能尝试破坏它或执行重放攻击，使用旧的密文副本替换较新的版本，从而使访客看起来像是看到了旧版本的数据。SEV-SNP 架构使用名为 RMP（反向映射表）的结构在访客私有页上强制执行数据完整性。
反向映射表
在 AMD 系统中，内存通过 CPU 指令或设备 I/O（称为 DMA（直接内存访问））访问。CPU 访问使用内部 MMU（内存管理单元），而 DMA 使用 IOMMU（I/O 内存管理单元）。MMU 和 IOMMU 都在访问内存之前使用页表将虚拟地址转换为物理地址。在 SEV-SNP 架构中，HV 控制页表和到物理地址空间中地址的映射，但 RMP 在物理地址空间中强制执行访问控制。
RMP 是一个大型内存数据结构，用于跟踪每个内存页的所有者。DRAM 的每个 4KB 页都与一个 16 字节的 RMP 条目关联。该 RMP 条目指示谁有权写入该页。在任何给定时间，内存都可能分配给特定的访客或 HV，甚至保留供硬件使用。RMP 永远不会被软件直接修改；它只能通过受信任的方式（例如特殊的 x86 CPU 指令）进行操作。
RMP 用于强制执行对系统中内存页的访问控制。当 CPU 或 IOMMU 将虚拟地址转换为物理地址时，通常在转换结束时执行 RMP 检查。软件或设备想要访问的物理地址用于索引到 RMP 中，然后验证分配的所有者是否是要尝试访问该页的所有者。如果此检查失败，则会生成错误并阻止访问。
例如，要将内存页添加到访客，HV 将发出 RMPUPDATE x86 指令。此指令修改 RMP，使特定的内存页现在分配给特定 GPA（访客物理地址）的特定访客。完成此操作后，HV 将无法再写入该内存页。如果它尝试这样做，CPU 将发出页错误。
RMP 之所以是反向映射，是因为对于访客内存，RMP 条目包含 GPA 和 ASID（地址空间 ID），该页已分配给该 GPA 和 ASID。这确保了恶意 HV 无法尝试将页面映射到访客地址空间中的错误位置。
当 CPU 运行 SEV-SNP 访客时，在使用嵌套分页将 GVA（访客虚拟地址）转换为 GPA，然后再转换为系统物理地址后，将读取并检查 RMP 条目，如图 2 所示。RMP 条目必须包含在页表遍历期间使用的正确 GPA，这验证了转换的正确性。
其他保护
内存加密和 RMP 为 SEV-SNP VM 提供了大量的机密性和完整性保护，但这并不是全部。SEV-SNP 旨在保护 VM 免受恶意 HV、恶意设备等的侵害。当然，云提供商可能并不打算恶意，但机密计算的目的是在所有情况下都受到保护。毕竟，良性软件可以通过简单的远程代码漏洞利用而变得恶意。
保护免受潜在恶意虚拟机监控程序的其他安全措施的一个示例是 SEV-SNP VM 选择加入各种中断安全模式的能力。通常，对于诸如模拟设备之类的事情发生的中断由 HV 注入到访客 VM 中，这是完全正常的。但是，如果 HV 在 VM 屏蔽中断时恶意注入中断会发生什么？当然，这不是预期的行为，但“意外行为”正是攻击者垂涎三尺的东西。
SEV-SNP 提供的一种中断安全模式是“限制注入”。在此模式下，HV 被阻止向访客注入任何中断或异常，除了一个特定的向量，称为 #HV。当注入 #HV 时，访客使用特殊协议3 来查明虚拟机监控程序想要发送的底层中断或异常。然后，访客可以决定立即处理该事件或将其推迟到以后。通过这样做，访客可以有效地模拟自己的中断控制器，确保在正确的时间处理中断，而无需依赖 HV。
诸如 Spectre 之类的侧信道攻击是另一种潜在威胁，可能会破坏诸如 SEV-SNP 之类技术的隔离承诺。因此，SEV-SNP 提供了特殊的模式，例如，隔离分支预测器，以便 VM 可以免受某些类型的侧信道攻击。
当然，机密计算并非万能的侧信道保护方案。对于最佳安全级别，仍然需要诸如恒定时间加密和避免依赖于秘密的分支之类的最佳实践。
证明
诸如 SEV-SNP 之类的技术可以隔离 VM，确保数据机密性和完整性……但是您如何知道云实际上已启用该功能？您又如何知道云提供商是否已在其系统上安装了最新的固件或微代码补丁？这就是证明发挥作用的地方。
证明是证明的另一种说法——它是证明您是您所说的人，或者某事物实际上是它看起来的样子。它涉及受信任的人员证明（“证明”）其他人是安全的。
在诸如 SEV-SNP 之类的机密计算技术中，云提供商是不受信任的，因此唯一可以证明 VM 安全性的实体是芯片提供商自身。在 SEV-SNP 中，此服务由称为 ASP（AMD 安全处理器）的片上实体提供。
ASP 是处理器的一部分，但与 x86 CPU 分开的专用微控制器。它有自己的资源，包括熔丝、SRAM、加密硬件等。ASP 运行 AMD 签名固件，并提供许多服务来帮助管理 SEV-SNP VM 的生命周期。这些服务记录在公共规范4 中，用于创建/销毁 SEV-SNP VM、执行诸如内存交换或实时迁移之类的任务，当然，还用于提供证明。
在 SEV-SNP 中，与 VM 关联的初始代码和数据不是秘密的。为了创建安全的 VM，HV 向 ASP 提供此初始代码和数据，这通常是访客 BIOS 映像，例如 OVMF（开放虚拟机固件）。通常，安全 VM 使用加密硬盘，因此为了成功启动，它需要解锁对该硬盘的访问权限。该硬盘的密钥可能位于其他某个密钥服务器上。这就是证明可以发挥作用的地方。
为了请求磁盘解密密钥，新的 VM 必须向密钥服务器证明自己。它不仅必须表明 VM 是它所说的 VM，还必须证明它在安全环境中运行，并且其映像未被以任何方式篡改。
ASP 在 SEV-SNP 访客 VM 请求时生成证明报告，如图 3 所示。此证明报告包含有关 VM 和平台本身的大量信息，例如 VM 的初始代码和数据的测量值（即哈希值）、有关 VM 身份的信息、与当前加载的固件关联的版本号等。
整个报告都使用称为 VCEK（版本化芯片背书密钥）的特殊密钥进行签名。VCEK 对于每个 AMD CPU 都是唯一的，并且是使用当前版本的可变 ASP 固件和 CPU 微代码以加密方式派生的。构建此功能是为了让查看报告的人员可以确信该报告是由特定版本的固件签名的，而不是较旧的版本试图伪装成较新的版本。这一点尤其重要，因为当研究人员在 SEV-SNP 等功能中发现错误时，AMD 通常会发布固件或 CPU 微代码更新来解决这些问题。
这一切如何结合在一起与密钥服务器对话以进行安全 VM 启动？证明报告中的字段之一是包含任意访客提供的数据的 512 位字段。一个典型的用例可能涉及访客 VM 创建一个公钥/私钥对，并提供其公钥的哈希值以包含在证明报告中。如果验证方通过证明报告中的所有必需的安全检查，则可以使用该公钥与访客安全地通信。
除了验证证明报告中的数据外，验证方还必须检查报告的签名。它应该使用适当的 VCEK 进行签名——但是验证者如何知道它可以信任该 VCEK 呢？为了帮助解决这个问题，AMD 创建了 KDS（密钥分发服务），该服务提供可以证明 VCEK 是真实有效的证书。KDS 集成到 AMD 的制造流程中，因此 AMD 仅为真实的 AMD 部件签署证书。（有关此内容的更多详细信息，请参阅 VCEK 证书和 KDS 接口规范。）5 可以在 GitHub 上找到一个可用于协助 SEV-SNP 证明的示例工具。18
VM 内的安全
到目前为止，本文重点介绍了保护 VM 免受虚拟机监控程序和其他主机软件的侵害。但是 VM 通常也需要执行其自身的内部安全。例如，在裸机系统上，UEFI（统一可扩展固件接口）安全启动可能会使用 TPM（可信平台模块）芯片来计算启动流程的度量值，以确保免受诸如 rootkit 之类的攻击。在虚拟化系统中，TPM 可以由 HV 模拟。这在无法信任 HV 模拟 TPM 的机密环境中如何工作？
为了帮助完成此类任务，SEV-SNP 提供了一种称为 VMPL（虚拟机特权级别）的功能，该功能允许额外的安全控制，可以保护访客内部的内存免受同一访客内部的其他代码的侵害。每个 SEV-SNP 访客最多可以有四个 VMPL，其中 VMPL0 的特权最高，而 VMPL3 的特权最低。每个硬件上下文（称为 VMSA（虚拟机保存区））都与一个 VMPL 关联，并且分配给访客的每个内存页都可能具有基于 VMPL 的不同权限。VMPL0 始终具有对访客地址空间中每个页面的完全访问权限，但它可以配置某些页面在例如 VMPL1 处不可访问，或者可能允许只读访问。
VMPL 的一个用例是以 VMPL0 运行 AMD 所谓的 SVSM（安全 VM 服务模块）：一小段代码，旨在为访客的其余部分提供安全服务。例如，COCONUT8 是用 Rust 编写的 SVSM，它在 VMPL0 中运行，而 Linux 操作系统的其余部分在 VMPL1 中运行。
SVSM 可以做的一件事是向访客提供 vTPM（虚拟 TPM）服务。vTPM 对访客中的操作系统显示为正常的 TPM，并启用诸如 UEFI 安全启动之类的功能。但是，由于 vTPM 在 VMPL0 中运行，因此它可以使用受保护免受访客操作系统侵害的内存，因此访客中的任何恶意软件都无法破坏 vTPM 状态。而且，别忘了整个访客都在 SEV-SNP 下运行，因此它也受到 HV 或其他 VM 试图破坏其状态的保护。
诸如 vTPM 之类的服务也很有用，因为它们可以向连接到该 VM 的用户证明 VM 的安全性。vTPM 可以证明 VM 中运行的软件的安全性，而 SEV-SNP 证明报告则证明 vTPM 本身和 VM 配置的安全性。
AMD 正在与开源社区合作，以进一步开发 SVSM，并最终通过 SVSM 支持诸如加速实时迁移之类的功能以及可能的其他服务。
最后，SEV-SNP 架构还支持 paravisor 的概念，它可以帮助运行几乎不了解 SEV-SNP 的访客操作系统。这是一个小型但受信任的层，位于大部分未修改的旧版访客操作系统和 HV 之间。即使访客操作系统实际上对机密计算一无所知，paravisor 也会处理与 SEV-SNP 关联的所有新的安全协议。
例如，Microsoft 在 Azure 中使用自定义 paravisor，该 paravisor 利用 SEV-SNP VMPL 技术来支持客户以最小的努力将现有工作负载迁移到机密云。14 此 paravisor 支持与 Windows 和 Linux 的兼容性，并提供安全启动服务、安全中断传递等。像这样的技术通过使安全性更容易采用而无需更改客户软件堆栈，从而扩展了机密计算的范围。
安全成本
安全永远不会免费，但是诸如 SEV-SNP 之类的机密计算技术会尽力最大程度地减少安全开销。SEV-SNP 使用高带宽 AES（高级加密标准）内存加密引擎、多级 TLB（转换后备缓冲区）和其他微架构优化，以减少维护机密计算环境所需的额外安全检查的性能影响。
因此，在许多工作负载中，SEV-SNP 的性能成本都非常低。例如，第三代 AMD EPYC 处理器在估计的 SPECrate 2017_int_base17 上仅表现出约 4% 的差异，在服务器端 Java 性能基准测试中为 2%，在 Black-Scholes 基准测试中为 2%。9 这些成本主要是 AES 内存加密和 RMP 安全检查的影响结果。随着时间的推移，AMD 预计这些性能差异可能会进一步缩小。当然，实际工作负载的实际性能取决于许多因素，包括硬件配置、VM 及其资源的放置、软件优化等。
保护设备 I/O 的安全
随着每一代 SEV 的发展，该技术不断发展以增加更多的安全功能、功能和改进的性能。AMD 最近宣布了 SEV 的下一个重大演进，即新的 SEV-TIO（具有可信 I/O 的 SEV）技术。2 SEV-TIO 为直接设备分配给 SEV-SNP VM 提供支持，从而允许安全 VM 和物理设备以快速安全的方式进行通信。
SEV-TIO 构建于多项行业标准之上，包括 PCIe 的 TDISP（TEE 设备接口安全协议）15、IDE（完整性和数据加密）11、SPDM（安全协议和数据模型）10 等。它在设备（例如设备上的虚拟功能）和特定的 SEV-SNP VM 之间提供安全链接。
此安全链接意味着 VM 和设备之间的通信同时具有机密性和完整性。它为设备向访客 VM 证明身份提供了一种方式，因此访客 VM 可以避免与恶意设备交互。最重要的是，它支持高性能 DMA，而无需反弹缓冲。
在 AMD SEV-TIO 之前，所有设备通信都必须通过共享（未加密）内存页进行。这意味着 VM 必须获取它想要发送到设备的数据，将其复制到 C 位=0 的页面中，然后要求设备从那里获取它。如果您执行大量 I/O，则额外的内存复制可能会非常昂贵。借助 SEV-TIO，一旦访客验证了设备的证明并确定它是可信的，它就可以允许设备直接 DMA 到访客私有（加密）内存；不再需要内存复制。
此外，由于 C 位=0 页中的任何数据都对 HV 可见，因此 VM 要发送到设备的任何秘密都必须在通过 DMA 发送之前在软件中加密。借助 SEV-TIO，不再严格需要此软件加密，因为设备读取和写入的数据可以以 C 位=1 的页面为目标。
SEV-TIO 旨在与符合 TDISP 和相关标准的任何设备一起使用。这可能包括 SmartNIC（智能网络接口卡），它可以卸载网络和存储工作；AI 训练加速器；等等。虽然并非每个工作负载都可能需要直接设备分配提供的 I/O 安全性和性能，但 SEV-TIO 将机密计算的范围扩展到 I/O 敏感型工作负载。
结论
机密计算是一种非常适合公共云的安全模型。它使客户可以租用 VM，同时享受基于硬件的隔离，从而确保云提供商不会有意或无意地查看或损坏其数据。SEV-SNP 是第一个商业上可用的 x86 技术，可为云提供 VM 隔离（包括机密性和完整性），并且已部署在 Microsoft Azure7、AWS6 和 Google Cloud19 中。随着诸如 SEV-SNP 之类的机密计算技术的发展，机密计算很可能只会成为云的默认信任模型。
参考文献
1. AMD。2020 年。AMD SEV-SNP：通过完整性保护等功能加强 VM 隔离。AMD 白皮书； https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf。
2. AMD。2023 年。AMD SEV-TIO：用于安全加密虚拟化的可信 I/O。AMD 白皮书； https://www.amd.com/content/dam/amd/en/documents/developer/sev-tio-whitepaper.pdf。
3. AMD。2023 年。SEV-ES 访客虚拟机监控程序通信块标准化； https://www.amd.com/system/files/TechDocs/56421-guest-hypervisor-communication-block-standardization.pdf。
4. AMD。2022 年。SEV 安全嵌套分页固件 ABI 规范； https://www.amd.com/system/files/TechDocs/56860.pdf。
5. AMD。2023 年。版本化芯片背书密钥 (VCEK) 证书和 KDS 接口规范； https://www.amd.com/system/files/TechDocs/57230.pdf。
6. AWS。2023 年。Amazon EC2 现在支持 AMD SEV-SNP； https://aws.amazon.com/about-aws/whats-new/2023/04/amazon-ec2-amd-sev-snp/。
7. Cai, R.。2022 年。使用 SEV-SNP (DCasv5/ECasv5) 的 Azure 机密 VM 现已正式上市。Microsoft Azure 机密计算博客； https://techcommunity.microsoft.com/t5/azure-confidential-computing/azure-confidential-vms-using-sev-snp-dcasv5-ecasv5-are-now/ba-p/3573747。
8. COCONUT 安全 VM 服务模块； https://github.com/coconut-svsm/svsm。
9. Comp, L.。2021 年。由第三代 EPYC CPU 驱动的 Microsoft Azure 机密计算。AMD； https://community.amd.com/t5/epyc-processors/microsoft-azure-confidential-computing-powered-by-3rd-gen-epyc/ba-p/497796。
10. DMTF。2023 年。DSP0274 的所有已发布版本； https://www.dmtf.org/dsp/DSP0274。
11. Harriman, D.。2022 年。完整性和数据加密以及 IO 安全更新。PCI-SIG； https://pcisig.com/blog/integrity-and-data-encryption-ide-and-io-security-updates。
12. Kaplan, D.、Powell, J.、Woller, T.。2021 年。AMD 内存加密。AMD 白皮书； https://www.amd.com/system/files/TechDocs/memory-encryption-white-paper.pdf。
13. Linux SVSM； https://github.com/AMDESE/linux-svsm。
14. Perez-Vargas, C.。2023 年。Azure 上的机密 VM。Microsoft Windows OS 平台博客； https://techcommunity.microsoft.com/t5/windows-os-platform-blog/confidential-vms-on-azure/ba-p/3836282。
15. PCI-SIG。2022 年。TEE 设备接口安全协议； https://pcisig.com/tee-device-interface-security-protocol-tdisp。
16. Russinovich, M. 等人。2021 年。迈向机密云计算。 通讯 64 (6), 54–61; https://dl.acm.org/doi/10.1145/3453930。
17. 有关 SPEC® 基准测试的更多信息，请参阅 https://www.spec.org。
18. VirTEE； https://github.com/virtee/。
19. Young, J.。2023 年。哦 SNP！VM 变得更加机密。Google Cloud 博客； https://cloud.google.com/blog/products/identity-security/rsa-snp-vm-more-confidential。
David Kaplan 是 AMD 的高级研究员，他是 AMD 安全加密虚拟化技术的首席架构师，隶属于 AMD 产品安全办公室。Kaplan 在 AMD 拥有超过 17 年的经验，并且在过去 10 年中一直从事机密计算工作。到目前为止，他已提交了 50 多项专利，并拥有伊利诺伊大学的理学学士学位。
版权所有 © 2023，所有者/作者所有。出版权已许可给 。
最初发表于 Queue vol. 21, no. 4—
在 数字图书馆 中评论本文
更多相关文章
Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用机密联邦学习实现可信赖的 AI
安全性、隐私性、问责制、透明度和公平性原则是现代 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 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要在平台硬件和软件方面进行创新，但是这些创新有可能增强对计算的信任，尤其是在第三方拥有或控制的设备上。机密计算的早期消费者将需要自行决定他们选择信任的平台。
© 保留所有权利。