More Granular, Less Trust: Enforcing Intra-Process Isolation with Arm CCA in an Untrusted Management Environment

• CVMs avoid trusting cloud hypervisors but remain exposed to OS privilege escalation; Arm CCA’s realm/root TCB includes the guest OS, while process-level isolation leaves intraprocess gaps.Source: §I · p. 1
• CCAegis allocates sensitive data to dedicated physical memory and switches GPTs at sensitive-code boundaries, granting access only under the GPT for sensitive code.The Secure Monitor in the Root world configures and switches GPTs, keeping the OS out of the TCB.Source: §I · p. 2
• CCAegis modifies LLVM to use points-to and taint analysis to identify sensitive-data functions, insert GPT-switching instructions at their boundaries, and replace related memory system calls.This automates program partitioning and instrumentation to reduce porting effort.Source: §I · p. 2
• An untrusted kernel driver maps sensitive data and creates shadow page tables, while the Root world protects those pages and tables from OS access and verifies the mappings.The Monitor addresses the semantic gap by inspecting shadow page tables because it lacks the OS’s virtual-to-physical mapping information.Source: §I · p. 2
• Across five real-world applications, CCAegis protected sensitive code comprising 10.57% to 35.26% of total LoCs, with 1.01× to 1.43× overhead versus the original, on an emulator and real Arm SoC.Source: §I · p. 2

A. Arm Confidential Computing Architecture

• CCA uses GPT attributes and GPC checks to control physical-memory access, while CCAegis constructs multiple GPTs to enforce distinct permissions over the same memory.Unauthorized access triggers a Granule Protection Fault.Source: A. Arm Confidential Computing… · p. 3

B. Trust Firmware-A

• TF-A initializes CCA, manages isolation across four worlds, and prevents other worlds from modifying GPT and GPC configuration.At 590K LoCs, TF-A is smaller than the 26M-LoC Linux kernel, reducing the supervisory-layer TCB.Source: B. Trust Firmware-A · p. 3

A. Motivation

• VM-level SEV, TDX, CCA, ACAI, and CAGE retain the CVM OS in the TCB; CCA also trusts the RMM, adding over 20K LoCs.Sanctuary uses Zircon but adds approximately 500K LoCs to its TCB.Source: A. Motivation · p. 3
• CaSE isolates applications in the L2 cache, while RContainer and SHELTER use multiple GPTs, but their coarse granularity leaves intra-process vulnerabilities.Most TEEs,, isolate at VM, container, or application granularity.Source: A. Motivation · pp. 3–4
• Fine-grained TEEs require manual program partitioning, or rely on caches or registers; automated Glamdring and SeCage depend on Intel-specific features.Ginseng uses registers for isolation but is constrained by the limited data volume it can protect.Source: A. Motivation · pp. 3–4

B. CCAegis Architecture

• CCAegis places enforcement in the GPT, avoiding the additional RMM trust required by a stage-2/Realm-EL2 design, while the root-world Monitor authorizes critical runtime operations.The untrusted OS handles basic scheduling and exceptions; the Monitor oversees memory delegation and recycling, component transitions, sensitive I/O, and key generation.Source: B. CCAegis Architecture · p. 4

IV. CCAEGIS COMPILE-TIME ANALYSIS

• Offline compilation converts CCApps to LLVM IR and a call graph, then uses points-to and taint analysis to identify sensitive data, operations, and functions.Developers annotate initial sensitive data and final forms as analysis sources and sinks; the analysis occurs offline and is therefore immune to runtime attackers.Source: B. CCAegis Architecture · p. 4

B. CCAegis Architecture

• CCAegis inserts call gates at sensitive-function entry and exit and around calls to external non-sensitive functions to grant and revoke access permissions.The compiler links the instrumented program into an executable, with gates invoking the CCAegis-Monitor to change permissions.Source: B. CCAegis Architecture · pp. 4–5
• Developers mark initial taint sources and sinks; the compiler automates function protection and replaces unsafe key-related allocation, release, and file-loading functions with Monitor-provided secure functions.CCAegis does not require explicit file-descriptor protection because it enforces signature verification on file contents during reads.Source: B. CCAegis Architecture · pp. 4–5

C. Threat Model and Assumptions

