foreword

In the past ten years, TEE has been mainly used on the mobile side, which can be called confidential computing 1.0 , to ensure the security of Alipay, WeChat, and FIDO payment roots of trust, to ensure the security of personal privacy such as face and fingerprints, and to protect the digital copyright DRM of high-definition media.

In 2008, ARM launched the trustzone technology, which isolates the operating state of the processor into a secure (secure) state and a non-secure (non-secure) state through hardware design. The memory can be divided into Secure memory and non-secure memory. Based on Trustzone technology, manufacturers have built a trusted execution environment TEE.

In the next ten years, we will enter the era of data economy. Sensitive data going to the cloud and cross-border and transfer of data are the only way to release greater value from data. As a mainstream technical solution for privacy computing, confidential computing has suddenly become popular. We Call it confidential computing 2.0 .

In 2021, after 13 years, ARM launched the confidential computing architecture CCA (Confidential Compute Architecture), which added the division of physical memory attributes under the instruction set architecture. CCA is a new feature proposed by ARM for confidential computing, and it is also an important part of the ARM V9 architecture. CCA can provide a confidential computing base for cloud and data centers, and constitute a computing platform where ARM and x86 architectures coexist.

1. Background

The application software of modern devices has become more and more complex. Different applications and services may run on the same device, and the providers of applications, services, systems, firmware, etc. are also different, which leads to the mutual trust of these providers. Questions such as:

Hosted applications on the same system do not trust each other
The application does not trust the runtime environment
The runtime environment (system) does not trust applications that may interfere and disrupt system and other services
The security service does not trust the application

Existing hypervisor solutions can run applications in the vm sandbox, protecting the system from interference and destruction of applications. Trustzone technology solves the problem of security services from interference and destruction of non-safe applications, but the above technologies fail to solve the problem of application Programs are protected from security services and runtime environments, i.e. applications need to trust the runtime environment .

ARM CCA solves the above problems through the following aspects:

Minimal chain of trust: applications only need to trust themselves, and the parts of the system that provide CCA security guarantees
Run-time verification of trustworthiness: applications deployed in CCA can verify the trustworthiness of CCA firmware
Certifiable: The security implemented by CCA hardware and firmware has the characteristics of development, certification and inspection

The strength of ARM CCA is that through the hardware mechanism and cooperation with related firmware, the application does not need to trust the operating system, hypervisor, and security services, and the mechanism provided by CCA and the trusted endorser realize the reduction of the chain of trust.

2. CCA hardware architecture

We can look at the similarities and differences between the Trustzone architecture and the CCA architecture:

Figure 1 Trustzone security architecture

Figure 2 CCA security architecture

CCA still supports rich operating system + trusted operating system mode, the system mode is still EL0~EL3, hypervisor is also called hypervisor, monitor is still monitor;

CCA adds an additional isolated area on the left, which is logically equivalent to the trusted area on the right, which we call the Realm (R) area; there are multiple RVMs corresponding to the R area in the middle domain (will use to the Realm Confidential Computing VM).

The main difference can also be said to be the difference in the programming model: under the Trustzone model, the application program is divided into common business logic CA and sensitive business logic TA to realize confidential computing 1.0; while CCA can completely put business programs into the private Realm area , while other non-confidential business and management programs run in RVM.

This technical route is similar to Intel SGX -> TDX~

2.1 Introduction

The CCA hardware architecture introduces two new states, Realm and Root, where confidential computing programs run in the Realm state, and EL3 firmware runs in Root.

The Armv9 hardware architecture is divided into 4 privileged modes and 4 states: privileged modes are EL3, EL2, EL1, EL0; states are Root, Realm, Secure, Non-Secure. The status control register is located at the NS and NSE bits of SCR_EL3, and the status relationship is shown in the figure.

Figure 3 System Status Control Register

Root state contains EL3 mode
Realm state contains EL2, EL1, EL0 modes
Secure state includes EL2, EL1, EL0 modes
Non-Secure state includes EL2, EL1, EL0 mode

There are also four types of physical memory attributes, namely Root PA, Realm PA, Secure PA, and Non-Secure PA. The access rights are shown in the figure.

Figure 4 Memory access control

2.2 Memory Management

ARM CCA introduces the concepts of Granule Protection Table (GPT) and Granule Protection Check (GPC) to provide a dynamic partitioning mechanism for physical memory attributes. GPT is a table used to manage the attributes of physical memory space, which can only be operated by monitor in EL3 mode. GPC is a check module at the hardware level. When the processor accesses physical memory, GPC will check according to the attribute configuration in GPT (SMMU also introduces GPC).

Figure 5 GPC particle inspector

2.3 Memory Encryption Mechanism

