ARMv9-机密计算架构(CCA)深入理解

• 1 概述
  
• 2 背景知识
  
• 3 什么是机密计算
  
• 4 ARM CCA扩展
  
• 5 CCA硬件架构
  
• 6 CCA软件架构
  
• 7 问题
  

1 概述

在本文中，我们看一下现代计算系统中机密计算的角色，以及实现原理。然后，描述了ARM的机密计算架构（CCA）如何在ARM硬件平台上实现机密计算。

通过本文，能够学习到：

• 什么是机密计算
  
• 描述一个复杂的可信链
  
• 理解Realm是ARM的CCA架构引入的受保护的执行环境
  
• 知道Realm VM虚拟机如何在CCA架构中，创建、管理和执行
  
• TEE环境和Realm环境的差异
  
• 如何在Realm空间中建立可信环境

2 背景知识

本文假设你已经熟悉ARM架构的异常模型和内存管理模型。如果不熟悉，请参考ARM官方文档AArch64 Exception model和AArch64 Memory management guides。

CCA架构的操作涉及到虚拟机和虚拟化的知识。如果不熟悉这些概念，请参考AArch64 virtualization。

如果不熟悉ARM安全知识，请参考Introduction to security。

3 什么是机密计算？

机密计算是通过在硬件支撑的安全可信环境中执行计算，进而保护使用的数据的一种手段。这种保护使代码和数据免于特权软件和硬件固件的观察和修改。

机密计算环境中的应用和操作系统期望执行环境与系统中的其它非可信组件隔离开。在没有显式授权的情况下，平台的其它组件都不能访问机密计算环境中的数据。

3.1 ARM CCA架构的条件

ARM CCA系统不需要信任大型、复杂的软件栈或可能影响它的外设（如DMA访问的设备）。这样，ARM CCA就尽量削减了和软件栈、硬件开发者之间的关系。

假设一种场景：安全架构师将工作负载部署到一个云服务器上，如果不知道hypervisor的开发者是谁，他可能不敢使用。因为hypervisor是未知的，这可能导致架构师对执行环境缺乏安全感。这时候，就需要考虑ARM CCA架构了。

ARM CCA架构允许安全架构师将工作负载安全地部署到云服务器上，而无需考虑底层代码的可信度。底层代码包括hypervisor或运行在安全空间的代码。

想要使用CCA架构，系统必须提供：

• 提供隔离不信任组件的执行环境；
  
• 提供一种机制，建立执行环境，并初始化为可信任状态的环境。
  

在本文中，我们将阐述ARM CCA架构如何通过硬件和软件满足这些条件。

4 ARM CCA扩展

ARM CCA架构允许部署应用或虚拟机（VM），而阻止特权软件（如hypervisor）访问。但是，通常情况下，正是这些特权软件管理着资源，比如内存等。这种情况下，特权软件确实可以访问应用程序或虚拟机（VM）的内存。

ARM CCA允许hypervisor控制VM，但是剥夺了其访问VM的代码、寄存器和数据的权力。

隔离是通过创建受保护的VM执行空间实现的，这个空间称为Realm。Realm在代码执行和数据访问上与正常空间完全隔离。ARM CCA架构是通过硬件扩展和特殊固件达到的这种隔离。

在ARM CCA架构中，这种硬件扩展成为Realm 管理扩展(RME)。RME与特殊的固件交互，这个固件称为Realm管理监控器(RMM)。

4.1 Realm空间

Realm是ARM的CCA环境，可以被正常空间的Host动态分配。Host是管理应用程序或虚拟机（VM）的监控程序。

后面为了方便理解，我们以hypervisor作为Host进行阐述。

Realm和硬件平台的初始状态可以被认证。认证可以保证在使用Realm运行机密计算之前，建立可信的Realm环境。所以，Realm空间无需从非安全空间的hypervisor继承信任。

hypervisor负责资源分配和管理，Realm空间虚拟机的调度管理。但是，hypervisor不能观察或修改Realm中执行的指令。

同样，hypervisor负责创建和销毁Realm的虚拟机空间，同时还要负责申请和释放内存页。

为了支持CCA架构，hypervisor需要修改。除了继续保留原有的功能，也就是管理、控制非机密计算的虚拟机之外，还需要与CCA架构的固件（尤其是RMM）进行通信。

4.2 Realm空间和Root空间

ARMv8-A架构的TrustZone扩展提供了安全、非安全空间。这儿的空间指的是PE的安全状态和物理地址空间的组合。PE执行的安全状态决定了PE可以访问的物理地址空间。在安全状态下，PE可以访问安全、非安全物理地址空间，而在非安全状态下，它只能访问非安全物理地址空间。正常空间通常指的是非安全状态和非安全物理地址空间的组合。

