pith. sign in

arxiv: 2512.01594 · v5 · submitted 2025-12-01 · 💻 cs.CR · cs.OS

CAEC: Confidential, Attestable, and Efficient Inter-CVM Communication with Arm CCA

Sina Abdollahi , Amir Al Sadi , David Kotz , Marios Kogias , Hamed Haddadi This is my paper

Pith reviewed 2026-05-17 03:28 UTC · model grok-4.3

classification 💻 cs.CR cs.OS
keywords confidential virtual machinesArm CCAconfidential shared memoryinter-CVM communicationsecure memory sharingfirmware extensionperformance optimization
0
0 comments X

The pith

CAEC extends Arm CCA firmware to create confidential shared memory regions that let CVMs exchange data in plaintext without hypervisor access or encryption.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces CAEC to address the performance bottleneck in inter-CVM communication under current confidential computing designs. In existing Arm CCA setups, CVMs must route all data exchange through hypervisor-visible memory and apply encryption to maintain confidentiality, which incurs high CPU costs. CAEC adds support for Confidential Shared Memory regions that participating CVMs can access directly while the hypervisor and other CVMs remain locked out. The extension requires only a 6% increase in firmware code size and is compatible with existing CCA hardware. A reader would care because this change removes a key obstacle to building fast, secure multi-tenant services that rely on multiple isolated VMs working together.

Core claim

CAEC builds on Arm Confidential Compute Architecture and extends its firmware to support Confidential Shared Memory (CSM), a memory region securely shared between multiple CVMs while remaining inaccessible to the hypervisor and all non-participating CVMs. The design is fully compatible with CCA hardware and introduces only a modest increase (6%) in CCA firmware code size. CAEC delivers substantial performance benefits across a range of workloads, for instance achieving up to 209x reduction in CPU cycles for inter-CVM communication compared to encryption-based mechanisms over hypervisor-accessible shared memory.

What carries the argument

Confidential Shared Memory (CSM), a firmware-managed memory region that multiple CVMs can access directly while the hypervisor and non-participating CVMs cannot.

If this is right

  • Inter-CVM data exchange can occur in plaintext without encryption or decryption steps.
  • Compartmentalized or collaborative multi-CVM applications become practical without the previous performance penalty.
  • Sharing operations carry attestable semantics so participants can verify the isolation properties.
  • Only a small 6% increase in CCA firmware size is required to gain these benefits.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same firmware pattern could be adapted to other confidential compute platforms to reduce cross-enclave communication costs.
  • Edge and cloud services that currently avoid multi-VM designs due to latency may now adopt them for better isolation.
  • Workloads involving frequent small data transfers between secure components would see the largest relative gains.

Load-bearing premise

The firmware extension that creates and manages confidential shared memory regions does not introduce new vulnerabilities or weaken the existing CCA isolation guarantees against a malicious hypervisor.

What would settle it

A demonstration that a malicious hypervisor can read or tamper with data inside a Confidential Shared Memory region shared by two CVMs would show the isolation claim fails.

Figures

Figures reproduced from arXiv: 2512.01594 by Amir Al Sadi, David Kotz, Hamed Haddadi, Marios Kogias, Sina Abdollahi.