• The TCB consists only of the root-world Monitor, verified by vendor signatures and securely loaded via secure boot; CCAegis assumes Arm CCA and RME conform to their specifications.It aims to protect cryptographic keys from intra-process adversaries and privileged adversaries, including the OS, hypervisor, and secure- and realm-world components, and to enforce mutual isolation among CCApps and privileged software.Source: C. Threat Model and Assumptions · p. 5
• The threat model includes intra-process memory exploits and control-flow hijacking, plus privileged memory, register, I/O, and DMA access, control-flow manipulation, and memory-oriented Iago attacks.It excludes intentional leaks or vulnerabilities in sensitive functions, hardware attacks such as bus snooping, Cold Boot, and Rowhammer, and DoS and side-channel attacks; future MPE memory encryption and possible integrity protection are expected to mitigate hardware threats.Source: C. Threat Model and Assumptions · p. 5

A. Program Analysis and Partitioning

• Points-to and taint analysis, follows secrets from input sources to ciphertext or signature sinks and identifies crypto operations whose containing functions are isolated.A function qualifies as a crypto function if it contains at least one load or store that touches an address on the secret path.Source: A. Program Analysis and Partitioning · p. 5
• Taint IR normalizes constructs across compiler IRs, assigns context-sensitive instruction identifiers, and models byte-range offsets to reduce over-tainting of structured and array data.The normalized analysis results can be reapplied to the original IR without binding the analysis to a specific compiler.Source: A. Program Analysis and Partitioning · p. 5
• The context-sensitive analysis tracks taint propagation from an entry function and returns tainted local and global variables and memory locations for instrumentation.Distinct call sites define distinct contexts, and each variable’s result records propagation flows and corresponding memory-location indices.Source: A. Program Analysis and Partitioning · p. 6

Secure Memory Management

• CCAegis consolidates scattered keys in a contiguous crypto buffer with crypto stack, heap, and data segment, copying non-sensitive globals onto the crypto stack for access.The GPT's minimum isolation granularity is 4KB; the Monitor manages the crypto buffer's available memory.Source: B. Program Instrumentation · p. 6

Call Gate Generation

• At crypto-function entry and exit, GPERM and RPERM switch GPT permissions and stacks; internal gates revoke and restore crypto access around non-crypto calls.Nested crypto calls need no additional entry or exit gates because the caller already established the secure context.Source: B. Program Instrumentation · pp. 6–7

Context-Sensitive Isolation

• Context-sensitive analysis generates separate versions of context-dependent functions, preventing non-crypto callers from exploiting INGPERM while preserving crypto-context gates.A function called from crypto context may still need internal revoke and grant gates around its own non-crypto calls.Source: B. Program Instrumentation · p. 7

Call Gate Hardening

• The Monitor permits INGPERM only after Access Granted and Internal Revoked states, and verifies its address matches the paired INRPERM.These checks secure legitimate control flow and prevent attackers from jumping directly to INGPERM.Source: B. Program Instrumentation · p. 7

Key-Related System Call Replacement

• The Compiler replaces native malloc and free with Monitor implementations, which manage buffer memory; the Monitor also securely implements key I/O and random-number generation.The OS still allocates and maps the crypto buffer, which is delegated to the Monitor for internal memory management.Source: B. Program Instrumentation · p. 7

Iago Attack Defense

• To resist Iago attacks, CCAegis checks page-table updates and allocation overlap with the crypto buffer, and bounds-checks returned lengths such as recv data.Non-sensitive allocations may still use native system calls such as mmap.Source: B. Program Instrumentation · p. 7

A. Memory Isolation

• Per-core Host, Crypto, and Non-Crypto GPTs give the OS, crypto functions, and non-crypto functions distinct physical-memory permission views.The Monitor initializes and switches GPTs according to execution context to avoid conflicts when cores require different permissions.Source: A. Memory Isolation · p. 7, Figure 8 · p. 8
• A spinlock keeps GPT views current, while the Host GPT serves as a template for creating each CCApp’s GPT with minimal adjustments.Only normal memory in the Host GPT may be delegated; other CCApps’ GPTs mark delegated memory inaccessible, and memory delegated to original TEEs is marked realm or secure.Source: A. Memory Isolation · pp. 7–8
• After OS page-table creation, the Monitor marks the tables no-access in the Host GPT before inspecting mappings, eliminating the TOCTTOU window.This order bridges the gap between GPT physical-memory permissions and CCApps’ virtual-address view.Source: A. Memory Isolation · p. 8
• The Monitor verifies that code and crypto buffers are uniquely mapped to delegated memory, preventing page-oriented code-reuse attacks and Iago attacks.It also checks that page and vector tables cannot be maliciously mapped.Source: A. Memory Isolation · p. 8
• The Monitor requires the code segment to be read-only and executable and all other memory to be non-executable, preventing code injection.Source: A. Memory Isolation · p. 8
• On CCApp page faults, CCAegis uses a shadow page table so the OS can securely update the CCApp page table.The paper details this mechanism in §V-B.Source: A. Memory Isolation · p. 8