CCA架构作为ARMv9-A的一部分，引入RME（Realm管理扩展）。该扩展引入了两个额外的空间，Realm空间和root空间。

• Root空间是Root安全状态和Root物理地址空间的组合。此时的PE运行在EL3异常级别。特别需要注意的是，Root空间的物理地址空间与安全空间的物理地址空间是隔离的。这是与ARMv8-A的TrustZone主要的不同，TrustZone中EL3的代码没有专门的物理地址空间，而是使用安全空间的物理地址。现在，TrustZone应用代码运行在S_EL2/1/0，Monitor运行在root空间中，也就是EL3。
  
• Realm空间类似于TrustZone的安全空间。Realm空间由Realm安全状态和物理地址空间组成。Realm的代码运行在R_EL2、R_EL1和R_EL0。运行在Realm空间的监控软件可以访问正常空间的内存，这样，可以建立共享缓存。
  

下图展示了四个空间，以及它们与SCR_EL3的NS、NSE标志位的关系：

Root空间允许可信的引导启动和在不同空间进行切换。PE复位后，进入Root空间。

Realm空间提供了VM的执行环境，这些VM与正常、安全空间隔离开。Realm中的VM需要正常空间中的hypervisor进行控制。为此，CCA需要提供：

• RME，架构所需要的硬件扩展，提供Realm VM执行的隔离环境；
  
• RMM，架构所需要的软件，用来管理hypervisor发来的Realm创建、执行的请求。
  

在没有RME扩展的时候，空间的切换是通过SCR_EL3.NS标志位完成的。切换到安全空间时，EL3的软件设置NS = 0；切换到非安全空间时，设置NS = 1。添加了RME扩展后，增加了SCR_EL3.NSE标志位。下表是标志位和四个空间的切换关系：

4.3 TrustZone和Realm的差异

所有ARM-A架构规范中，TrustZone都是作为一个扩展选项存在。该扩展为代码和数据提供了一个安全可信的隔离环境。

从ARMv8.4-A架构开始，安全空间也添加了虚拟化的支持，允许在安全空间中管理多个安全分区，从而运行多个可信OS。运行在S_EL2的安全分区管理器（SPM），负责安全分区的管理工作。SPM就类似于正常空间中的hypervisor。

实际系统中，可信操作系统（TOS）是可信链中的一环，它由更高特权的固件程序进行验证，某些系统中，这些特权固件就是SPM。这意味着TOS的开发依赖于更高特权级别的固件开发者。

有两种方法启动TOS的执行：

• Rich OS进入空闲状态，调用SMC指令，通过Monitor调用TOS;（Rich OS通常指Linux、Windows、Android）
  
• TOS的专用中断。安全类型-1的中断用于TOS的执行。在正常空间断言的安全类型-1中断通过Monitor调用TOS。
  

Realm VM不同于TOS或者可信应用程序，因为Realm VM受到正常空间中的hypervisor控制，hypervisor负责创建Realm VM、分配内存。

Realm VM和可信OS的不同是：Realm没有任何物理中断使能。所有Realm的中断都是hypervisor虚拟的，然后通过传递给RMM的命令传递进去。这意味着一个受影响的hypervisor可能会阻止Realm VM的执行。

hypervisor初始化Realm的执行和内存访问。hypervisor不必验证Realm。Realm有一个独立的可信链，与正常、安全空间的不同。Realm也与控制它的hypervisor完全隔离。也就是说，hypervisor初始化Realm，但是没有能力访问Realm的数据和内存。

Realm和TrustZone最大的不同就是：安全扩展和Realm扩展设计目的不同。

• TrustZone是为芯片供应商和OEM提供的，用来设计硬件平台特有的服务。
  
• Realm是为普通开发者设计的，提供一个运行系统代码的环境，与复杂的业务逻辑隔离开。
  

可信是指机密性（Confidentiality）、整体性（Integrity）和真实性（Authenticity），具体解释如下：

• 机密性，ARM CCA环境中的代码或状态不能被其它空间中的代码窥测到，即使它是特权代码。
  
• 整体性，ARM CCA环境中的代码或状态不能被其它空间中的代码修改，即使它是特权代码。
  
• 真实性，代码或状态能够被其它代码修改，但是这些更改都是可验证的。
  

Realm和TrustZone另一处不同就是：TrustZone中的代码能够为系统提供机密性、整体性和真实性，而Realm只能提供给系统机密性和整体性。

ARM机密计算架构中提供的4个空间中，安全空间和Realm空间是完全隔离的。这意味着可信应用不必关注Realm VM的执行，而Realm VM也不必关心可信应用的执行。