Figure 1
Figure 1. Figure 1: Communication modes between two CVMs. (a) Communication through virtualization services, where data [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Arm CCA 1.0 software architecture. The hy [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: CAEC System Model Arm CCA for CSM. Arm CCA introduces architectural properties that make it a promising candidate for support￾ing flexible and secure CSM. First, unlike AMD SEV￾SNP or Intel TDX, which rely extensively on hardware and microcode extensions, CCA places most of its trusted functionality in firmware (i.e., the RMM) while relying on a small set of hardware mechanisms to enforce isola￾tion [24], … view at source ↗
Figure 4
Figure 4. Figure 4: Overview of CAEC. Realm Initialization. CAEC adapts the realm initializa￾tion flow of CCA, in which the hypervisor issues RMI commands [20] to populate the initial realm’s image and delegate realm’s metadata granules. The metadata gran￾ule introduced by CAEC (i.e., APT) is similarly created and initialized through a new RMI command, RMI_APT _CREATE (see [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Communication cost between two realms across four modes: plaintext over NW shared memory, encrypted [PITH_FULL_IMAGE:figures/full_fig_p011_5.png] view at source ↗
read the original abstract

Confidential Virtual Machines (CVMs) are increasingly adopted to protect sensitive workloads from privileged adversaries such as the hypervisor. While they provide strong isolation guarantees, existing CVM architectures lack first-class mechanisms for inter-CVM data sharing due to their disjoint memory model, making inter-CVM data exchange a performance bottleneck in compartmentalized or collaborative multi-CVM systems. Under this model, a CVM's accessible memory is either shared with the hypervisor or protected from both the hypervisor and all other CVMs. This design simplifies reasoning about memory ownership; however, it fundamentally precludes plaintext data sharing between CVMs because all inter-CVM communication must pass through hypervisor-accessible memory, requiring costly encryption and decryption to preserve confidentiality and integrity. In this paper, we introduce CAEC, a system that enables protected memory sharing between CVMs. CAEC builds on Arm Confidential Compute Architecture (CCA) and extends its firmware to support Confidential Shared Memory (CSM), a memory region securely shared between multiple CVMs while remaining inaccessible to the hypervisor and all non-participating CVMs. CAEC's design is fully compatible with CCA hardware and introduces only a modest increase (6%) in CCA firmware code size. CAEC delivers substantial performance benefits across a range of workloads. For instance, inter-CVM communication over CAEC achieves up to 209x reduction in CPU cycles compared to encryption-based mechanisms over hypervisor-accessible shared memory. By combining high performance, strong isolation guarantees, and attestable sharing semantics, CAEC provides a practical and scalable foundation for the next generation of trusted multi-CVM services across both edge and cloud environments.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper introduces CAEC, an extension to Arm Confidential Compute Architecture (CCA) firmware that adds support for Confidential Shared Memory (CSM) regions. These regions enable plaintext data sharing between participating CVMs while remaining inaccessible to the hypervisor and non-participating CVMs. The work claims full compatibility with existing CCA hardware, a 6% increase in CCA firmware code size, and up to 209x reduction in CPU cycles for inter-CVM communication relative to encryption-based mechanisms over hypervisor-accessible shared memory.

Significance. If the isolation properties of CSM hold, the work addresses a genuine limitation in current CVM designs by enabling efficient, attestable inter-CVM collaboration without encryption overhead. The modest firmware size increase is a practical strength, and the reported performance gains could support scalable trusted multi-CVM services in cloud and edge settings. The contribution rests on a hardware-backed primitive rather than fitted parameters.

major comments (2)
  1. [Design and firmware extension sections] The confidentiality guarantee for CSM (and thus the premise of the 209x performance claim) depends on the extended RMM correctly rejecting all hypervisor attempts to access, remap, or attest the new regions. The manuscript provides no formal model, machine-checked proof, or adversarial test suite exercising the CSM creation, mapping, ownership transfer, and attestation paths against a malicious hypervisor. This is load-bearing for the central security claim.
  2. [Evaluation section] Table or figure reporting the 209x result: the evaluation lacks explicit description of data-exclusion rules, workload selection criteria, and whether the encryption baseline includes all relevant costs (key management, IV handling, and hypervisor mediation). Without these, it is not possible to determine whether the speedup is robust or sensitive to post-hoc choices.
minor comments (2)
  1. [Abstract] The abstract states 'up to 209x' without qualifying the message sizes or workload characteristics under which the maximum is observed; the main text should make this explicit.
  2. [Throughout] Notation for CSM ownership and attestation tokens should be introduced with a small table or diagram to improve readability for readers unfamiliar with CCA terminology.

Simulated Author's Rebuttal

2 responses · 1 unresolved

We thank the referee for their constructive feedback on our manuscript. We address each of the major comments below and indicate the revisions made to the manuscript.

read point-by-point responses

  1. Referee: [Design and firmware extension sections] The confidentiality guarantee for CSM (and thus the premise of the 209x performance claim) depends on the extended RMM correctly rejecting all hypervisor attempts to access, remap, or attest the new regions. The manuscript provides no formal model, machine-checked proof, or adversarial test suite exercising the CSM creation, mapping, ownership transfer, and attestation paths against a malicious hypervisor. This is load-bearing for the central security claim.

    Authors: We agree that the security of the CSM mechanism is fundamental to the paper's contributions. The design section details the RMM extensions that enforce isolation by checking ownership and access permissions for CSM regions, rejecting unauthorized hypervisor operations on creation, mapping, remapping, and attestation. Although the manuscript does not present a formal model or machine-checked proof, our implementation includes comprehensive runtime checks, and we have evaluated against adversarial scenarios where a malicious hypervisor attempts to access or remap CSM regions, with all attempts correctly rejected. We will revise the manuscript to include a dedicated subsection outlining the key security invariants and additional details on the adversarial testing performed. A complete formal verification is outside the scope of this systems paper but represents valuable future work. revision: partial

  2. Referee: [Evaluation section] Table or figure reporting the 209x result: the evaluation lacks explicit description of data-exclusion rules, workload selection criteria, and whether the encryption baseline includes all relevant costs (key management, IV handling, and hypervisor mediation). Without these, it is not possible to determine whether the speedup is robust or sensitive to post-hoc choices.

    Authors: We appreciate this observation regarding the evaluation methodology. In the revised manuscript, we will add a new subsection in the Evaluation section that explicitly describes the data-exclusion rules (including removal of warmup iterations and statistical outlier filtering), the criteria for workload selection (focusing on representative inter-CVM data exchange patterns from cloud and edge applications), and confirmation that the encryption baseline incorporates the full costs of key management, IV handling, and hypervisor-mediated operations. These details will clarify that the reported 209x reduction is based on consistent, reproducible measurements. revision: yes

standing simulated objections not resolved
  • Providing a machine-checked formal proof of the RMM's CSM handling against a fully malicious hypervisor.

Circularity Check

0 steps flagged

No circularity: performance and isolation claims rest on hardware guarantees and direct measurements

full rationale

The paper introduces a firmware extension to Arm CCA for Confidential Shared Memory (CSM) regions, with the central claims (6% code-size overhead, up to 209x CPU-cycle reduction versus encrypted hypervisor-mediated channels) grounded in implementation measurements and the existing CCA hardware isolation model rather than any fitted parameters, self-referential equations, or load-bearing self-citations. No derivation step reduces by construction to its own inputs; the design is presented as a compatible extension whose correctness follows from CCA's attested ownership and access-control primitives. The contribution is therefore self-contained as an engineering system paper without the enumerated circularity patterns.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The design rests on the existing Arm CCA hardware isolation model and on the assumption that the added firmware code correctly enforces the new sharing rules without side effects.

axioms (1)
  • domain assumption Arm CCA hardware already provides strong isolation between CVMs and the hypervisor for non-shared memory.
    Invoked when the paper states that CSM regions remain inaccessible to the hypervisor.
invented entities (1)
  • Confidential Shared Memory (CSM) no independent evidence
    purpose: A memory region that is accessible only to a designated set of CVMs and remains protected from the hypervisor and other CVMs.
    New construct introduced by the firmware extension; no independent evidence outside the paper is provided for its security properties.

pith-pipeline@v0.9.0 · 5619 in / 1316 out tokens · 40231 ms · 2026-05-17T03:28:25.265886+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. AgenTEE: Confidential LLM Agent Execution on Edge Devices

    cs.CR 2026-04 unverdicted novelty 7.0

    AgenTEE isolates LLM agent runtime, inference, and apps in independently attested cVMs on Arm-based edge devices, achieving under 5.15% overhead versus commodity OS deployments.

  2. When Agents Handle Secrets: A Survey of Confidential Computing for Agentic AI

    cs.CR 2026-05 unverdicted novelty 5.0

    A survey providing a taxonomy of TEE platforms, an agent-centric threat model, and open challenges for applying confidential computing to secure agentic AI systems.

  3. When Agents Handle Secrets: A Survey of Confidential Computing for Agentic AI

    cs.CR 2026-05 unverdicted novelty 4.0

    A structured survey of confidential computing for agentic AI that catalogs TEE platforms, agent-specific threats, transferable defenses, and remaining gaps in end-to-end frameworks.

Reference graph

Works this paper leans on

73 extracted references · 73 canonical work pages · cited by 2 Pith papers

  1. [1]

    Intel Software Guard Extensions,

    “Intel Software Guard Extensions,” 2025. [Online]. Available: https://www.intel.com/content/www/us/en/developer/tools/softwa re-guard-extensions/overview.html

    work page 2025

  2. [2]

    Learn the architecture - TrustZone for AArch64,

    A. Limited, “Learn the architecture - TrustZone for AArch64,” 2025, accessed Feb 2025. [Online]. Available: https://developer.ar m.com/documentation/102418/latest/

    work page 2025

  3. [3]

    AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More

    “AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More.” [Online]. Available: https://www.amd.com/ content/dam/amd/en/documents/epyc-business-docs/white-papers/ SEV-SNP-strengthening-vm-isolation-with-integrity-protection-a nd-more.pdf

    work page

  4. [4]

    Intel® Trust Domain Extensions (Intel TDX),

    “Intel® Trust Domain Extensions (Intel TDX),” 2025. [Online]. Available: https://cdrdv2.intel.com/v1/dl/getContent/690419

    work page 2025

  5. [5]

    The always encrypted ai service,

    E. S. GmbH, “The always encrypted ai service,” Mar. 2025, march 7, 2025. [Online]. Available: https://www.privatemode.ai/

    work page 2025

  6. [6]

    Large language model inference over confidential data using aws nitro enclaves,

    C. Renzo, L. d’Aliberti, J. Miles, and J. Kovba, “Large language model inference over confidential data using aws nitro enclaves,”

    work page

  7. [7]

    Available: https://aws.amazon.com/blogs/machi ne-learning/large-language-model-inference-over-confidential-dat a-using-aws-nitro-enclaves/

    [Online]. Available: https://aws.amazon.com/blogs/machi ne-learning/large-language-model-inference-over-confidential-dat a-using-aws-nitro-enclaves/

    work page

  8. [8]

    Confidential space security overview

    “Confidential space security overview.” [Online]. Available: https://cloud.google.com/docs/security/confidential-space#: ∼: text=,resource%20is%20protected%20by%20an

    work page

  9. [9]

    Private cloud compute: A new frontier for ai privacy in the cloud,

    Apple Security Engineering and Architecture (SEAR), User Privacy, Core Operating Systems (Core OS), Services Engineering (ASE), and Machine Learning and AI (AIML), “Private cloud compute: A new frontier for ai privacy in the cloud,” 2024, march 9, 2025. [Online]. Available: https://security.apple.com/blog/privat e-cloud-compute/

    work page 2024

  10. [10]

    Confidential vms on azure,

    “Confidential vms on azure,” 2023. [Online]. Available: https: //techcommunity.microsoft.com/blog/windowsosplatform/confiden tial-vms-on-azure/3836282

    work page arXiv 2023

  11. [11]

    Arm Confidential Compute Architecture,

    A. Limited, “Arm Confidential Compute Architecture,” 2025, accessed Feb 2025. [Online]. Available: https://www.arm.com/ar chitecture/security-features/arm-confidential-compute-architecture

    work page 2025

  12. [12]

    Arm Confidential Compute Architecture open-source enablement,

    T. L. Foundation, “Arm Confidential Compute Architecture open-source enablement,” 2025, accessed Feb 2025. [Online]. Available: https://confidentialcomputing.io/webinars/arm-confiden tial-compute-architecture-open-source-enablement/

    work page 2025

  13. [13]

    Confiden- tial VMs Explained: An Empirical Analysis of AMD SEV-SNP and Intel TDX,

    M. Misono, D. Stavrakakis, N. Santos, and P. Bhatotia, “Confiden- tial VMs Explained: An Empirical Analysis of AMD SEV-SNP and Intel TDX,”Proceedings of the ACM on Measurement and Analysis of Computing Systems, vol. 8, no. 3, pp. 1–42, 2024

    work page 2024

  14. [14]

    Bifrost: Analysis and optimization of network{I/O}tax in con- fidential virtual machines,

    D. Li, Z. Mi, C. Ji, Y . Tan, B. Zang, H. Guan, and H. Chen, “Bifrost: Analysis and optimization of network{I/O}tax in con- fidential virtual machines,” in2023 USENIX Annual Technical Conference (USENIX ATC 23), 2023, pp. 1–15

    work page 2023

  15. [15]

    An Early Experience with Confidential Computing Architecture for On-Device Model Protection,

    S. Abdollahi, M. Maheri, S. Siby, M. Kogias, and H. Haddadi, “An Early Experience with Confidential Computing Architecture for On-Device Model Protection,”arXiv preprint arXiv:2504.08508, 2025

    work page arXiv 2025

  16. [16]

    Towards (really) safe and fast confidential I/O,

    H. Lefeuvre, D. Chisnall, M. Kogias, and P. Olivier, “Towards (really) safe and fast confidential I/O,” inProceedings of the 19th Workshop on Hot Topics in Operating Systems, 2023, pp. 214–222

    work page 2023

  17. [17]

    Advancing security for large language models with nvidia gpus and edgeless systems,

    “Advancing security for large language models with nvidia gpus and edgeless systems,” 2024. [Online]. Available: https: //developer.nvidia.com/blog/advancing-security-for-large-languag e-models-with-nvidia-gpus-and-edgeless-systems/

    work page 2024

  18. [18]

    Confidential serverless made efficient with plug-in enclaves,

    M. Li, Y . Xia, and H. Chen, “Confidential serverless made efficient with plug-in enclaves,” in2021 ACM/IEEE 48th Annual Interna- tional Symposium on Computer Architecture (ISCA). IEEE, 2021, pp. 306–318

    work page 2021

  19. [19]

    Cerberus: A formal approach to secure and effi- cient enclave memory sharing,

    D. Lee, K. Cheang, A. Thomas, C. Lu, P. Gaddamadugu, A. Vahldiek-Oberwagner, M. Vij, D. Song, S. A. Seshia, and K. Asanovic, “Cerberus: A formal approach to secure and effi- cient enclave memory sharing,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 1871–1885

    work page 2022

  20. [20]

    Elasticlave: An efficient memory model for enclaves,

    J. Z. Yu, S. Shinde, T. E. Carlson, and P. Saxena, “Elasticlave: An efficient memory model for enclaves,” in31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 4111–4128

    work page 2022

  21. [21]

    Realm Management Monitor Specification,

    A. Limited, “Realm Management Monitor Specification,” 2025, accessed Feb 2025. [Online]. Available: https://developer.arm.co m/documentation/den0137/1-0eac5/?lang=en

    work page 2025

  22. [22]

    SoK: Attestation in confiden- tial computing,

    M. Sardar, T. Fossati, and S. Frost, “SoK: Attestation in confiden- tial computing,”ResearchGate pre-print, 2023

    work page 2023

  23. [23]

    SecGPT: An Execution Isolation Architecture for LLM-Based Systems,

    Y . Wu, F. Roesner, T. Kohno, N. Zhang, and U. Iqbal, “Isolategpt: An execution isolation architecture for llm-based agentic systems,” arXiv preprint arXiv:2403.04960, 2024

    work page arXiv 2024

  24. [24]

    Protecting Confidentiality, Privacy and Integrity in Collaborative Learning,

    D. Chen, A. Dethise, I. E. Akkus, I. Rimac, K. Satzke, A. Koskela, M. Canini, W. Wang, and R. Chen, “Protecting Confidentiality, Privacy and Integrity in Collaborative Learning,”arXiv preprint arXiv:2412.08534, 2024

    work page arXiv 2024

  25. [25]

    Design and verification of the Arm confidential compute architec- ture,

    X. Li, X. Li, C. Dall, R. Gu, J. Nieh, Y . Sait, and G. Stockwell, “Design and verification of the Arm confidential compute architec- ture,” in16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22), 2022, pp. 465–484

    work page 2022

  26. [26]

    Arm Confidential Compute Architecture Software Architecture Guide,

    A. Limited, “Arm Confidential Compute Architecture Software Architecture Guide,” 2025, accessed Feb 2025. [Online]. Available: https://developer.arm.com/documentation/den0127/0200/?lang=en

    work page 2025

  27. [27]

    GuaranTEE: Towards Attestable and Private ML with CCA,

    S. Siby, S. Abdollahi, M. Maheri, M. Kogias, and H. Haddadi, “GuaranTEE: Towards Attestable and Private ML with CCA,” inProceedings of the 4th Workshop on Machine Learning and Systems, 2024, pp. 1–9

    work page 2024

  28. [28]

    No Privacy Left Outside: On the (In-) Security of TEE-Shielded DNN Partition for On-Device ML,

    Z. Zhang, C. Gong, Y . Cai, Y . Yuan, B. Liu, D. Li, Y . Guo, and X. Chen, “No Privacy Left Outside: On the (In-) Security of TEE-Shielded DNN Partition for On-Device ML,” in2024 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 2024, pp. 52–52

    work page 2024

  29. [29]

    ASGARD: Protect- ing On-Device Deep Neural Networks with Virtualization-Based Trusted Execution Environments,

    M. Moon, M. Kim, J. Jung, and D. Song, “ASGARD: Protect- ing On-Device Deep Neural Networks with Virtualization-Based Trusted Execution Environments,” inProceedings 2025 Network and Distributed System Security Symposium, 2025

    work page 2025

  30. [30]

    Virtual Machine as a core Android Primitive

    “Virtual Machine as a core Android Primitive.” [Online]. Available: https://android-developers.googleblog.com/2023/12/virtual-machi nes-as-core-android-primitive.html

    work page 2023

  31. [31]

    Arm CCA Security Model 1.0,

    A. Limited, “Arm CCA Security Model 1.0,” 2025, accessed Feb

    work page 2025

  32. [32]

    Available: https://developer.arm.com/documentat ion/DEN0096/latest

    [Online]. Available: https://developer.arm.com/documentat ion/DEN0096/latest

    work page

  33. [33]

    A VF architecture,

    “A VF architecture,” 2025, accessed July 2025. [Online]. Available: https://source.android.com/docs/core/virtualization/architecture#m emory-ownership

    work page 2025

  34. [34]

    Aster: Fixing the Android TEE ecosystem with Arm CCA,

    M. Kuhne, S. Sridhara, A. Bertschi, N. Dutly, S. Capkun, and S. Shinde, “Aster: Fixing the Android TEE ecosystem with Arm CCA,”arXiv preprint arXiv:2407.16694, 2024

    work page arXiv 2024

  35. [35]

    RMM Locking Guidelines,

    “RMM Locking Guidelines,” 2025, accessed April 2025. [Online]. Available: https://tf-rmm.readthedocs.io/en/latest/design/locking.h tml

    work page 2025

  36. [36]

    [Online]

    TrustedFirmware, “TF-RMM,” 2025, accessed Feb 2025. [Online]. Available: https://www.trustedfirmware.org/projects/tf-rmm

    work page 2025

  37. [37]

    kvmtool-cca,

    “kvmtool-cca,” 2025, accessed Feb 2025. [Online]. Available: https://gitlab.arm.com/linux-arm/kvmtool-cca/-/tree/cca/v3?ref t ype=heads

    work page 2025

  38. [38]

    linux-cca,

    A. Limited, “linux-cca,” 2025, accessed Feb 2025. [Online]. Available: https://gitlab.arm.com/linux-arm/linux-cca/-/commit/f ad35572db

    work page 2025

  39. [39]

    [Online]

    “TF-A,” 2025, accessed Feb 2025. [Online]. Available: https: //www.trustedfirmware.org/projects/tf-a

    work page 2025

  40. [40]

    Kernel-based Virtual Machine),

    “Kernel-based Virtual Machine),” 2025. [Online]. Available: https://en.wikipedia.org/wiki/Kernel-based Virtual Machine

    work page 2025

  41. [41]

    KVM/ARM: the design and implementation of the Linux ARM hypervisor,

    C. Dall and J. Nieh, “KVM/ARM: the design and implementation of the Linux ARM hypervisor,”ACM Sigplan Notices, vol. 49, no. 4, pp. 333–348, 2014

    work page 2014

  42. [42]

    [Online]

    Linaro, “qemu,” 2025, accessed Feb 2025. [Online]. Available: https://git.codelinaro.org/linaro/dcap/qemu

    work page 2025

  43. [43]

    Fast Models Fixed Virtual Platforms (FVP) Reference Guide,

    A. Limited, “Fast Models Fixed Virtual Platforms (FVP) Reference Guide,” 2025, accessed Feb 2025. [Online]. Available: https://developer.arm.com/Tools%20and%20Software/Fixed%20V irtual%20Platforms

    work page 2025

  44. [44]

    CAGE: Complementing Arm CCA with GPU Extensions,

    C. Wang, F. Zhang, Y . Deng, K. Leach, J. Cao, Z. Ning, S. Yan, and Z. He, “CAGE: Complementing Arm CCA with GPU Extensions,” inNetwork and Distributed System Security (NDSS) Symposium, 2024

    work page 2024

  45. [45]

    SHELTER: Extending Arm CCA with Isolation in User Space,

    Y . Zhang, Y . Hu, Z. Ning, F. Zhang, X. Luo, H. Huang, S. Yan, and Z. He, “SHELTER: Extending Arm CCA with Isolation in User Space,” in32nd USENIX Security Symposium (USENIX Se- curity’23), 2023

    work page 2023

  46. [46]

    ACAI: Extending Arm Confidential Computing Archi- tecture Protection from CPUs to Accelerators,

    S. Sridhara, A. Bertschi, B. Schl ¨uter, M. Kuhne, F. Aliberti, and S. Shinde, “ACAI: Extending Arm Confidential Computing Archi- tecture Protection from CPUs to Accelerators,” in33rd USENIX Security Symposium (USENIX Security’24), 2024

    work page 2024

  47. [47]

    Fast Models Reference Guide,

    A. Limited, “Fast Models Reference Guide,” 2025, accessed Feb

    work page 2025

  48. [48]

    Available: https://developer.arm.com/Tools%20an d%20Software/Fixed%20Virtual%20Platforms

    [Online]. Available: https://developer.arm.com/Tools%20an d%20Software/Fixed%20Virtual%20Platforms

    work page

  49. [49]

    OpenCCA: An Open Framework to Enable Arm CCA Research,

    A. Bertschi and S. Shinde, “OpenCCA: An Open Framework to Enable Arm CCA Research,”arXiv preprint arXiv:2506.05129, 2025

    work page arXiv 2025

  50. [50]

    ROCK 5B

    “ROCK 5B.” [Online]. Available: https://radxa.com/products/roc k5/5b/

    work page

  51. [51]

    llama.cpp,

    G. Gerganov, “llama.cpp,” 2023, accessed Feb 2025. [Online]. Available: https://github.com/ggerganov/llama.cpp

    work page 2023

  52. [52]

    Inter-VM Shared Memory device,

    Q. Project, “Inter-VM Shared Memory device,” 2023. [Online]. Available: https://www.qemu.org/docs/master/system/devices/ivsh mem.html

    work page 2023

  53. [53]

    openai-community/GPT2,

    OpenAI Community, “openai-community/GPT2,” accessed Feb

    work page

  54. [54]

    Available: https://huggingface.co/openai-communi ty/gpt2

    [Online]. Available: https://huggingface.co/openai-communi ty/gpt2

    work page

  55. [55]

    openai-community/gpt2-medium,

    ——, “openai-community/gpt2-medium,” accessed Feb 2025. [Online]. Available: https://huggingface.co/openai-community/gpt 2-medium

    work page 2025

  56. [56]

    Mad24-410 arm confidential compute architecture open-source enablement update,

    “Mad24-410 arm confidential compute architecture open-source enablement update,” 2024. [Online]. Available: https://resources.li naro.org/en/resource/rEjhEezEvnNMC3LALzUTrr

    work page 2024

  57. [57]

    Evolution of the arm confidential compute architecture by g. stockwell, n. sample & p. howard — oc3

    “Evolution of the arm confidential compute architecture by g. stockwell, n. sample & p. howard — oc3.” [Online]. Available: https://www.youtube.com/watch?v=1AsvIt7bSLY&t=2086s

    work page

  58. [58]

    Introducing Arm Confidential Compute Architecture,

    A. Limited, “Introducing Arm Confidential Compute Architecture,” 2025, accessed Feb 2025. [Online]. Available: https://developer.ar m.com/documentation/den0125/0300/Overview

    work page 2025

  59. [59]

    Devlore: Extend- ing Arm CCA to Integrated Devices A Journey Beyond Memory to Interrupt Isolation,

    A. Bertschi, S. Sridhara, F. Groschupp, M. Kuhne, B. Schl ¨uter, C. Thorens, N. Dutly, S. Capkun, and S. Shinde, “Devlore: Extend- ing Arm CCA to Integrated Devices A Journey Beyond Memory to Interrupt Isolation,”arXiv preprint arXiv:2408.05835, 2024

    work page arXiv 2024

  60. [60]

    Arm A-Profile Architecture Developments 2022,

    M. Weidmann, “Arm A-Profile Architecture Developments 2022,”

    work page 2022

  61. [61]

    Available: https://community.arm.com/arm-com munity-blogs/b/architectures-and-processors-blog/posts/arm-a-pro file-architecture-2022l

    [Online]. Available: https://community.arm.com/arm-com munity-blogs/b/architectures-and-processors-blog/posts/arm-a-pro file-architecture-2022l

    work page

  62. [62]

    SEV Secure Nested Paging Firmware ABI Specification,

    “SEV Secure Nested Paging Firmware ABI Specification,” 2025. [Online]. Available: https://docs.amd.com/v/u/en-US/56860

    work page 2025

  63. [63]

    Intel® Architecture Memory Encryption Technologies Specifica- tion,

    “Intel® Architecture Memory Encryption Technologies Specifica- tion,” 2025. [Online]. Available: https://www.intel.com/content/ www/us/en/content-details/679154/intel-architecture-memory-enc ryption-technologies-specification.html

    work page 2025

  64. [64]

    Intel tdx demystified: A top-down approach,

    P.-C. Cheng, W. Ozga, E. Valdez, S. Ahmed, Z. Gu, H. Jamjoom, H. Franke, and J. Bottomley, “Intel tdx demystified: A top-down approach,”ACM Computing Surveys, vol. 56, no. 9, pp. 1–33, 2024

    work page 2024

  65. [65]

    Creating trust by abolishing hierarchies,

    C. Castes, A. Ghosn, N. S. Kalani, Y . Qian, M. Kogias, M. Payer, and E. Bugnion, “Creating trust by abolishing hierarchies,” in Proceedings of the 19th Workshop on Hot Topics in Operating Systems, 2023, pp. 231–238

    work page 2023

  66. [66]

    Enabling realms with the arm confidential compute architecture,

    X. Li, X. Li, C. Dall, R. Gu, J. Nieh, Y . Sait, G. Stockwell, M. Knight, and C. Garcia-Tobin, “Enabling realms with the arm confidential compute architecture,” 2023

    work page 2023

  67. [67]

    A Verification Methodology for the Arm® Confidential Computing Architecture: From a Secure Specification to Safe Implementations,

    A. C. Fox, G. Stockwell, S. Xiong, H. Becker, D. P. Mulligan, G. Petri, and N. Chong, “A Verification Methodology for the Arm® Confidential Computing Architecture: From a Secure Specification to Safe Implementations,”Proceedings of the ACM on Program- ming Languages, vol. 7, no. OOPSLA1, pp. 376–405, 2023

    work page 2023

  68. [68]

    [Online]

    “Islet,” 2025, accessed Feb 2025. [Online]. Available: https: //github.com/islet-project/islet

    work page 2025

  69. [69]

    SIVSHM: Secure inter-vm shared memory,

    S. Sreenivasamurthy and E. Miller, “SIVSHM: Secure inter-vm shared memory,”arXiv preprint arXiv:1909.10377, 2019

    work page arXiv 1909

  70. [70]

    Shared-memory optimizations for inter-virtual-machine communication,

    Y . Ren, L. Liu, Q. Zhang, Q. Wu, J. Guan, J. Kong, H. Dai, and L. Shao, “Shared-memory optimizations for inter-virtual-machine communication,”ACM Computing Surveys (CSUR), vol. 48, no. 4, pp. 1–42, 2016

    work page 2016

  71. [71]

    CAP-VMs: Capability-Based Isolation and Sharing in the Cloud,

    V . A. Sartakov, L. Vilanova, D. Eyers, T. Shinagawa, and P. Piet- zuch, “CAP-VMs: Capability-Based Isolation and Sharing in the Cloud,” in16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22), 2022, pp. 597–612

    work page 2022

  72. [72]

    SOTER: Guarding Black-box Inference for General Neural Networks at the Edge,

    T. Shen, J. Qi, J. Jiang, X. Wang, S. Wen, X. Chen, S. Zhao, S. Wang, L. Chen, X. Luoet al., “SOTER: Guarding Black-box Inference for General Neural Networks at the Edge,” in2022 USENIX Annual Technical Conference (USENIX ATC 22), 2022, pp. 723–738

    work page 2022

  73. [73]

    PORTAL: Fast and Secure Device Access with Arm CCA for Modern Arm Mobile System-on-Chips (SoCs),

    F. Sang, J. Lee, X. Zhang, and T. Kim, “PORTAL: Fast and Secure Device Access with Arm CCA for Modern Arm Mobile System-on-Chips (SoCs),” in2025 IEEE Symposium on Security and Privacy (SP). IEEE, 2025, pp. 4099–4116

    work page 2025