Call Gate Handling

• Call gates use immediate-number svc calls and delegated-vector routing; the Monitor identifies executors by GPT base, blocks Host-GPT callers, switches GPTs, and bypasses the OS.The compiler sets original svc immediate values to 0 to avoid conflicts; call gates use an immediate such as svc #4 instead of passing the call number in x8.Source: B. Secure Context Switch · p. 8

Regular Exception Interception

• On regular exceptions, the Monitor switches to Host GPT before entering the OS and restores the relevant GPT for CCApp re-entry; direct OS jumps back trigger a GPF.The delegated vector table ensures execution leaving the CCApp first enters the Monitor.Source: B. Secure Context Switch · p. 8

Register State Sanitization and Sensitive Context Cleanup

• At crypto-function entry and exit, the Monitor sanitizes PSTATE and general registers, while exception handling preserves sensitive context and clears registers before handing control to the OS.Entry sanitization clears condition flags and keeps status bits such as the debugging bit at required values; exception handling saves general registers, the exception link register, and saved program status, then restores them on re-entry.Source: B. Secure Context Switch · pp. 8–9

CCApp Page Table Updating

• For page faults, the Monitor lets the OS update a shadow page table, then restores and synchronizes delegated CCApp tables while checking mappings against the crypto buffer and stack to defend against memory-based Iago attacks.The delegated vector table is reactivated on each CCApp re-entry so exceptions remain intercepted.Source: B. Secure Context Switch · p. 9

C. Sensitive I/O and Key Generation

• The monitor generates true random numbers by reading Armv8.5-A’s RNDR register and writing the value into the crypto buffer through call-gate routing that bypasses the OS.The CCAegis-Monitor manages this process directly.Source: C. Sensitive I/O and Key Generation · p. 9
• For key import, the monitor verifies the file signature, checks that the kernel buffer is normal memory in the Host GPT, and prevents copying keys to unprotected memory.The OS requests the monitor to decrypt encapsulated keys and transfer them into the crypto buffer; signature verification prevents exploitation of monitor_copy as a decryption oracle, while the copy_from_ns and copy_to_crypto checks prevent secret theft or leakage.Source: C. Sensitive I/O and Key Generation · p. 9
• Key export follows a procedure similar to key import, though the paper does not detail it.Source: C. Sensitive I/O and Key Generation · p. 9

D. Multi-threading Support.

• CCAegis allocates a crypto stack per thread, saves and restores sensitive state by thread ID, and uses lock-free per-core GPT switches.It disables TLB sharing to avoid cross-core shootdowns; a global spinlock is reserved for infrequent GPT updates and memory delegation. Before external calls such as FUTEX_WAIT, it executes INRPERM.Source: D. Multi-threading Support · p. 9

VI. IMPLEMENTATION

• The functional prototype uses FVP, while LLVM taint analysis treats unresolved calls on tainted paths as sensitive boundaries under a fail-closed policy.The LLVM analyzer and pass add 2k LoCs; the Linux kernel modifications and driver add 1k LoCs. The driver manages CCApp lifecycle and thread creation.Source: §VI · pp. 9–10
• In the root world, the CCAegis-Monitor exposes a narrow SMC ABI for GPT configuration and switching and shadow-mapping verification.The passage characterizes this fail-closed trusted path as compact and auditable, without scheduler, filesystem, or device stacks.Source: §VI · p. 10
• The Rock Pi 4B performance prototype simulates unsupported GPC, RNG, and GPT-TLB-invalidation features rather than measuring them on supported Arm CCA hardware.It substitutes EL3 registers for GPC/GPT registers, uses full-TLB invalidation in place of TLBI PAALLOS, and generates a simulated key from registers.Source: §VI · p. 10

VII. EVALUATION

• The evaluation addresses TCB size, resistance to privileged and intra-process attacks, static-analysis compilation overhead, isolation performance, and its causes.Security questions use the FVP functional prototype; performance questions use the Rock Pi 4B prototype.Source: §VII · p. 10, A. Experimental Setup · p. 10

A. Experimental Setup