5 CCA硬件架构

本文描述了Realm管理扩展（RME），其赋能PE运行Realm代码。

5.1 Realm空间的要求

下图是融合了RME扩展的完整CCA架构视图：

Realm空间必须能够执行代码，访问内存和可信设备，并且与其它非root空间和设备完全隔离。

同其它空间一样，Realm空间具有3个异常级别R_EL0、R_EL1和R_EL2，其中Realm VM运行在R_EL1和R_EL0。Realm管理监控程序(RMM)运行在R_EL2。关于RMM的描述可以参考Arm CCA Software Stack。

空间隔离是通过RME架构扩展实现的，其允许控制内存管理、代码执行、隔离Realm的内容上下文和数据。隔离意味着PE、加密单元、Realm、Root空间等访问会产生错误异常而被阻止。

下图中，展示了通过正常空间的hypervisor创建Realm VM并对其进行控制的架构，但是Realm VM的执行在Realm空间中

Realm VM的启动过程是hypervisor发送命令给Monitor，然后，Monitor转发给RMM。

Monitor是不同空间的“传送门”。它连接着正常空间、安全空间、和Realm空间，保证各个空间的隔离，同时在需要的时候提供通信。

5.2 CCA内存管理

TrustZone安全扩展提供了两种物理地址空间(PAS)：

• 非安全物理空间
• 安全物理空间

RME又提供了两种物理地址空间：

• Realm物理地址空间
• Root物理地址空间

下图展示了各个物理地址空间和系统内存空间之间的对应关系：

各个物理地址空间之间的访问是硬件定义的，如下表所示：

如表所示，root空间可以访问所有的物理地址空间。也就是说，root空间在必要时，可以对非安全、安全和Realm的物理地址空间进行转换。

为了保证各个物理地址空间的隔离，ARM推出了一项新的硬件单元，称为颗粒度保护表（Granule Protection Table(GPT)）。该表会跟踪内存页是用于Realm地址空间、安全地址空间、还是非安全地址空间，MMU单元进行地址转换之前，会检查这个表。EL3的Monitor会动态更新这个GPT表，也就是说，物理内存可能在这几个空间中进行转换。

访问非法地址空间会产生一个新的fault，称为颗粒度保护错误（Granule Protection Fault (GPF)）。GPC使能、GPT内容和GPF路由都由root空间进行控制。

为了保证隔离，Realm空间中的资源必须在Realm自己的内存空间中，也就是Realm物理地址空间的一部分。但是，Realm可能会访问非安全空间的资源，比如使能消息传递。所以，Realm能够访问Realm和非安全物理地址空间。

运行在Realm空间的VM，也需要同时访问Realm物理地址空间和非安全物理地址空间。访问不同的物理地址空间是通过Realm的stage-2阶段地址转换表中的NS标志位实现的。

下图展示了完整的地址转换流程和GPC检查的位置。在图中，TTD指的是地址转换表描述符，GPTD指的是颗粒度保护表描述符：

如果对ARM的2阶段地址转换过程不熟悉，请参考AARCH64 Memory Management。只是需要注意的是，在EL3的stage-1页表项中增加了一个NSE标志位-非安全扩展标志位，用以控制monitor访问4个不同的物理地址空间。

不管是非安全空间、Realm空间还是安全空间都能在EL1或EL2完成stage-1地址转换，如果必要，还可以完成stage-2地址转换。

RME扩展在完成地址转换后，增加了颗粒度保护检查（GPC），根据GPT检查所有的物理地址和物理地址空间，决定是否可以访问还是产生fault。GPT表存储在Root空间的内存中，保证与其它空间的隔离。GPT的创建和修改只能在root空间中进行，由Monitor或其它可信固件完成。

SMMU转换管理也纳入到GPC的检查过程中。

5.3 认证

运行在Realm中的代码负责管理机密数据或运行机密算法。所以，这部分代码必须知道它是运行在真实的ARM CCA环境中，而不是一个模拟场景。代码还需要知道是否被正确加载，而不是被篡改过。最后，还需要知道整个平台运行在正常模式，而不是debug模式，从而造成机密泄露。这个建立信任的过程称为Attestation(认证)。

认证过程分为两部分：

• 硬件平台认证；
  
• Realm初始状态认证；
  

这两部分结合起来产生认证报告，realm中的代码可以随时请求访问这些报告。这些报告可以用来验证平台和realm空间中代码的有效性。