ARM CCA provides a memory encryption mechanism. Data is stored in DRAM in the form of ciphertext. Each address space uses a different key to isolate data in different spaces. MPE (Memory Protection Engine) encrypts and decrypts data accessed from DRAM.

Figure 6 Memory encryption engine

2.4 Interrupt Mechanism

The introduction of the ARM CCA mechanism does not change the ARM GIC module. Non-Secure hypervisor distributes interrupts to Realm through the virtual interrupt mechanism (vGIC) (the hypervisor schedules Realm like a normal VM).

3. CCA software architecture

Confidential computing systems and applications can run in Realm;

RMM is the manager of Realm, which provides RSI interface services for applications in Realm, and provides services for Non-secure hypervisors;

Monitor adds GPT management and a context switching mechanism between Realm state and Non-secure state on the basis of the original TF-A.

Figure 7 Realm software architecture

3.1 Realm

The hypervisor can dynamically create Realm, and the Realm initialization phase can attest to the operating environment through the Realm Management Interface (Realm Management Interface, RMI). The proof process does not depend on the hypervisor in the non-secure state and the TEE in the secure state (in the 1.0 era, the application must trust these two components unconditionally). Hypervisor can create, destroy, and schedule Realm through RMM, but cannot change Realm's instructions and data.

Realm's runtime environment can use either a Linux-like conventional operating system, or a library operating system (libos) such as Enarx, Occlum, and Graphene.

3.2 Monitor

Under the non-CCA architecture, the trusted firmware running in EL3 mode is called TF-A (Trust Firmware for A Profile). For the ARM CCA mechanism, TF-A has completed the following modifications:

Load and run the RMM image
Switch the context of Non-secure, Secure, Realm state
Manage GPT page tables

3.3 RMM

RMM (Realm Management Monitor) runs in EL2 mode and is mainly responsible for the following functions:

Manage the life cycle of Realm: including the creation and destruction of Realm. In the process of running/initializing Realm, Realm can call the proof service through the RSI interface to complete the proof of the runtime environment
Manage the context of Realm: the vcpu scheduling mechanism is managed by the hypervisor, that is, computing resources are allocated by the non-secure side. When entering Realm, RMM restores the context of Realm; when exiting Realm, RMM saves the context state of Realm. Realm communicates with the non-secure side through shared memory
Manage memory: Realm runtime memory is divided into two categories:
- Protected ranges: The area where Realm's code, etc. run
- Unprotected ranges: Shared storage areas, such as memory that implements virtio, can be accessed by the non-secure side
Manage interruptions
- The introduction of the ARM CCA feature does not change the original mechanism of GIC. The interrupt of Realm is realized by the virtual interrupt of hypervisor GIC. CCA focuses on the security of the calculation process data and does not affect the original business operation of the non-safe side. Therefore, the CPU and interrupt Availability doesn't interfere too much

4. System startup process

In the system startup process when the system does not introduce the ARM CCA mechanism, BL2 runs in EL3 or Secure EL0/EL1/EL2 mode, initializes devices such as DRAM, and completes the loading and verification of BL31, BL32, and BL33 images. BL31 completes the initialization of TEE system and REE system.

Figure 8 Non-CCA startup process

In the system startup process when the system introduces the ARM CCA mechanism, BL2 must run in EL3 mode, initialize DRAM and other devices, and complete the loading and verification of BL31, BL32, BL33, and RMM images. BL31 completes the initialization of TEE system, RMM system and REE system.

Figure 9 CCA startup process

5. Attestation

Attestation is a concept in the field of trusted computing. Based on endorsement certificates, it is a technical solution to make reliable statements on software, firmware, configuration data, etc. to achieve trusted verification. ARM CCA provides attestation functionality to ensure Realm perceives the authenticity of the platform it is running on. ARM CCA recommends using the HES (HARDWARE ENFORCED SECURITY) module to ensure the security of the platform.

Figure 10 CCA certification process

The proof process is shown in the figure, and the entire dynamically collected statement report mainly includes two parts:

Statements related to platforms provided by TF-A and HES
A declaration of the state of the Realm runtime provided by the RMM

6. CCA Implementation Example

EL3 runs TF-A monitor in Root state;

EL2 runs TF-RMM, Linux KVM and Hafnium SPM in Realm, Non-secure and Secure states respectively;

EL1 runs Linux VM, OS VM and OP-TEE in Realm, Non-secure and Secure states respectively

Figure 11 CCA example

Linux KVM can interact with VM through RMI of TF RMM, and schedule VM (Linux KVM creates two VMs, each running in their own independent Realm).

Through the memory encryption and GPC mechanism provided by ARM CCA, the system can ensure that the Non-secure hypervisor cannot obtain the data running on Realm. During the startup and operation of Realm, the operating environment can be certified to ensure the authenticity of the operating environment.