• Compile-time overhead is evaluated with LLVM 10.0.1 at -O2 on a 96-core Kunpeng-920 server, while Rock Pi 4B performance tests disable its Cortex-A53 cores.The board’s two Cortex-A72 cores run at maximum frequency to avoid big.LITTLE measurement discrepancies.Source: A. Experimental Setup · p. 10

B. Q1: TCB Size of CCAegis

• CCAegis’s TCB uses 479K LoCs of Trusted Firmware-A v2.9.0 and adds 1,803 LoCs of modifications.It omits Linux cca-guest-v2 (26M LoCs) and TF-RMM v0.4.0 (33K LoCs).Source: Table III · p. 10, B. Q1: TCB Size of CCAegis · p. 10

C. Q2: Security of CCAegis

• CCAegis-Monitor verifies CCApp loading addresses and binary integrity, validates delegated memory, and uses GPTs to fault on unauthorized access to code, crypto buffers, and page tables.It invalidates TLB entries during GPT updates and prevents cross-core TLB sharing; privileged software cannot modify the root-world GPT or EL3 GPC registers.Source: C. Q2: Security of CCAegis · pp. 10–11
• During execution, the monitor secures random-number generation and key I/O, intercepts exceptions for GPT switching, sanitizes crypto registers, and checks page-table updates and call-gate authorization.It reactivates the delegated vector table on CCApp re-entry, protects exception returns from return-address tampering, and integrates system-call return checks against Iago attacks.Source: C. Q2: Security of CCAegis · p. 11
• Call gates, INRPERM before untrusted calls, legitimate-control-flow checks, and register clearing prevent non-crypto functions or hijacked control flow from accessing the crypto buffer or leaking keys.The monitor also protects the vector table, page table, and CCApp code by checking page-table updates rather than marking them no-access in the Non-Crypto GPT.Source: C. Q2: Security of CCAegis · p. 11
• On CCApp destruction, CCAegis clears crypto buffers, cache, and register state, releases delegated memory through GPT updates, and destroys the CCApp GPTs.The Host GPT synchronizes access across cores to avoid memory overlaps from outdated views.Source: C. Q2: Security of CCAegis · p. 11
• The monitor prevents CCApps from claiming overlapping memory and uses the SMMU to enable peripheral GPC protections against DMA bypass of isolated memory.It gives peripherals the lowest access permissions and invalidates the SMMU TLB when modifying the Host GPT.Source: C. Q2: Security of CCAegis · p. 11

D. Q3: Evaluation on Static Analysis

• Across wolfSSL, ccrypt, libhydrogen, and libxcrypt, annotations marked cryptographic keys as taint sources and algorithm outputs as sinks, taking under three hours for most libraries and under six for wolfSSL.The evaluation used five graduate students; wolfSSL required annotations in 13 LoCs, while the other libraries also required only a small number of annotated LoCs.Source: D. Q3: Evaluation on Static Analysis · p. 11, Table V · p. 11
• False positives were 0% for libxcrypt, 1.91% for wolfSSL, 14.29% for ccrypt, and 7.89% for libhydrogen; the latter two rates reflect only three incorrectly flagged functions combined.For wolfSSL, 343 functions (12.70%) were identified as crypto functions, covering 23.77% of total LoCs; crypto code across libraries ranged from 10.57% to 35.26% of total LoCs. The conservative overprotection avoids missing genuine crypto functions and risking key leakage.Source: Table V · p. 11, D. Q3: Evaluation on Static Analysis · p. 12
• WolfSSL had 704 call gates and 2,534 internal call gates; ccrypt required 12 system-call replacements, and wolfSSL compilation overhead was approximately one minute.The evaluation measured call-gate insertion, system-call replacements, and overall compilation time; domain-switch instruction counts affect execution efficiency.Source: Table V · p. 11, D. Q3: Evaluation on Static Analysis · p. 12

E. Q4: Evaluation on Benchmarks and Applications