硬件平台认证包含证明芯片和固件的真实性，从而证明Realm是真实的。这需要硬件的支持，需要提供硬件的标识。同样，硬件还需要支持关键固件镜像的度量，比如Monitor、RMM和其它影响安全的控制器固件（比如电源控制器）。

6 CCA软件架构

ARM的CCA架构带来了组件的增加，比如RME，再比如固件，尤其是Monitor和RMM。本段介绍CCA架构的软件栈。

6.1 软件栈概述

运行在Realm中的VM与正常空间隔离开，VM的启动和控制由正常空间的hypervisor管理。为了实现Realm VM的隔离执行，ARM引入了一个新的组件，称为RMM（Realm管理监控器），运行在R_EL2异常级别。

RMM负责管理通信和内容切换。RMM只提供机制，不管策略，比如具体是哪个VM运行，或者分配哪块内存给VM等都不管。这些策略交给hypervisor完成。

RMM还通过提供stage-2页表，在Realm空间中为各个Realm VM提供隔离空间。

可以与安全、非安全空间通信的Monitor，也会提供接口给RMM。Monitor运行在EL3，与平台相关，为系统中各个可信模块提供服务。它提供给RMM一个特定的接口，用于处理来自hypervisor或者Realm VM的请求。如果这个接口定义好，RMM完全可以是一个通用代码段。

下图就是一个在realm空间中运行着机密计算的realm vm的CCA架构平台

RMM是运行在Realm空间的控制管理软件，响应来自正常空间的hypervisor的请求，从而允许其管理Realm VM的执行。RMM通过Monitor控制非安全物理地址空间和Realm物理地址空间的转换。

SMC指令允许RMM、hypervisor和SPM陷入到Monitor中，为所有运行在EL2的软件和Monitor建立了一个通信通道。下图展示了CCA架构SMC指令的调用过程。

每个空间中，EL2的代码调用SMC指令，陷入到EL3的Monitor。这是hypervisor通过Monitor与RMM进行通信的基础。

6.2 RMM

RMM是Realm空间的固件，用来管理Realm空间中的虚拟机执行，并与正常空间的hypervisor进行交互。RMM运行在R_EL2。

与正常空间的hypervisor的交互，可以分为机制和策略（能够清晰地抽象出机制和策略是一个优秀工程师的基本素质吧）。

hypervisor负责策略：

• 何时创建、销毁VM；
• 何时为VM添加、移除内存；
• 调度VM的执行；

RMM给hypervisor策略提供支撑：

• 提供操控Realm页表的服务，用于VM创建、销毁和Realm内存的申请、释放；
  
• 提供Realm上下文管理。用于调度时保存、恢复上下文；
  
• 支持中断；
  
• 拦截PSCI调用，用于电源管理请求。RMM还向Realm VM提供认证和加密服务；
  

还有，RMM为Realm VM提供以下安全原语：

• RMM验证主机请求的正确性；
  
• RMM为Realm VM提供隔离空间；
  

RMM规范定义了两个通信通道，允许在正常空间的hypervisor和Realm VM之间进行通信。hypervisor→RMM的通信通道称为Realm 管理接口（RMI）。RMM→Realm VM的通信通道称为Realm 服务接口（RSI）。RSI是RMM提供的服务。

6.3 Realm管理接口

RMI是RMM和正常空间的hypervisor之间的接口。

RMI允许hypervisor发送指令给RMM，进而管理Realm VM。RMI响应hypervisor调用的SMC指令。

RMI提供的服务包括Realm VM的创建、数量、执行和销毁。

下图展示了hypervisor、RMM和Monitor之间的RMI：

6.4 Realm服务接口

RSI是Realm VM和RMM之间的接口。

RSI是RMM提供Realm VM额外服务的接口。这些服务包括加密和认证服务。RSI也是Realm VM向RMM申请内存管理的接口。

下图展示了RSI在Realm VM和RMM之间的位置：

7 问题

7.1 CCA架构下，认证是什么意思？

CCA架构的认证分为两部分：平台认证和Realm认证。平台认证是通过硬件验证固件和芯片的状态安全；Realm认证是指检查Realm的初始状态。

7.2 在基于RME扩展的系统中，允许访问物理内存的最后屏障是什么？

在完成所有的虚拟地址（VA）→物理地址（PA）的转换之后，RME扩展增加了颗粒度保护检查（GPC）。具体的实现由Monitor根据GPT表进行管理，该表也是Monitor固件创建的。

7.3 RMM存在的两个接口是什么？

第一个接口是RMI，提供Realm VM和正常空间的hypervisor通信服务。第二个接口是RSI，允许RMM接收Realm VM发起的服务请求。

上期主题：通往内核的大门（异常向量表_AArch64）

下期主题：分门别类处理异常