作者：Arm 首席应用工程师 David Brooke
原文：
Learn the architecture - Introducing Arm Confidential Compute Architecture Version 3.0
Introducing the Confidential Compute Architecture
机密计算架构简介
Hign Level设计
安全威胁模型
用法
内存安全问题
1. 概述
在本指南中，我们将探讨机密计算在现代计算平台中的作用，并解释机密计算的原理。然后，我们将介绍 Arm 机密计算架构 （Arm CCA） 如何在 Arm 计算平台中实现机密计算。
在本指南结束时，您将能够：
- 定义机密计算
- 描述一个复杂的系统信任链
- 了解 Realm 是由 Arm CCA 引入的受保护的执行环境
- 解释如何在 Arm CCA 的实现上创建、管理和执行 Realm
- 定义可信执行环境 （TEE） 和 Realm 之间的区别
- 解释 Realm 所有者如何在 Realm 中建立信任
引言
本指南假定你熟悉 Arm 异常模型和内存管理。如果您不熟悉这些主题，请阅读我们的AArch64 异常模型和AArch64 内存管理指南.
Arm CCA 的一些操作涉及虚拟机和虚拟化。如果您不熟悉这些概念，请参阅AArch64 虚拟化.
如果您不熟悉 Arm 安全概念，请参阅安全简介。
2. 什么是机密计算？
机密计算是指在基于硬件支持的可信的安全环境中运行计算任务，以此对使用中的数据进行保护。这种保护能让代码和数据免于被特权软件和硬件代理所监控和修改。
在机密计算环境中执行的任何应用程序或操作系统都将独立于系统的其他部分单独执行。任何由此种独立执行所生成或消费的数据，在没有明确许可的情况下，都不会被同一平台上的任何其他角色监视。
Arm CCA 相关要求
在 Arm CCA 系统中执行的代码不必信任在环境中执行的大型复杂软件堆栈或任何可能影响它的外围设备。例如，支持 DMA 的设备。Arm CCA 消除了与软件堆栈或硬件开发人员建立许多关系的需要。
如果安全架构师在云服务器系统上部署负载，而他们可能不知道该系统的虚拟机管理程序开发人员是谁。由于虚拟机监控程序是未知的，这可能会导致在没有 Arm CCA 的情况下对平台上的执行缺乏信任。
Arm CCA 允许应用程序开发人员安全地部署工作负载，而无需信任底层软件基础设施，例如在安全环境中运行的虚拟机管理程序或代码。
若要允许 Arm CCA，平台必须提供以下信息：
- 一个能隔离所有不可信任者的执行环境
- 一个能将该执行环境初始化为值得信任的状态的机制。此初始化要求这个执行环境有自己的信任链 (Chain of Trust)，而此信任链是独立于平台上并行使用的不可信任环境的信任链。
在本指南中，我们将解释 Arm CCA 如何通过硬件实现和软件使用来满足这些要求。
3.Arm CCA 扩展
Arm CCA 让您能在部署应用程序或虚拟机的同时，阻止例如 hypervisor 等特权软件的访问。但是，内存等资源通常由这些特权软件来管理。在这种情况下，特权软件（例如 hypervisor ）就具有访问应用程序或虚拟机内存的权限。
Arm CCA 允许虚拟机监控程序控制 VM，但删除了访问该 VM 使用的代码、寄存器状态或数据的权限。
通过创建称为 Realms 的受保护 VM 执行空间来实现分离。Realm 在代码执行和数据访问方面与正常世界完全隔离。Arm CCA 通过架构硬件扩展和固件的组合来实现这种分离。
在 Arm CCA 中，Arm 应用程序 PE 上的硬件扩展称为领域管理扩展 （RME）。RME与领域控制的专用固件（称为领域管理监视器（RMM））和异常级别3的监视器代码进行交互。
Realms
Realm 是一种 Arm CCA 环境，能被 Normal world 主机动态分配。主机是指能管理应用程序或虚拟机的监控软件。
Realm 及其所在平台的初始化状态都可以得到验证。这一过程使 Realm 的所有者能在向它提供任何机密前就建立信任。Realm 不必从控制它的非安全虚拟机管理程序继承信任。
主机可以分配和管理资源配置。主机可以管理 Realm 虚拟机操作的调度。但是，主机不能观察或修改 Realm 执行的指令。
在主机控制下，Realm 可以被创建并被销毁。可以通过主机请求添加或删除页面，其方式类似于管理任何其他非机密虚拟机的虚拟机管理程序。
为了运行 CCA 系统，需要对主机进行修改。主机继续控制非机密虚拟机，但需要与 Arm CCA 固件（特别是领域管理监视器 （RMM））进行通信。
Realm world 和 Root world
Armv8-A TrustZone 扩展拥有两个独立的环境，分别是 Secure world 和 Normal world ，支持代码的安全执行和数据的隔离。
这里 World 是由 PE 的安全状态和物理地址空间组成。PE 执行时的安全状态会决定 PE 能访问哪种物理地址空间。在安全状态下，PE 可以访问安全和非安全的物理地址空间，但是在非安全的状态下，它只能访问非安全的物理地址空间。 Normal world 一般用来指非安全的状态和非安全的物理地址空间的组合。
Arm CCA 是 Armv9-A 的一部分，引入了 Realm Management Extension (RME)。该扩展引入了两个额外的 World，分别是 Realm world 和 Root world：
Root world 引入了 Root 安全状态和 Root 物理地址空间。PE 在 Exception level 3运行时，处于 Root 安全状态。Root PA 与 Secure PA 是分开的。这是与 Armv8-A TrustZone 的主要区别，在 Armv8-A TrustZone 中，异常级别 3 代码没有专用地址空间，而是使用安全 PA。后者仍被 S_EL2/1/0 使用。监视器在 Root 世界中运行。
Realm world 与 TrustZone 技术下的安全环境类似。Realm world 包括 Realm 安全状态和 Realm PA。Realm 状态代码可以在 R_EL2, R_EL1 和 R_EL0 上执行。在 Realm world 中运行的控制固件可以访问 Normal world 中的内存，支持共享缓冲。
下图说明了四个基于 RME 的 world 以及它们与 SCR_EL3 NS 和 NSE 位之间的关系：
图 1：Arm CCA 四个 world 的位置
Root world 支持可信的启动执行和不同环境之间的切换。PE 复位到 Root world中。
Realm world 为虚拟机提供了一个与 Normal 和 Secure world 隔离的执行环境。虚拟机需要 Normal world 中主机的控制。为能全面控制 Realm 创建和执行，Arm CCA 系统将提供：
- Realm Management Extension：这是底层架构所要求的硬件扩展，让隔离的 Realm 虚拟机得以运行
- Realm Management Monitor：这属于固件的一部分，用于按照 Normal world 主机的请求来管理 Realm 的创建和执行
在 Arm CCA 硬件架构和 Arm CCA 软件架构的章节中，我们会对这些部件进行更详细的介绍。
在不支持 RME 的 PE 中的 world 切换由 SCR_EL3.NS 位控制。在切换为 Secure world 时，Exception level 3 软件设置 NS 为 0，切换为 Normal world 时设置 NS 为 1。支持 RME 的 PE 中进行 world 切换是通过在 SCR_EL3 寄存器增加一个新的 SCR_EL3.NSE 位来扩展的。
下表显示了“这些寄存器位”是如何控制四个环境之间的执行和访问：
表 1：World 控制和状态位
Arm TrustZone 扩展和 Arm RME 之间的区别
所有 Arm A系列的处理器都可以选择实施 Arm TrustZone 架构扩展。这些扩展支持开发隔离的执行和数据环境。可信操作系统（Trusted Operating System, TOS）等组件可以服务在隔离环境中执行的可信应用程序，响应 Normal world 中运行的 Rich OS 的安全服务器请求。
在 Armv8.4-A 中将虚拟化添加到安全世界中，允许您在安全环境中管理多个安全分区。此功能可以允许将多个 TOS 应用于一个系统。在S_EL2执行的安全分区管理器 （SPM） 是安全分区的管理器。SPM 具有与普通世界中的虚拟机管理程序类似的功能。
在操作中，可信操作系统通常是信任链的一部分，它由更高权限的固件验证，在某些系统中，这可能是 SPM。这意味着 TOS 依赖于与更高权限固件开发人员的关系。
有两种方法可以启动 TOS 的执行：
- 富操作系统生成，其中富操作系统进入空闲循环并执行 SMC 指令以通过监视器调用 TOS
- 针对受信任操作系统的中断。安全类型 1 中断用于执行 TOS。在正常世界执行期间断言的安全类型 1 中断通过监控器调用 TOS。
Realm 虚拟机不同于受信任的操作系统或受信任的应用程序，因为 Realm 虚拟机是由普通世界的主机控制的。在创建和内存分配等方面，Realm 虚拟机的行为与主机控制的任何其他虚拟机一样。
Realm VM 执行和 Trusted OS 执行之间的区别在于 Realm 没有启用任何物理中断。Realm 的所有中断都由虚拟机管理程序虚拟化，然后通过传递给 RMM 的命令向 Realm 发出信号。这意味着被入侵的虚拟机管理程序可能会阻止 Realm 虚拟机的执行，因此无法保证 Realm 的执行。
Realm 的执行和内存访问由控制主机软件（例如虚拟机管理程序）初始化。Realm 不必由主机验证。Realm 有一个独立的信任链，独立于正常和安全世界使用的信任链。有关更多信息，请参阅证明 。Realm 也与控制软件完全隔离。如果 Realm 是由 Host 初始化的，那么 Host 就无法查看 Realm 的数据或数据存储器。
使用 Realms 和 TOS 的主要区别在于安全执行和 Realm 执行之间的设计意图。
可信应用程序用于与系统开发关系密切的参与者（如有机硅供应商 （SiP） 和原始设备制造商 （OEM））所拥有的特定于平台的服务。
Realm 执行的目的是允许普通开发人员在系统上执行代码，而无需与计算系统中的开发人员建立复杂的业务关系。
Arm CCA 允许在普通世界宿主的控制下按需创建和销毁领域。资源可以动态地添加或检索到 Realms。
信任通常根据机密性、完整性和真实性进行定义，并在以下列表中进行了说明：
- 在机密性方面，Arm CCA 环境的代码数据或状态无法被同一设备上运行的其他软件监视，即使这个软件具有更高的特权
- 在完整性方面，Arm CCA 环境的代码数据或状态无法被同一设备上运行的其他软件修改，即便这个软件具有更高的特权
- 在真实性方面，代码或数据可被运行在同一设备上的其他软件修改，但任何改动都能被识别
可信应用程序和 TOS 为系统提供机密性、完整性和真实性。 Realm 执行可为系统提供机密性和完整性。
Arm CCA 提供的四个 world 使 Secure world 和 Realm world 之间完全隔离开。这意味着可信应用程序无需担心任何 Realm 虚拟机的执行， Realm虚拟机也无需担心任何被执行的可信应用程序。
4. Arm CCA 硬件架构
这一章节主要介绍 Realm Management Extension，即对 PE 架构的改动，使 PE 能运行 Realm。
Realm world 的要求
下图完整说明了 Realm 是如何配合 ARM CCA 系统的：
图 2： Realm world 软件执行
Realm 世界必须能够执行代码，访问内存和可信设备，与所有其他非 Root 世界和设备完全隔离。
就像安全状态一样，Realm 世界有三个异常级别，R_EL0、R_EL1 和 R_EL2。Realm 虚拟机以R_EL1和R_EL0运行。Realm Management Monitor （RMM） 在 R_EL2 中运行。RMM 在 Arm CCA 软件堆栈中进行了描述。
隔离是通过架构 Realm Management Extension 在硬件上强制实施的，它允许控制内存管理、执行以及 Realm 的上下文和数据隔离。隔离意味着通过 PE 或加密或 Realm 和 Root 环境的错误异常来阻止访问。
在下图中，隔离的 Realm 虚拟机由虚拟机管理程序在 Normal 世界中生成和控制，但物理执行在 Realm 世界中：
图 3： Realm 虚拟机执行
Realm 虚拟机的执行通过 hypervisor 命令初始化，这些命令被传达到 Monitor，然后通过 Monitor 推送到 RMM。
Monitor 在不同的 world 之间扮演着守门人的角色。它控制着 Normal，Secure 和 Realm world 之间的通道，确保各个 world 之间的隔离能一直得以维持，同时在需要的地方支持通信和控制。
Arm CCA 内存管理
实施 TrustZone 安全扩展的 Arm A 系列处理器具有两个物理地址空间 (PAS)：
- Non-Secure 物理地址空间
- Secure 物理地址空间
Realm Management Extension 增加了另外两个物理地址空间：
- Realm 物理地址空间
- Root 物理地址空间
下图描述了这些物理地址空间以及如何在工作系统中实施这些空间：
图 4：物理地址空间
不同 world 之间的 PAS 访问由硬件强制执行，见下表：
表 2：物理地址访问权限
如表所示，根状态可以访问所有物理地址空间。Root 状态允许内存在非安全 PAS 和安全或领域 PAS 之间转换（如果需要）。
为确保强制执行所有世界的隔离规则，上表中的物理内存访问控制由下游的内存管理单元 （MMU） 强制执行。此过程称为粒度保护检查 （GPC）。
每个物理内存粒度的 PAS 分配在粒度保护表 （GPT） 中进行了描述。异常级别 3 中的监控器可以动态更新 GPT，从而允许物理内存在世界之间移动。
任何访问控制冲突都会导致一种新型故障，称为粒度保护故障 （GPF）。GPC 的启用、GPT 的内容和 GPF 的路由由 Root 状态控制。
属于 Realm 的资源必须位于 Realm 拥有的内存中，也就是 Realm PAS 的一部分，以确保隔离。但是，Realm 可能需要访问非安全内存中保存的一些资源，例如启用消息传递。这意味着 Realm 需要能够访问 Realm 和非安全 PAS 中的物理地址。
任何 Realm 虚拟机都在 Realm 世界中执行，但在普通世界主机的控制下执行。Realm 虚拟机需要能够访问普通世界 PAS 和 Ream 世界 PAS 中的内存。对不同 PAS 的访问由 Realm 阶段 2 转换表中 NS 位的状态控制。
下图显示了 GPC 在虚拟地址 （VA） 到物理地址 （PA） 链中的完整阶段和位置。在此图中，TTD 是转换表描述符，GPTD 是粒度保护表描述符：
图 5：粒度保护检查
此图显示了具有 RME 的平台的虚拟地址到物理地址的转换阶段。
如需了解 stage 1 和 stage 2 转换的详细信息，请参阅 AARCH64 内存管理。但是，在这个例子中，Exception level 3 的 stage 2 页表条目定义了一个额外的位，目的是允许通过 Monitor 访问四个 PAS。这就是转换表定义中的非安全扩展（Non-secure Extension, NSE）位。
Normal world，Realm world 和 Secure world 都可以有 Exception level 1，Exception level 2 的 stage 1 转换，如有必要，Exception level 2 还可以有 stage 2 转换。
RME 在 stage 1 和 stage 2 转换过程后增加了GPC。GPC 对照 GPT 检查所有物理地址和 PAS，目的是允许访问或是产生 fault。GPT 保存Root 内存中，以确保它能与所有其他 world 隔离开。GPT 只可以通过在 Root world 运行的代码从 Monitor 代码或可信固件创建和修改。
如果非 PE 请求者连接到请求者端过滤器（如系统 MMU （SMMU）），他们也将包含在此检查中。
证明
在 Realms 中运行的代码将管理机密数据或运行机密算法。因此，该代码需要确保它运行的是真正的 Arm CCA 平台，而不是一些模拟。代码还需要知道它已正确加载且未被篡改。最后，代码还需要知道整个平台或领域没有处于可能泄露其机密的调试状态。建立此信任的过程称为证明。
证明分为两个关键部分：
- 平台证明
- 领域初始状态的证明
这两个部分组合在一起创建证明报告，领域代码可以随时请求这些报告。然后，可以使用这些报告来验证平台和领域中代码的有效性。
平台证明包括证明 Realm 背后的芯片和固件是真实的。这就对硬件提出了要求。需要使用标识预配硬件。同样，硬件需要支持对关键固件映像（如监视器、RMM 和平台中可能对安全性产生重大影响的任何其他控制器（如电源控制器）的固件的测量。
5. Arm CCA 软件架构
Arm CCA平台是由许多额外的硬件组合（如 PE 中的 RME）和固件组件（特别是 Monitor 和 Realm Management Monitor ）组成。这一章节主要介绍面向 Arm CCA 平台的软件栈。
软件栈概述
Realm 虚拟机的执行旨在与正常世界隔离，Realm 虚拟机由正常世界主机启动和控制。为了允许独立执行 Realm VM，引入了一个名为 Realm Management Monitor （RMM） 的新组件，该组件在 R_EL2 时执行。
RMM 负责管理通信和上下文切换。RMM 不会做出策略决策，例如运行哪个 Realm 或分配给 Realm 什么内存。这些决定仍由主机虚拟机管理程序决定。
RMM 通过 Realm 世界中第 2 阶段的页表将 Realm 彼此隔离开来。
RMM 直接连接到监视器，监视器还与安全世界和正常世界连接。在异常级别 3 中运行的监视器具有特定于平台的代码，这些代码必须为系统的所有受信任功能提供服务。RMM 响应特定的接口，并具有完全定义的功能来管理来自主机和领域的请求。由于此接口定义明确，因此 RMM 可以是所有 Arm CCA 系统的通用代码。
下图显示了在 Realm 世界中运行机密 Realm VM 的完整 Arm CCA 平台：
图 6： Realm 虚拟机执行
RMM 是 Realm 世界中的控制软件，它对 Normal 世界中 hypervisor 的请求做出反应，从而允许管理 Realm VM 的执行。RMM 通过 Root 环境中的 Monitor 进行通信，以控制 Realm 内存管理功能，以便在 NS PAS 和 Realm PAS 之间转换内存。
SMC 指令允许 RMM、虚拟机管理程序和 SPM 将控制权返回给监控器，并允许在所有异常级别 2 软件和监控器之间实现通信通道。下图显示了监控器与每个世界中不同控制软件之间的通信通道：
图 7：通过 SMC 通道实现 world 之间的通信
在每个 world 中，Exception level 2 执行可以通过执行 SMC 指令对 Exception level 3 的 Monitor 进行调用。SMC 指令的使用为个别 Exception 二级控制主机和 Exception level 3 Monitor之间的通信信道建立了基础。这就是 Normal world Exception level 2上的主机通过 Monitor 与 Realm world Exception level 2 上的 RMM 建立通信的方法。
Realm 管理监视器
Realm Management Monitor（RMM）是 Realm 世界的固件，用于管理 Realm 虚拟机的执行以及它们在 Normal 环境中与 hypervisor 的交互。RMM 在 Realm 世界中以异常级别 2 运行，称为 R_EL2。
RMM 在 Arm CCA 系统中有两组职责，RMM 向主机提供服务，允许主机管理 Realms，RME 还直接向 Realm 提供服务。
主机服务可以分为“策略”和“机制”区域。
对于策略功能，主机拥有所有策略决策，包括以下内容：
- 何时创建或销毁 Realm
- 何时在 Realm 中添加或删除内存
- 何时安排 Realm 的输入或输出
RMM 通过提供以下功能来支持主机策略：
- 提供操作 Realm 页表的服务，这些页表用于创建或销毁以及添加或删除 Realm 内存
- 管理 Realm 上下文。这是调度中使用的上下文保存和恢复。
- 中断支持
- PSCI 呼叫拦截。这是电源管理请求。RMM 还为 Realms 提供服务，主要是证明和加密服务。
最后，RMM 还为 Realm 维护以下安全原语：
- RMM 验证主机请求的正确性
- RMM 将 Realm 彼此隔离
RMM 规范定义了两个通信通道，允许在正常世界主机和 Realm VM 之间请求和控制所有功能。从主机到 RMM 的通信通道称为领域管理接口 （RMI）。在 RMM 和 Realm VM 之间定义的第二个通道称为 Realm 服务接口 （RSI）。RSI 是从 RMM 请求服务的通道。
在下面的章节中，我们将介绍每个接口。
Realm Management Interface
领域管理接口 （RMI） 是 RMM 和正常世界主机之间的接口。
RMI 允许正常世界虚拟机管理程序向将管理该领域的 RMM 发出指令。RMI 使用来自主机虚拟机监控程序的 SMC 调用来请求 RMM 的管理控制。
RMI 支持对 Realm 管理的控制，包括 Realm 的创建、填充、执行和销毁。
下图显示了在正常世界主机、监视器和 RMM 之间实现 RMI 的位置：
图 8： Realm Management Interface 的路径
Realm Services Interface
Realm 服务接口 （RSI） 是 Realm VM 和 RMM 之间的接口。
RSI 允许外部服务有一个通道，某些 Realm 管理操作需要从 RMM 传递到 Realm。这些服务可以包括加密服务和证明。RSI 也是从 Realm VM 到 RMM 的内存管理请求的通道。
下图显示了 RMM 和每个 Realm VM 之间 RSI 的位置：
图 9：Realm 服务接口
6.设备分配 （DA） 和内存加密上下文 （MEC）
本指南的前几节介绍了 Realm 如何提供一个与普通世界的富操作系统、Hypervisor 和 TrustZone 完全隔离的执行环境。一个 Realm 可以在初始化时得到充分的证明，以保证它的初始内容，并且它运行在基于 RME 的平台上。
在大多数操作情况下，任何 Realm 软件的执行都需要访问系统中可用的设备。默认情况下，系统中的所有设备都会被阻止访问所有 Realm 领域的内容。如果 Realm 需要使用某个设备，它必须首先证明该设备，然后向 RMM 表示同意才能授予访问权限。
此设备分配过程维护机密计算体系结构提供的安全保证。使用标准RME功能，可以保证对不支持DMA且具有固定地址范围的SoC外设的隔离。这可以使用 RMM 页表和 GPT 或完成器端 PAS 过滤器来实现，以允许或拒绝对该内存区域的访问。
但是，某些设备系统（例如根端口输入）通过单个内存区域控制和访问多个设备。这意味着仅靠内存访问控制是不够的。此外，设备可能还具有自己的缓存，需要对其进行管理。
设备分配
设备分配 （DA） 是一种允许将设备唯一分配给单个 Realm 的方法，并允许 Realm 在授予设备访问 Realm 内容之前对设备进行认证的方法。DA 可以防止 Realm 不信任的代理（包括其他 Realm 和 hypervisor）访问或控制分配的设备。这包括保护设备 MMIO 接口和设备缓存。DA 提供了一种标准机制，用于证明所有设备类型，而 RMM 对被证明的设备没有任何特殊知识，无论是静态内存映射还是 PCIe 根端口后面。PCI SR-IOV是最普遍的设备分配体系结构。
硬件设备通常支持多个接口，这些接口可以分配给各个虚拟机。主机虚拟机监控程序控制分配过程，从而生成可由特定虚拟机直接管理的设备的硬件接口。设备分配体系结构的典型属性如下：
它依赖于标准化。这使主机能够将设备分配给 VM，而无需特定于设备的驱动程序（例如 GPU 驱动程序）。
设备接口的 MMIO 可供分配给它的 VM 访问。这意味着 VM 可以直接与设备接互。主机对 MMU 进行编程以启用此功能。
来自设备接口的直接内存访问 （DMA） 可以访问 VM 的内存。主机对 SMMU 进行编程以启用此功能。
来自设备接口的中断可由 VM 处理。主机确保转发这些中断。
在引入 RME 设备分配 （RME-DA） 之前，RME 架构不允许从设备到 Realm 内存的 DMA。为了与设备交互，Realms 需要对设备接口进行编程，以允许 DMA 到非安全内存。RME-DA 是 RME 架构的补充，它克服了这一限制，并描述了如何将设备接口分配给 Realms。在功能级别上，RME-DA 具有与分配给 VM 相同的属性：
分配方法依赖于标准化，使其与设备无关。
Realm 可以访问设备接口的 MMIO。
设备接口可以对分配的 Realm 内存执行 DMA。
Realm 接受与设备接口相关的中断。
虽然 RME-DA 在功能上类似于向 VM 分配设备，但 RME-DA 也支持 Realm 安全模型。这导致了以下安全模型和安全保证：
Realm 可以根据认证过程决定是否接受设备接口进入其可信计算库 （TCB）。被 Realm 接受的设备接口可以访问 Realm 的内存。但是，任何不被 Realm 接受的设备接口都不能访问该 Realm 使用的内存区域。
所有 Realm 数据都受到保护，不会处于非安全状态。
对于支持多个接口的设备，Realm 必须信任该设备来隔离它为每个接口保存的设备上下文。
可以通过设备接口上的不受信任的通道建立和控制对设备的信任。
如果设备是离散的，并且与主机不在同一 SoC 上，则必须保护它们之间的物理链路（用于通信 Realm 转换）免受物理攻击。链路保护方案必须提供机密性、完整性和重放保护。
为了实现这种安全模型，主机体系结构必须提供必要的保护和机制。RME-DA描述了这种架构，由两部分组成：
- Arm系统架构规格：
- PCI 规格:
- TEE 设备接口安全协议 （TDISP） 规范
- 完整性和数据加密 （IDE）
设备分配的生命周期由 RMM 管理，并使用 TDSP（TEE 设备接口安全协议）实现。主机平台保护 RMM 和 Realm 免受未通过证明接受的设备的影响。
Arm 系统架构规范
RME-DA 扩展了SMMU 规范启用对 DMA 进入 Realm 内存的支持。SMMU 规范现在包含一个 Realm 编程接口。这允许 RMM 管理针对设备 DMA 到 Realm 内存的 Realm 流。这包括对下面描述的 MEC 功能的支持。
添加了对使用已翻译事务的设备的支持。这些设备在设备内本地缓存地址转换，并向内存系统提供物理地址。恶意设备接口可能会为内存提供物理地址，而该内存位于其所分配的领域边界之外。为了防止主机出现这种情况，SMMU 体系结构中添加了一个新结构，即设备权限表。这个结构将一个设备接口与一个特定的 Realm 相关联，并用于检查来自该设备接口的事务是否在其关联 Realm 的内存占用范围内。只有在支持转换事务的设备（例如 PCI-ATS）上才需要 DPT。
此外，RME-DA 扩展了RME系统架构提供对 PCI 根端口和互连的要求。这些要求标准化了 RP 功能，以实现独立于平台的 RMM，解决了 PCI TDISP 和相关规范留下的差距。看PCI TDISP 和设备认证和分配了解更多信息。RME-DA 系统架构还涵盖了 Arm 内存系统和 PCI 事务属性之间的架构映射，并定义了 RCiEP 设备的要求。
PCI TDISP 和设备认证和分配
TEE 设备接口安全协议 （TDISP） 提供了一种标准化方法来管理设备接口分配的生命周期。这个生命周期包括 Realm 对设备进行认证的能力。根据获得的数据，Realm 可以决定是否接受设备加入其可信计算库 （TCB）。TDISP 参考体系结构定义了一组组件、它们的角色和职责，以及它们可以通过它们进行通信的标准接口。下表简要总结了 TDISP 组件以及 CCA 中的相应组件。
TDISP 依赖于一组相关协议，总结如下。
设备分配流程
要通过 PCI 开始设备分配，需要将设备物理连接到主机中的根端口。
然后，TDISP 在分配角色和职责时定义参考体系结构结构和状态机。主机内部的软件实体连接到设备中的元素。主机软件实体的示例包括设备驱动程序、VM 和 TEE 安全管理器 （RMM） 。连接设备元素的示例包括设备的物理功能、受信任的设备接口和设备安全管理器。
图10 Realm World、Non-secure 和 Secure world 的异常级别
分配受信任设备接口 （TDI） 的过程是通过领域管理监视器 （RMM） 协商的。这是系统中受信任的代理，它使用 SPDM（安全协议和数据模型）、TDSP 和 ID_KM（ID 密钥管理）协议与 DSM（设备安全管理器）进行通信，以确保 Realm 能够以安全的方式访问所需的数据。
设备证明
在任何时间点，支持 TDISP 的多功能 PCIe 设备都可以将 TDI 分配给领域，将标准虚拟功能分配给非安全虚拟机。与设备关联的 PCIe 事务带有一个 T 位，对于所有与 Realm 相关的流量，该 T 位设置为 1，无论是 Realm 对 TDI MMIO 的访问，还是来自 TDI 的 DMA。与非安全 VM 或 VMM 关联的事务将 T 位设置为零。这允许硬件将需要保护的流量与其他流量区分开来，并提供检测和丢弃非法访问的机制。
将 TDI 分配给 Realm 的过程如下：
TDI 以解锁状态启动。在此状态下，VMM 可以访问和修改 TDI 的配置空间。VMM 配置 TDI 以准备分配给领域。
VMM 将控制权传递给 RMM （TSM），RMM 使用 SPDM 与 DSM 建立安全通信通道。
使用此通信通道，RMM 将 TDI 转换为锁定状态。此时，VMM 无法再更改 TDI 的配置。在此阶段，将配置 IDE。
RMM 查询 DSM 以获取 TDI 配置和设备认证信息。
RMM 将配置和身份验证信息转发到 Realm。Realm 根据这些数据决定是否接受设备加入其可信计算库 （TCB）。Realm 将其决定传达给 RMM。已检查 IDE 配置。
如果接受 TDI，RMM 将执行以下操作：
如果这是设备的第一个 TDI，则 RMM 会在 RP 和设备之间设置 IDE 流。
在 SMMU 中对 Realm 流进行编程，并将其与 Realm 的第 2 阶段页表相关联。
如果设备使用 ATS，则 DPT 也会被编程为将 TDI 可以访问的 Realm 中的颗粒与 Realm 的 VMID 相关联。
RMM 将设备转换为运行状态。此时，设备可以对 Realm 的地址空间执行 DMA。
DSM 监控 TDI 组件的配置和状态，如果在锁定配置或运行状态下检测到威胁或安全违规，则可以将 TDI 转换为错误状态。在错误状态下，TDI 无法交易，只能重置回解锁状态。作为该转换的一部分，将清除与设备中保存的 TDI 关联的任何机密信息。
ID 密钥编程
设备密钥由 IDE-KM（ID 密钥管理）协议编程。为了将 RMM 的复杂性降至最低，根端口密钥在 EL3 的监视器中编程。器件按键的编程由 RMM 执行，使用 SPDM 上的 IDE-KM。
配置 ID 流后，可以使用 TDISP 协议锁定设备，并且 VMM 无法再访问或更改设备。如果 VMM 尝试更改锁定的 TDI 的配置，则 TDI 将进入错误状态。
断开 Realm 连接
Realm 可以随时停止使用该设备，只需请求 RMM 停止使用该设备并断开其与 TCB 的连接。为此，RMM 会向 DSM 发出一条消息，请求断开连接。DSM 确保 TDI 执行以下操作：
- 中止任何现有的已接受操作。
- 完成或中止任何现有事务。
- 停止显示中断。
- 停止显示地址转换服务 （ATS） 和页面请求接口 （PRI） 请求（如果正在使用）。
此外，设备会清理与 TDI 关联的任何内部状态，并在使用 ATS 时使为该 TDI 缓存的转换无效。当这些操作竞争时，TDI 将转移回解锁状态。
内存加密上下文 （MEC）
内存加密上下文是与 MMU 分配的内存区域关联的加密配置。
MEC 是 Arm 领域管理扩展 （RME） 的扩展。RME系统架构要求对 Realm、Secure 和 Root PAS 进行加密。与这些 PAS 中的每一个一起使用的加密密钥或调整或加密上下文在该 PAS 中是全局的。因此，举例来说，对于 Realm PAS，所有的 Realm 内存都使用相同的加密上下文。在 MEC 中，这个概念得到了扩展，特别是对于 Realm PAS，我们允许每个 Realm 都有一个唯一的加密上下文。这为RME中已经提供的隔离提供了额外的深度防御。Realms 和 RMM 本身都可以有单独的加密。
MECID 正在识别与不同内存加密上下文关联的标记。MECID 被分配给系统中的不同软件实体，例如 Realms 或 RMM。如下图所示，其中每个 Realm 都有一个单独的 MECID：
图11. 非 MEC 和 MEC 之间的比较
MECID 本身不是系统全局标识符。要成为系统全局标识符，它们必须与物理地址 （PA） 空间相关联。
MECID 由软件（Realm PAS 的 RMM）使用系统寄存器值和页表位的组合进行分配。MEC 允许软件主体、领域和 RMM 使用多个 MECID 寄存器，页表位用于选择哪个 MECID 寄存器适用于映射到该软件主体的特定内存区域。例如，这使得 RMM 能够使用一个 MECID 寄存器来管理它自己的数据结构，并使用另一个寄存器来管理它当前管理的 Realm 的数据结构，例如 Realm 的阶段页表。对于一个 Realm 来说，拥有多个 MECID 寄存器意味着它可以与其他 Realm 共享加密的 Realm PAS 内存。这意味着可以为内存空间分配一个内存加密上下文，该上下文可以在多个 Realm 之间共享，以允许这些 Realm 共享加密内存。此外，来自任何具有 MECID 的实体的每个高级微控制器总线架构 （AMBA） 事务都使用该实体的 MECID 属性进行注释。
当执行涉及与 MECID 关联的内存区域的事务时，MECID 用于检索用于加密或解密事务的调整或加密密钥（加密上下文）。加密密钥是修改加密操作的数据。在系统启动时，内存保护引擎 （MPE） 会生成并存储一组加密上下文。这些上下文由 MECID 索引，当系统中的其他实体重用 MECID 时，可以从根世界的请求进行更新。
MECID 大小介于 1 到 16 位之间，在体系结构上是可发现的。MECID 的大小意味着它们太小而无法用作调整。由于 MECID 的大小是有限的，这意味着在正在运行的系统的生命周期内，MECID 将在系统中的不同实体之间重复使用。因此，MECID 的每个分配只有在 MECID 的关联加密上下文失效后才能发生，然后才能重新生成。
MEC 加密密钥只能存储在一次性写入寄存器中，只能由 Root 请求访问。重置密钥后，必须将该值设置为不同于所有其他活动 MEC 加密密钥的默认值。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达，可以在下面评论区评论
