Source-linked AI summary
More Granular, Less Trust: Enforcing Intra-Process Isolation with Arm CCA in an Untrusted Management Environment
Shiqi Liu, Zhouqi Jiang, Jie Wang, Wei Zhou, Kun Sun, Zhaohui Chen, Yulai Xie
TL;DR
Existing isolation approaches can leave intra-process attacks exposed or require the OS to manage protection domains, increasing the trusted computing base. CCAegis extends Arm CCA with static-analysis-guided GPT switching so designated functions alone access isolated data. Evaluations on an emulator and development board report effective protection with 1.01× to 1.43× overhead on real-world cryptographic workloads.
Problem
Existing fine-grained isolation schemes remain vulnerable to intra-process attacks or depend on OS-managed mechanisms, resulting in a large Trusted Computing Base.
Method
CCAegis uses static taint and points-to analysis to identify sensitive functions, inserts GPT permission switches at code boundaries, and relies on a trusted Monitor for enforcement.
Results
1.01× to 1.43× overhead was reported across real-world applications while CCAegis effectively protected sensitive data.
Takeaways & Limitations
CCAegis provides fine-grained intra-process isolation with a compact TCB centered on the root-world Monitor.
Takeaways & Limitations
CCAegis currently supports only a single crypto domain, although separate GPTs could extend it to multiple independent domains.
Abstract
from arXiv · showhide
With the increasing adoption of confidential computing, security-sensitive applications are often deployed in confidential virtual machines (CVMs), which reduce reliance on third-party cloud providers. However, privilege attacks originating from the OS remain a significant threat in these environments. Existing finer-grained isolation schemes, such as SHELTER, provide process-level protection but are still vulnerable to intraprocess attacks and potential collusion between the OS and intra-process adversaries. Many current intra-process isolation techniques continue to depend on the OS to manage and enforce isolation domains, leading to a large Trusted Computing Base (TCB). This gap highlights the need for more granular, less trust-dependent confidential computing solutions. In this paper, we present CCAegis, a system that extends the Arm Confidential Compute Architecture (CCA) to enforce intra-process isolation of sensitive data and operations, safeguarding them from both intraprocess adversaries and the OS. We employ static analysis to track the flow of sensitive data and identify functions that handle such data. Permission-switching instructions are inserted at the function call and return points, adjusting permissions via the Granule Protection Table (GPT) to ensure that only designated functions can access the isolated data. Notably, CCAegis places trust solely in the Secure Monitor, which configures the GPTs and manages domain switching, thereby minimizing the TCB. We implemented CCAegis on both an official emulator and a real development board to assess its performance. Our experimental results show that CCAegis effectively isolates sensitive data and operations, with performance overheads ranging from 1.01x to 1.43x compared to the original version across real-world cryptographic workloads.
I. INTRODUCTION
CCAegis targets coarse or OS-dependent isolation by extending Arm CCA with GPT-based intra-process protection. Static analysis automates partitioning and instrumentation while a trusted Monitor preserves a minimal TCB.
- Motivation: Existing approaches remain too coarse-grained or OS-dependent, leaving intra-process attacks and privilege escalation as significant concerns.VM-, container-, and process-level isolation do not fully address intra-process threats, while OS-managed mechanisms remain vulnerable to privileged attackers.
- Design: Arm CCA’s GPT enables physical-memory protection domains whose configuration and switching are controlled by the trusted Secure Monitor rather than the OS.CCAegis uses separate GPTs for sensitive and non-sensitive code and allocates sensitive data to a dedicated physical region.
- Design: Static analysis tracks sensitive data and identifies the minimal functions requiring protection, after which CCAegis inserts GPT-switching instructions at code boundaries.The compiler performs points-to and taint analysis, and the system replaces sensitive memory-related system calls when needed.
- Runtime Isolation: The untrusted kernel driver maps sensitive memory and maintains shadow page tables, while the root world verifies mappings and blocks OS access to protected pages.This design bridges virtual-address process management and the Monitor’s physical-memory enforcement without trusting the driver.
- Evaluation: CCAegis comprises approximately 5K LoCs and protects 10.57% to 35.26% of application LoCs, with 1.01× to 1.43× overhead across five real-world applications.The implementation was evaluated on an official Arm emulator and a real Arm hardware SoC.
- Contributions: The system is designed to prevent sensitive-data leakage while addressing automated partitioning, isolation instrumentation, and semantic-gap challenges with a minimal TCB.The reported evaluation finds effective protection with moderate performance overhead.
II. BACKGROUND
Arm CCA adds realm and root worlds through RME and uses GPT/GPC mechanisms to control physical-memory access. Trust Firmware-A operates in the root world and helps keep the supervisory TCB smaller than the Linux kernel.
- Arm Confidential Computing Architecture: Arm CCA introduces realm and root worlds alongside TrustZone, enabled by the Realm Management Extension in Armv9.2-A.The architecture supports confidential virtual machines in the realm world.
- Arm Confidential Computing Architecture: The Granule Protection Table tracks physical pages and assigns attributes including world association, universal access, or no access.The Granule Protection Check enforces these physical-memory permissions.
- Arm Confidential Computing Architecture: CCAegis differs from typical CCA by constructing multiple GPTs to support finer-grained intra-process protection.The supplied passage introduces this contrast but does not provide the complete list of GPT configurations.
- Trust Firmware-A: Trust Firmware-A runs in the root world, initializes hardware, supports secure boot, and prevents other worlds from modifying GPT and GPC configuration.Its reported size is 590K LoCs versus 26M LoCs for the Linux kernel.
A. Motivation
CCAegis is motivated by the coarse granularity and practical burdens of existing TEE isolation. It combines automated taint-based partitioning with GPT-backed memory isolation and a Monitor-centered trust model.
- A. Motivation: Existing TEEs commonly isolate VMs, containers, or applications, while finer-grained designs may require substantial manual effort or rely on caches and registers.These limitations reduce the practicality of fine-grained protection for general-purpose applications.
- A. Motivation: Developer annotations identify initial sensitive data, and taint propagation analysis discovers subsequent sensitive data for instrumentation-based protection.This approach is intended to minimize manual partitioning effort.
- A. Motivation: CCAegis uses memory-based isolation because GPT provides memory access control without trusting the OS, supporting applications with larger data volumes than register-centric schemes.The passage contrasts memory-based isolation with cache- and register-centric approaches.
- B. CCAegis Architecture: The runtime architecture bridges user space and the Monitor through compiler-generated gates, a kernel driver, and Monitor-managed security operations.The driver handles virtual-memory allocation and mapping, while critical transitions remain in the root-world component.
- B. CCAegis Architecture: CCAegis trusts only the root-world Monitor and hardware assumptions, aiming to protect cryptographic keys from intra-process and privileged adversaries.The stated scope includes the OS, hypervisor, and components in secure and realm worlds.
IV. CCAEGIS COMPILE-TIME ANALYSIS
CCAegis-Compiler combines points-to and taint analysis to track sensitive data through context-sensitive, index-aware Taint IR. The analysis identifies sensitive variables, memory locations, and functions for subsequent function-granular isolation.
- CCAegis treats cryptographic secrets as taint sources and ciphertext or signatures as sinks, stopping tracking after the data reaches its final protected form.
- Taint IR normalizes compiler constructs, preserves context-sensitive identifiers, and models byte-range indices to track structured and array elements precisely.The index model reduces over-tainting by distinguishing structure elements in points-to analysis.
- Points-to analysis represents variables as memory-location and byte-range tuples, with allocation, load, store, and index instructions describing memory relationships.
- Taint and points-to results identify sensitive variables and accesses, enabling later instrumentation to classify functions and operations on secret paths.
- The context-sensitive taint algorithm propagates taint across Taint IR instructions and call contexts, producing taint results for local and global variables and memory locations.
B. Program Instrumentation
CCAegis instruments function boundaries with call gates that switch between crypto and non-crypto permissions. The design handles nesting, context-sensitive calls, and control-flow attacks while preserving secure interactions with ordinary code and system calls.
- CCAegis reallocates cryptographic keys into a contiguous crypto buffer because GPT isolation has a minimum granularity of 4KB.
- Instrumentation also secures access to non-sensitive globals, non-crypto functions, and system calls executed from crypto functions.
- Entering a crypto function invokes GPERM to select the Crypto GPT and crypto stack, while returning invokes RPERM to revoke access and restore the normal stack.
- Nested crypto calls omit redundant entry and exit gates, whereas transitions involving non-crypto functions use permission gates to preserve the crypto context.
- The monitor hardens call gates with state-machine transitions and paired-address checks so attackers cannot re-enter crypto functions through arbitrary internal targets.
A. Memory Isolation
CCAegis uses GPT-based physical-memory domains to isolate crypto buffers and related state from privileged software. The monitor delegates and configures memory while preserving separation among applications and trusted environments.
- The CCAegis-Monitor delegates memory by updating GPT permissions, while the untrusted driver manages allocation to minimize the Trusted Computing Base.
- CCAegis addresses GPT permission conflicts that arise when multiple cores require different access views for crypto functions and other software.
- Only normal memory in the Host GPT may be delegated, preventing overlap with CCApps and original trusted execution environments.
B. Secure Context Switch
CCAegis routes call gates and exceptions through the Secure Monitor, which selects the appropriate GPT and sanitizes execution state. These mechanisms prevent OS access to protected memory, sensitive registers, and delegated page-table state.
- The monitor identifies call-gate executors using the GPT base address, blocking attempts from software using the Host GPT.
- Call gates use immediate-number conventions through svc and smc traps, reducing opportunities to tamper with call-gate register arguments.
- After trapping to EL3, the monitor switches to the relevant Crypto or Non-Crypto GPT and returns directly to the CCApp without the OS.
- At crypto entry and exit, the monitor sanitizes status flags and general registers to prevent control-state manipulation and sensitive-register leakage.
- Before entering the OS, the monitor selects the Host GPT, and an OS jump back to the CCApp triggers a permission fault.
- For page faults, the monitor lets the OS update a shadow page table, then synchronizes checked changes with the delegated CCApp page tables.
C. Sensitive I/O and Key Generation
CCAegis protects sensitive key operations from the untrusted OS by routing key generation and I/O through the CCAegis-Monitor.
- Key loading: Encapsulated key loading is handled as a dedicated CCAegis operation.The paper presents this operation in Fig. 9.
- Key generation: The CCAegis-Monitor generates keys through call-gate routing that bypasses the OS and writes Arm RNG output into the crypto buffer.It reads true random numbers from the RNDR register.
- Key import: For key import, copy_from_ns verifies that source kernel buffers are normal memory in the Host GPT.This prevents the OS from using the interface to access secrets from other worlds or the crypto buffer.
- Key I/O: CCAegis uses copy_to_crypto to prevent imported keys from leaking into unprotected memory.Key export follows a similar protected procedure.
D. Multi-threading Support.
CCAegis supports multithreaded CCApps while keeping synchronization variables accessible to the OS and allocating protected stacks per thread.
- Synchronization: CCAegis supports locks, condition variables, and semaphores using Futex-based thread synchronization.The OS can normally access Futex variables because they remain outside the crypto buffer.
- Synchronization: Before external calls such as FUTEX_WAIT, CCAegis executes INRPERM to prevent potential key leakage attacks.This revokes protected-memory permissions before entering the untrusted interaction.
- Thread isolation: Each new CCApp thread receives a separate crypto stack managed through the CCAegis runtime.The Monitor checks the associated mapping during thread creation.
- Runtime support: The driver manages CCApp creation, destruction, and new-thread creation through interactions with the CCAegis-Monitor via SMC.The functional prototype validates these lifecycle operations on Arm FVP.
- Evaluation: The evaluation examines TCB size, attack resistance, compilation overhead, performance cost, and overhead causes.The experiments use functional and performance prototypes, including a Rock Pi 4B board with Cortex-A72 cores selected for measurement.
B. Q1: TCB Size of CCAegis
CCAegis confines its TCB to a root-world Monitor and uses GPT-based defenses to protect CCApp memory and control flow from privileged and malicious software.
- TCB size: CCAegis adds 1,803 LoCs to Trusted Firmware-A while excluding the 26M-LoC CCA guest and 33K-LoC TF-RMM components from its TCB.The stated TCB is confined to the root-world Monitor.
- Initialization: The Monitor verifies CCApp binaries and allocation requests before protected execution begins.These checks protect initialization from the untrusted OS.
- GPT management: The Monitor synchronizes GPT access across cores to prevent memory overlaps caused by outdated GPT views.This coordination addresses cross-core consistency during protection management.
- Privileged-software defense: Because the GPT resides in the root world and GPC registers are at EL3, privileged software cannot modify the GPT or disable the GPC.The Monitor also invalidates relevant TLB state during GPT updates and switching.
- Memory protection: GPT isolation causes unauthorized privileged access to CCApp code, crypto buffers, and page tables to trigger a GPF.The Monitor also secures random-number generation and key-related I/O.
- Intra-process defense: Call gates and INRPERM restrict non-crypto access to the crypto buffer and revoke permissions before untrusted calls.The Monitor validates call-gate transitions and clears registers before crypto functions exit or invoke untrusted code.
D. Q3: Evaluation on Static Analysis
CCAegis combines static analysis with runtime permission switching, achieving low to moderate overhead while showing that call-gate count and invocation frequency drive performance costs.
- Static analysis: CCAegis evaluates static partitioning across wolfSSL, ccrypt, libhydrogen, and libxcrypt using annotations, taint propagation, and instrumentation.Points-to imprecision can include some non-crypto functions, causing slight overprotection while preserving security coverage.
- Lifecycle cost: 16.99 ms is the reported CCApp loading overhead for creating GPTs and verifying page tables and program code.Driver initialization adds about 1 ms for vector-table delegation.
- Runtime cost: 1,067 and 1,437 cycles are the measured trap overheads for exiting and entering the CCApp during exception handling.GPT-switch overhead also includes TLB flushes and EL3 context save-and-restore.
- Microbenchmarks: CCAegis adds less than 1% overhead on libhydrogen and libxcrypt, while ccrypt incurs 5.10% encryption and 4.35% decryption overhead.These results come from 10MB tests repeated 1,000 times.
- Root causes: 3,238 call gates make wolfSSL’s overhead over 20% greater than that of libraries with fewer than 500 call gates.The comparison identifies call-gate count as one major overhead factor.
- Root causes: High-concurrency workloads can produce a threefold overhead increase over low-concurrency conditions because they trigger more frequent domain switches.Call-gate invocation frequency is the second reported overhead factor.
- Stress testing: Up to 75.80% overhead appears in the wolfSSL AES-GCM stress test with 2048-byte inputs.This exceeds the overhead observed in high-concurrency Nginx scenarios invoking cryptographic functions.
VIII. DISCUSSION
CCAegis discussion centers on extending protection beyond a single crypto domain while preserving security and deployment practicality. The paper also positions taint-based partitioning as an automated alternative to manually defined compartment boundaries.
- Multi-Domain Support: CCAegis currently supports one crypto domain, but separate GPTs could extend protection to multiple independent secret domains.Each domain would use distinct GPTs for function sets handling different secrets.
- Performance Optimization: Frequent EL3 traps from internal call gates can be costly, motivating security verification for frequently called external functions.Combining GPT enforcement with PAC is another proposed optimization: GPT remains the authoritative barrier while PAC provides a user-mode fast path.
- Scalability: CCAegis primarily targets cryptographic applications because repeated secret propagation across small functions and library boundaries stresses intra-process isolation.This target scope reflects the workloads used to stress-test the system’s fine-grained protection mechanisms.
- Compartmentalization: Unlike earlier compartmentalization tools requiring manually identified boundaries, CCAegis uses taint analysis to automate partitioning around cryptographic keys and their propagation.It also supports privilege-aware instrumentation, including replacing key-related system calls.
- Conclusion: CCAegis combines automated program partitioning, GPT-based key protection, and a compact TCB, with real-world applications incurring 1.01× to 1.43× overhead.The reported applications include Nginx, SSH connections, and popular cryptography libraries.