- The paper introduces CCX, a firmware-based framework that enables unmodified Intel SGX applications to run on Arm CCA by emulating SGX microcode instructions.
- It employs a multi-GPT memory protection scheme and dynamic memory management to ensure stringent intra-process isolation and near-native performance.
- The work demonstrates strong security guarantees with a minimal TCB while preserving SGX API compatibility and paving the way for future remote attestation on Arm platforms.
Authoritative Technical Analysis of "CCX: Enabling Unmodified Intel SGX Applications on Arm CCA" (2605.07548)
Introduction and Motivation
The landscape of confidential computing continues to evolve, with both hardware and software designs targeting increasingly granular isolation for sensitive workloads in cloud and data center environments. Intel SGX has become the de facto standard for enclave-based intra-process isolation on x86 platforms, reinforced by its minimal trusted computing base (TCB) and precise execution semantics. However, the heterogeneous nature of modern cloud infrastructure—especially the adoption of Arm CPUs and Arm CCA—poses a significant challenge for portability of SGX applications. Existing Arm TEEs (e.g., TrustZone, CCA) natively provide VM- or process-level isolation but do not implement SGX-style user-space enclaves and maintain distinct APIs and execution models. This paper presents CCX, a firmware-based framework which enables unmodified Intel SGX applications to run on Arm CCA, preserving the mature SGX ecosystem’s programming abstractions, isolation guarantees, and executing without source code modifications.
Architectural Design and Semantic Preservation
Implementation Approach
The authors propose a firmware-centric solution in which SGX microcode instructions (ENCLU, ENCLS) are reimplemented and emulated within Arm CCA’s EL3 Monitor—leveraging privileged firmware to enforce isolation and minimize the TCB. SGX applications, including their SDK, kernel module, and compiler wrappers, are cross-compiled for Arm targets using a CCX-specific toolchain. All enclave-related operations (e.g., enclave entry/exit, memory management, attestation) are transparently rerouted through firmware handlers, preserving API compatibility and execution semantics at every layer.
A critical design decision is the use of a multi-GPT memory protection scheme: each enclave receives a dedicated granule protection table (GPT), marking enclave pages as field memory in the enclave’s GPT but inaccessible in all others (including system-wide GPTs and those used by the RMM or hypervisor). Context switches between enclave and non-enclave execution are accompanied by GPT switching, ensuring strict intra-process isolation analogous to SGX’s EPC/PMH guarantees.
Memory Management and Dynamic Expansion
SGX’s fixed-size EPC limitation and costly page swapping are replaced with dynamic, on-demand field memory assignment via Arm’s GPT mechanism. Unlike SGX, which relies on expensive EWB/ELDB/U microinstructions to shuffle EPC pages, CCX can expand the field enclave memory footprint without disk-based swapping, yielding substantial improvements for memory-intensive workloads.
Attestation Model
The paper outlines full support for local enclave attestation, emulating SGX’s EREPORT/EGETKEY primitives using mbed TLS in firmware. Although remote attestation is not currently feasible due to the absence of CCA hardware and attestation infrastructure, CCX is architected to integrate future CCA remote attestation protocols (via the immutable CPAK and provisioning enclaves) once hardware is available.
Correctness
Extensive validation is performed via QEMU-CCA emulation and a hardware-backed performance prototype on the Nitrogen8M Arm board. Representative SGX SDK applications—including cryptographic libraries, secure databases, and federated learning frameworks—were cross-compiled and executed on CCX without source modification. Behavioral parity with native SGX execution is demonstrated, confirming the preservation of enclave lifecycle semantics, API compatibility, and function-level isolation.
Microbenchmark Results and Overhead Analysis
Microbenchmarks of SGX microprograms reveal that the enclave creation routine (ECREATE) is an outlier due to the setup overhead of new GPTs (~15 ms), but this is a one-time cost. Enclave entry/exit overhead is minimal (~17.5 μs), supporting responsive system call and ECALL/OCALL interactions. The elimination of EPC page swapping yields measurable performance gains on memory-intensive server workloads.
NBench benchmarking highlights near-native performance in CCX enclaves, with overhead typically below 1% except for test cases bound by trusted library implementations. Compared to other SGX virtualization solutions (e.g., VSGX: 200%+ overhead), CCX demonstrates superior efficiency, competitive with the most optimized designs for intra-process isolation (e.g., SHELTER, HiveTEE).
Security Analysis
Threat Model and TCB Minimization
The CCX threat model mirrors Arm CCA’s default assumptions: only EL3 firmware is trusted; all other OS, hypervisor, RMM, and field software is potentially adversarial. By situating microprogram emulation and isolation enforcement in EL3, CCX achieves a minimal TCB (4,462 SLOC added to firmware, <1% increase), smaller than comparable SGX-reimplementation approaches. The multi-GPT scheme ensures that enclave memory is strictly inaccessible to all system software except for EL3, matching SGX’s microcode trust boundary.
Side Channel and Control Flow Integrity
CCX inherits side channel characteristics from the underlying hardware, mirroring SGX’s vulnerability profile. The implementation of AEX-Notify enables mitigation of controlled single-stepping attacks; synchronization barriers at enclave transitions (FEAT_SB) and prospective hardware improvements (FEAT_CSV3, FEAT_MEC) are incorporated as mitigations against speculative execution and cache attacks, pending real-world CCA hardware validation.
CCX’s firmware-based approach facilitates rapid updates and flexible deployment of security mitigations, unlike SGX’s more constrained microcode platform. The authors advocate for formal verification of the CCX Monitor using bounded model checking—a technique already applied to other Arm CCA firmware.
Implications, Limitations, and Future Directions
By bridging the ecosystem gap between Intel SGX and Arm CCA, CCX enables direct migration of the substantial SGX application base to Arm cloud environments. Practically, this obviates costly application refactoring, accelerates adoption of confidential computing workloads on Arm, and leverages mature tooling (SDK, kernel module) without the need for novel APIs or programming models.
A key limitation remains the absence of publicly available CCA hardware, constraining empirical evaluation of memory encryption and attestation implementations. The prototype’s reliance on emulation and substitute hardware introduces uncertainty in real-world security and performance attributes, but this limitation is shared across all current Arm CCA research.
Future work will focus on hardware-backed remote attestation for CCX enclaves, further optimization of trusted library functions, and integration of SGX library OSes (e.g., GRAMINE, OCCULUM) for expanded compatibility. The firmware-level implementation will also support development of novel defenses against microarchitectural attacks and flexible enclave feature extensions.
Conclusion
CCX represents a comprehensive solution to enclave portability across heterogeneous architectures, delivering a full SGX-compatible enclave framework on Arm CCA. The firmware-based microprogram emulation preserves strict intra-process isolation, reproduces security and performance guarantees comparable to SGX, and enables transparent migration of existing workloads. The minimal and clearly-defined TCB, coupled with performance gains from dynamic memory management, establishes a robust foundation for confidential computing on Arm platforms. As Arm CCA hardware matures, CCX is positioned to serve as a principal framework for secure application deployment and attestation in mixed-architecture cloud environments.
