Design

Challenges and Compatibility

The introduction of Realms presents a significant challenge – ensuring compatibility with an established CPU architecture that follows the principle of more privileged levels having greater control. This challenge is common among CPU architectures, including the one under consideration. An immediate concern is understanding how Realms interact with the existing features of the Arm architecture. A notable example is the design of debug registers in the Arm architecture that permits hypervisors to observe VM state. This, however, contradicts the concept of Realms. Adapting the behavior of each instruction to the Realm context is a formidable task, given that the Arm instruction set evolved over decades.

Memory Protection and Isolation

Providing memory protection and isolation for Realms is another significant issue. Virtual Machines (VMs) typically rely on nested page tables (NPTs) to separate physical memory between VMs and safeguard hypervisor memory from VMs. However, NPTs are controlled entirely by the untrusted hypervisor, leaving VM data exposed to potential hypervisor access. While adding a memory ownership tracking system seems plausible, it poses challenges. This approach demands extensive information per memory frame, impacting TLB design and performance. Furthermore, managing such data structure might necessitate more privileged software or intricate instructions, potentially leading to complex architecture modifications.

Simplicity and Firmware Reliance

To circumvent these problems, the Arm Confidential Compute Architecture (CCA) introduces straightforward hardware mechanisms orthogonal to existing privilege levels. This decision reduces hardware complexity but places a significant reliance on firmware for maintaining security guarantees. Consequently, the verification of Arm CCA firmware becomes paramount.

Extending the Arm Architecture

Arm CCA extends the existing Arm architecture with additional layers of functionality. The previous Armv8-A architecture had two distinct worlds – the NS world for most software stacks and the Secure world for platform security services. The introduction of the Realm world (RME) coexists harmoniously with the NS world, enabling seamless execution of software designed for both. RME establishes privilege levels for NS, Realm, and Secure worlds, introducing a Root world to facilitate world switching. This arrangement empowers compatibility and interaction among the worlds.

Arm Confidential Compute Architecture

Dynamic Granule Access and Protection

Each world in Arm CCA operates within its distinct Physical Address Space (PAS), where memory granules (4 KB frames of physical memory) belong exclusively to a single PAS at any point. Notably, individual granules can transition dynamically from NS PAS to Realm PAS, promoting flexibility and shared resource utilization. A Granule Protection Table (GPT) enforces an access control policy that prevents unauthorized memory accesses, ensuring data security. The GPT supports differentiated memory access rights for each security state, minimizing the risk of data breaches.

Access Control Policy of RME: In the context of the RME (Realm Management Entity) access control policy, the entity attempting to access a granule is associated with a specific security state. The Physical Address Space (PAS), on the other hand, is a characteristic that solely pertains to the granule that is being accessed.

Trusted Firmware Components

Arm CCA relies on two essential firmware components: the Realm Management Module (RMM) and the EL3 Monitor (EL3M). RMM, operating at EL2 in the Realm world, oversees the execution of Realms, providing services to untrusted software in the NS world. RMM employs established virtualization technologies, such as NPTs, to isolate Realms and ensure security. By focusing solely on enforcing Arm CCA's security guarantees, RMM's size is significantly smaller than traditional bare-metal hypervisors, which encompass various virtualization functionalities.

EL3M, on the other hand, resides in the Root world at EL3, the highest privilege level. This component orchestrates CPU execution across the different worlds and manages the GPT. Only EL3M has the authority to change the PAS of a granule, enabling secure world transitions. Software in other worlds can request PAS changes via Secure Monitor Calls (SMCs), maintaining controlled and authorized access.

Isolation at the VM Level

The current Arm CCA version defines Realm isolation at the VM level. While this approach is effective for securing containers within virtual machines, finer application-level containerization is not yet supported. Similar to conventional VMs, Realm VMs can host multiple virtual CPUs (VCPUs). The number of Realm VMs scales with available physical memory, allowing for efficient resource utilization.

Delegation and Management

A core concept enabling collaboration between the untrusted hypervisor and RMM is delegation. The hypervisor delegates memory to the Realm world, and RMM manages the integrity and confidentiality of data and code stored in that memory. Realms must receive delegated memory from the hypervisor before use, ensuring RMM oversight. The delegation process maintains a level of granularity, allowing for optimized memory management and controlled data flow.

Realm Management Interface

RMM offers the Realm Management Interface (RMI) to the hypervisor, facilitating the delegation of memory, creation of Realms, execution of Realms, and memory allocation for Realms. Implemented as Secure Monitor Calls (SMCs), RMI commands channel hypervisor requests to RMM for processing. The interaction involves a seamless switch between EL3M and RMM, ensuring coherent execution. RMI commands are designed to maintain system consistency and uphold security guarantees, providing a controlled and structured approach to managing Realms.

RMM Realm Management Interface (RMI)

Granule State Tracking

A pivotal responsibility of RMM is maintaining knowledge about the state of memory granules in the system. To achieve this, RMM utilizes a Granule Status Table (GST). The GST keeps track of the delegation status and current usage of each granule, enabling RMM to verify the validity of requested actions. For instance, when the hypervisor delegates a memory granule, RMM consults the GST to ascertain its delegation status. This rigorous validation process is applied to various RMI commands, ensuring adherence to system policies.

Secure Creation and Management

Creating Realms, Realm Execution Contexts (RECs), and Realm Translation Tables (RTTs) is accomplished through RMM using dedicated RMI commands. RECs correspond to VCPUs, while RTTs play a role similar to normal VMs' nested page tables (NPTs). RTTs facilitate address translation within the Realm world, maintaining security. Granule delegation status is checked when using these commands, providing a structured approach to metadata and resource management.

Protected Address Range and Memory Control

The Protected Address Range (PAR) within a Realm's IPA space guarantees the confidentiality and integrity of Realm operations within the defined range. This isolation ensures that operations within the PAR remain insulated from external interference, promoting secure processing. Beyond the PAR, the hypervisor can map NS PAS granules or emulate accesses, allowing controlled interaction between different worlds.

Memory Manipulation and Reclamation

During Realm creation, the hypervisor can assign specific granules to a Realm, copying data from NS granules. This data is hashed and included in an attestation token, ensuring initial state validation. Memory manipulation continues as Realms operate, enabling dynamic memory allocation and reclamation. RMM erases reclaimed memory, maintaining data integrity and reducing information leakage risks. The process enables efficient memory usage while preserving security.

Concurrency and Fine-Grained Locking

RMM is designed to handle concurrent operations effectively, utilizing fine-grained locking to support high concurrency. Locks are applied at the level of memory granules, REC, and RTT operations. Fine-grained locking ensures parallel processing of multiple operations, optimizing performance. The approach enhances scalability, allowing large Realms to operate with optimal efficiency.

Firmware Security Measures

Arm CCA firmware follows stringent security practices. Unlike some systems that map all physical memory to kernel page tables, RMM and EL3M employ a more selective approach. These components map memory on demand, enhancing security. Firmware is carefully designed, adhering to secure coding principles. Special care is taken to prevent memory access vulnerabilities, such as interpreting SMC parameters exclusively as values rather than pointers, reducing potential attack vectors.

Conclusion

The introduction of Realms within the Arm architecture involves intricate challenges. By utilizing orthogonal hardware mechanisms and relying on firmware for management, Arm CCA strikes a balance between simplicity and security. Collaboration between the hypervisor and RMM establishes clear boundaries of responsibility, ensuring confidentiality and integrity. Arm CCA stands as a promising solution that addresses compatibility and security concerns, provided diligent security practices and rigorous verification efforts are upheld.