• Creation and destruction added one-time costs of about 1 ms for driver loading, 16.99 ms for CCApp loading, and 1.90 ms for destruction; switching averaged 1,211 cycles for GPERM and 1,269 for RPERM.Exception-handling traps added 1,067 cycles on exit and 1,437 cycles on entry; runtime overhead primarily arose from domain switching.Source: E. Q4: Evaluation on Benchmarks and… · p. 12
• Under low Nginx concurrency (≤80 clients), throughput overhead stayed below 10%, peaking at 9.33% with 40 clients; at 350 clients, it reached 42.72%.The evaluation used keepalive and up to 350 concurrent clients; beyond that, significant connection failures occurred.Source: E. Q4: Evaluation on Benchmarks and… · p. 12, Figure 10 · p. 12
• wolfSSH connection requests incurred 25.35% average overhead, approximately 27.2 ms, primarily during initial connection establishment.The evaluation compared 1,000 connections against an uninstrumented baseline; subsequent data transfers were expected to have significantly lower latency.Source: E. Q4: Evaluation on Benchmarks and… · p. 12
• CCAegis adds less than 0.83% overhead over SHELTER for ccrypt, 7.43% for wolfSSH, and at most 16.92% for Nginx while providing intra-process isolation.SHELTER provides process-level isolation; CCAegis inserts call gates for finer-grained domain switching.Source: E. Q4: Evaluation on Benchmarks and… · p. 13
• Across cryptographic libraries, overhead was below 1% for libhydrogen and libxcrypt, and 5.10% for ccrypt encryption and 4.35% for decryption.Tests used 10 MB of data and were repeated 1,000 times.Source: E. Q4: Evaluation on Benchmarks and… · p. 13, Table VI · p. 13

F. Q5: Root Cause Analysis

• Overhead increased with call-gate count: wolfSSL’s 3,238 call gates corresponded to overhead over 20% greater than libraries with fewer than 500 gates.The passage identifies call-gate count as one of two factors affecting overhead.Source: F. Q5: Root Cause Analysis · p. 13, Figure 11 · p. 13
• High-concurrency Nginx workloads caused more frequent domain switches and threefold higher overhead than low-concurrency conditions.The passage identifies call-gate invocation frequency as a second factor affecting efficiency.Source: Figure 10 · p. 12, F. Q5: Root Cause Analysis · p. 13
• A wolfSSL AES-GCM stress test with 2,048-byte inputs showed overhead up to 75.80%, exceeding that observed in high-concurrency Nginx.The direct benchmark of cryptographic functions incurred greater overhead than the Nginx scenarios invoking them.Source: F. Q5: Root Cause Analysis · p. 13, Table VII · p. 13

VIII. DISCUSSION

• CCAegis currently supports one crypto domain, but separate GPTs could extend it to independent domains with access limited to relevant function sets.The proposed extension creates separate GPTs for functions handling different secret types.Source: §VIII · p. 13
• To reduce costly EL3 traps, the authors propose verifying frequently called external functions or combining authoritative GPT enforcement with PAC user-mode fast paths.GPT would remain the barrier against OS and other-process reads, while PAC would reduce svc+smc transitions inside sensitive regions.Source: §VIII · p. 13
• Cryptographic workloads stress CCAegis because secret derivation and propagation across functions, call chains, and buffers enlarge the taint surface and increase domain switches.The paper characterizes its reported overheads as a conservative upper bound for many general-purpose workloads, and says other applications can be supported by adding monitor support for system calls beyond I/O and key generation.Source: §VIII · p. 13
• CCAegis fails closed by conservatively marking imprecise boundaries sensitive, but it does not claim to eliminate false negatives, which are difficult to quantify without ground-truth secret-flow labels.Potential sources include implicit or indirect control transfers, assembly branches or jumps, and missing taint or erase annotations; future work includes default cryptographic API signatures and warnings for assembly redirections or indirect jumps.Source: §VIII · pp. 13–14

IX. RELATED WORK

• Prior partitioning tools include SOAAP and Wedge, while automated approaches include Privtrans, ProgramCutter, and PtrSplit; CCAegis uses taint analysis to partition key-related code.The paper says CCAegis also enables privilege-aware instrumentation, including replacement of key-related system calls.Source: §IX · p. 14
• User-space isolation approaches include libmpk, CALI, PANIC, and Capacity, but these mechanisms are not designed to protect against privileged-software attacks.The passage also cites intra-process isolation work, and describes MPK, nsjail, PAN/LSU, and PAC/MTE as underlying mechanisms.Source: §IX · p. 14
• CCA-related work covers RMM implementations,, verification,, accelerator access,, and GPT-based protection,, but none provides function-level fine-grained isolation.Source: §IX · p. 14

X. CONCLUSION

• CCAegis is presented as the first system to extend Arm CCA for fine-grained isolation, with real-world workloads incurring 1.01× to 1.43× overhead.It automates partitioning with static analysis and uses three GPT types to safeguard cryptographic keys; experiments report a compact TCB and protection against privileged and intra-process key leakage.Source: §X · p. 14