OpenCCA: An Open Framework to Enable Arm CCA Research

Andrin Bertschi; Shweta Shinde

REVIEW 3 major objections 5 minor 42 references

OpenCCA: An Open Framework to Enable Arm CCA Research

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read OpenCCA lets CCA-bound code run on commodity Armv8.2 hardware for performance evaluation while preserving functional correctness.

desk verdict Useful open framework for Arm CCA prototyping; the big caveat is that performance numbers rest on unvalidated software stand-ins for RME hardware, so treat it as a functional dev platform plus rough performance estimate, not a validated timing model. read the letter →

arxiv 2506.05129 v1 pith:FWCCU4OL submitted 2025-06-05 cs.CR

Andrin Bertschi , Shweta Shinde This is my paper

classification cs.CR

keywords ArmCCAconfidentialcomputingRMEperformanceemulationTrustedFirmware-ARMMRK3588FVP

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

OpenCCA claims that researchers can run Arm CCA-bound code on commodity Armv8.2 hardware instead of waiting for RME-enabled CPUs. The paper shows that by adapting TF-A, the RMM, and U-Boot, a software-emulated realm world can run on a $250 RK3588 board while keeping the hypervisor, guest kernel, and VMM unchanged. It reports cycle- and instruction-level measurements for CVM boot, RMI/SMC round trips, and GPT delegation, and argues these are more useful than FVP instruction counts because the board has a real microarchitectural model. If true, this gives CCA researchers a reusable, affordable performance-measurement platform and a common baseline for comparing designs.

What carries the argument

The central mechanism is the software-emulated realm world multiplexed inside the architectural normal world. TF-A manages world identity through a memory-resident NSE' bit, substitutes missing Granule Protection Check and TLB instructions with dummy registers and a full TLB flush, and builds Granule Protection Tables in BL31. The RMM adapts translation-table geometry, cache maintenance, and timer handling so that an unmodified hypervisor, guest kernel, and VMM can run a confidential VM. This carries the argument because it lets any CCA design that works on Arm's FVP simulator be transplanted onto OpenCCA without higher-level software changes.

What would settle it

Run OpenCCA's RMI delegation and SMC benchmarks on the first commercially available Armv9 RME board using the same binaries and workload; if the cycle counts for RMI_GRANULE_DELEGATE or the SMC round trip diverge from OpenCCA's reported 7,988 and 421 cycles by a large margin, the full-TLB-flush and dummy-register substitutions are not representative proxies.

Watch

Extended reading notes

Core claim

The central discovery is a systematic software adaptation that makes a non-CCA Armv8.2 board execute CCA-bound code. OpenCCA introduces a software realm world inside the architectural normal world by storing an extra world bit (NSE') in saved CPU context, since the RK3588 lacks the hardware NSE bit. Missing RME instructions are replaced with dummy system registers and a full TLB flush; GPT construction is moved from BL2 into BL31; the RMM is changed to use 64MB translation tables instead of Armv8.4 small translation tables, to avoid Force Write Back by using cache maintenance, and to handle timer virtualization without ECV by setting offsets to zero and masking timers with EL0 registers; and U-Boot bundles the RMM into the firmware image. The result is that an unmodified hypervisor, guest kernel, and kvmtool can run a CVM, and the paper reports numbers such as a 256MB CVM boot costing 1,900 instructions and 2,647 cycles and an RMI round trip costing 932 instructions and 3,370 cycles.

Load-bearing premise

The whole platform's usefulness as a performance oracle rests on the assumption that replacing missing RME pieces with full TLB flushes, dummy registers, and no memory encryption approximates real CCA costs closely enough; the paper does not validate this against real CCA hardware.

Editorial extensions

If this is right

A CCA design validated on Arm's FVP simulator can be moved to OpenCCA without changes to the hypervisor, guest kernel, or VMM, giving researchers a functional checkpoint on real hardware.
CVM boot, RMI, SMC, and GPT delegation overheads become measurable in cycles and instructions on a $250 board, so CCA papers can report comparable numbers instead of FVP instruction counts.
The two case studies—a dual-GPT design and a shadow-GPT design—were reimplemented in under five person-hours each, indicating that new CCA designs can be prototyped quickly on OpenCCA.
The authors argue that OpenCCA's performance estimates carry less error than FVP instruction counts, because the RK3588 has a real microarchitecture even though it lacks RME.
Porting to a newer Armv8.2 board would require only a subset of the original porting work, since more CCA-relevant features may be natively supported.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If OpenCCA becomes a common benchmark substrate, CCA papers could report cycle counts measured on the same board, making cross-paper performance claims more directly comparable than today's FVP or ad-hoc prototypes.
The paper's substitution of a full TLB flush for the missing GPC/TLB instructions likely overestimates real delegation costs, so OpenCCA's reported RMIs may be upper bounds on GPC-related overheads; actual RME hardware could be faster.
A testable extension is to run the same OpenCCA benchmark on several Armv8.2 boards to quantify board-to-board variance; the paper motivates this concern but does not measure it.
The authors note OpenCCA does not enforce CCA-equivalent security, so it is a performance and compatibility layer; combining it with a security-preserving virtualization approach could give a platform that is both secure and measurable.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

OpenCCA is the first reusable open stack for running CCA-bound code on a commodity Armv8.2 board, and that is genuinely useful. Prior CCA papers each bolted together one-off prototypes with dummy CCA operations; OpenCCA systematically modifies TF-A, RMM, and U-Boot so the hypervisor, guest kernel, and kvmtool stay untouched. The LoC counts are concrete (940/1440/216), the measurements are repeated (100 boots, 5M invocations) with standard deviations, and the FVP consistency check for a CPU-bound workload is sensible. The board survey and the Table 1 taxonomy of prior CCA work are also worth having. The case studies (Two-GPT, Shadow GPT) show the framework really is adaptable; five hours for a new design is a meaningful data point.

The weak point is the paper's central claim about performance. OpenCCA's value as a measurement platform depends on software substitutes for missing RME features costing about what the real hardware would. The paper replaces GPC/TLB operations with a full TLB flush and dummy registers, and it omits memory encryption entirely. Sec. 7 asserts the resulting error is smaller than FVP's lack of a microarchitectural model, but that is an assertion, not a demonstration. A full TLB flush on every realm/hypervisor switch probably overestimates RME's TLB invalidation cost; missing memory encryption underestimates memory-side overhead. Neither direction is quantified. The paper even mentions an alternative patchset that removes the TLB flush by reserving ASIDs, but that patchset is not evaluated, so the main reported numbers depend on the more pessimistic approximation. That matters because a researcher wanting cycle-level estimates for a CCA design needs to know whether OpenCCA's overheads are in the right ballpark. The paper doesn't establish that yet.

Also minor: validation is limited to a CPU-intensive workload, and there is no real CCA hardware to compare against. That second part isn't the authors' fault, but it means the central validation has to be argued carefully, and this paper argues it too quickly. The citation pattern is fine; the authors cite their own earlier CCA prototypes for motivation, which is appropriate, and the prior table is useful.

Who is this for: systems and security researchers working on Arm CCA who want a functional development platform and rough performance estimates. That is a real audience, and the paper deserves a serious referee. I would send it to review with the instruction that the authors either add sensitivity analysis around the TLB flush and encryption omissions, or clearly reposition the paper as a functional emulation platform with preliminary performance, not a validated performance model.

Referee Report

3 major / 5 minor

Summary. The paper presents OpenCCA, an open-source framework that adapts the Arm CCA software stack (TF-A, RMM, U-Boot) to execute CCA-bound code on a commodity Armv8.2 RK3588 board that lacks RME hardware support. The framework introduces a software-emulated realm world, substitutes missing RME features (GPC/GPT, TLBI PAALLOS, FWB, ECV) with dummy registers, full TLB flushes, and cache-maintenance operations, and keeps the hypervisor, guest kernel, and VMM unchanged. The evaluation reports repeated measurements (100 CVM boots, 5M RMI/SMC invocations) of life-cycle metrics such as CVM boot time, RMI/SMC round trips, and granule delegation, together with two case studies (Two-GPT and Shadow GPT) reimplemented from prior CCA papers. The paper claims that OpenCCA enables CCA performance evaluation on low-cost hardware while preserving functional compatibility with Arm's FVP-based CCA reference stack.

Significance. If the performance-fidelity claim holds, OpenCCA would be a valuable, low-cost research platform that addresses a real fragmentation problem in CCA research: the field currently relies on ad-hoc prototypes on diverse, often unavailable boards, with inconsistent performance metrics. The paper's concrete strengths are its open-source implementation with modest LoC changes (940/1440/216 for TF-A/RMM/U-Boot), reproducible measurement methodology, an instructive survey of 19 CCA papers, and two case studies that demonstrate adaptability. However, the central utility as a performance-measurement platform rests on an unvalidated assumption: that software substitutions for missing RME hardware are closer to real CCA costs than FVP's timing model. This assumption is load-bearing because the paper explicitly recommends OpenCCA for performance evaluation and warns against using FVP for that purpose.

major comments (3)

The paper's central claim that OpenCCA provides meaningful performance estimates depends on the assertion in Sec. 7 that the error from missing RME features (GPC, realm/root world, memory encryption) is smaller than FVP's lack of a microarchitectural model. No supporting measurement, calibration, or quantitative argument is provided. In fact, the substitutions in Secs. 3.1 and 3.2 are likely to be biased in opposite directions: a full EL2 TLB flush on every RMM/normal-world context switch overestimates the cost of TLBI PAALLOS, while the complete omission of memory encryption in the design underestimates real CCA memory access costs. The alternative ASID-reservation patchset mentioned in Sec. 3.1 would eliminate the TLB flush and could materially change the reported context-switch and RMI numbers, but it is not evaluated. Because the paper's utility as a performance platform rests on these approximations, the authors should either validate them against real CCA hardware (when available), perform a sensitivity analysis over plausible GPC/TLB/memory-encryption costs, or explicitly re-scope the claims to functional compatibility and relative overheads within the emulated environment.
The described FVP consistency check is too thin to substantiate the claimed lift-and-shift compatibility. The text says that a "CPU-intensive workload" was benchmarked on both RK3588 and FVP using identical binaries and that results were "manually verified" to be consistent, but it does not specify the workload, the measured metric (instructions, cycles, boot time?), or any numerical results. This is at most a functional sanity check; it does not demonstrate that the OpenCCA software stack faithfully reproduces CCA semantics on the board, nor does it calibrate performance. The evaluation section should include a concrete comparison table or, at minimum, a precise description of the verification procedure and criteria.
The case-study overheads, such as the Two-GPT delegation cost of 3488 instructions (+21.7%) and 8654 cycles (+8.3%) relative to the single-GPT baseline, are presented as indicative CCA costs. However, these figures inherit the unvalidated TLB-flush and dummy-GPC approximations from Sec. 3.1, so they cannot be read as estimates of real CCA hardware overheads. If the authors intend these numbers to be used by other researchers as performance guidance, the manuscript must either provide evidence that the dominant costs in these measurements are not artifacts of the emulation strategy (e.g., by breaking down the cost components and identifying which are hardware-realistic) or add prominent caveats that the case-study overheads are only meaningful within the OpenCCA emulation environment.

minor comments (5)

The abstract uses both "Armv8.2" and "Arm v8.2" interchangeably; please standardize the notation.
The sentence "OpenCCA introduces minimal; 940 (+0.3%), ..." contains a typo: "minimal;" should be "minimal changes:" or similar.
The column headers "Sim." and "Board" are not self-explanatory; consider renaming them to "FVP Simulator" and "Physical Board" or adding a footnote that clarifies the checkmark/cross semantics.
The phrase "we use Performance Monitor Unit (PMU) with events" should be "we use the Performance Monitor Unit (PMU) with events" for grammatical correctness.
The paper repeatedly refers to an extended version [35] for implementation details; a data-availability or artifact statement in the main text (e.g., a link to the exact commit hashes of the modified source trees) would improve reproducibility for readers who do not have access to the extended version.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; OpenCCA's contributions are empirical system measurements, not derived from fitted inputs or self-citations.

full rationale

OpenCCA's central claims are that CCA-bound software can be lift-and-shifted to an RK3588 board and that the resulting cycle/instruction measurements provide a best-effort performance proxy. These claims are supported by direct construction and measurement: the paper builds TF-A/RMM/U-Boot modifications (Sec. 3-4), boots CVMs, and reports cycle/instruction counts for CVM boot, RMI/SMC round trips, and delegation (Sec. 5, Tab. 6), plus two re-implemented case studies (Sec. 6). No quantity is fitted to a subset of data and then reported as a prediction; no target result is assumed in the definition of an input; and no uniqueness theorem is imported from the authors' prior work. The TLB-flush and dummy-system-register substitutions for missing RME features are explicitly labeled approximations (Sec. 3.1) rather than claimed first-principles derivations, and citing prior prototypes [7]-[10], [12], [14] for that approximation choice does not determine the measured outcomes. Self-citations by the authors ([12], [20], [22], [27]) appear only as motivation and related-work context, not as load-bearing justification for the empirical results. The main caveat, flagged for the record, is Sec. 7's assertion that the error from missing RME features is smaller than FVP's lack of a microarchitectural model; this claim is unvalidated, and the unevaluated ASID-based alternative patchset could change TLB-flush overheads, but these are validation and representativeness limitations, not circular reasoning. Under the hard rules, this warrants a non-finding with score 0.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

No data fitting is performed. The only hand-chosen constants are firmware workarounds for missing Arm features; they do not encode the measured outcomes. The main burden is the assumption that software approximations of RME features yield representative performance and functional behavior.

free parameters (3)

GPT/GPC emulated configuration value = predefined constant, value not stated
Returned by dummy system registers instead of reading GPCCR_EL3/GPTBR_EL3 on hardware (Sec. 3.1); chosen by hand, affects emulated GPT behavior and reported boot overheads.
CNTPOFF timer offset = 0
Set to zero because RK3588 lacks Armv8.6 ECV; RMM spec requires fixed offsets, and this choice removes timer-offset effects from measurements (Sec. 3.2).
RMM TTBR1 address space size = 64 MB
Changed from the 2 MB TTST layout to 64 MB to support RK3588 lacking Armv8.4 Small Translation Tables (Sec. 3.2).

assumptions (4)

ad hoc to paper Missing RME hardware features can be emulated by software approximations without invalidating performance comparisons.
Load-bearing for the paper's purpose; Sec. 3.1 replaces GPC/TLB instructions with full TLB flush and dummy registers, and Sec. 7 argues errors are smaller than FVP's without validation.
domain assumption Functional correctness can be established by consistency with Arm FVP on benchmark workloads.
Sec. 5 benchmarks a CPU-intensive workload on both FVP and RK3588 and manually verifies consistency; this spot-checks, but does not prove correctness for all CCA-bound code.
domain assumption RK3588 is a suitable stand-in for future CCA hardware because it meets EL3 flashability and TF-A source availability.
Board selection in Sec. 3; performance results are tied to this board's microarchitecture.
domain assumption PMU counters, measured after bypassing the firmware save/restore mechanism, accurately reflect execution time across exception levels.
Sec. 5 introduces a patch set to bypass standard PMU save/restore; this could distort measurements, though it is needed to collect cross-world counters.

how reviews work

0 comments

Cite this review

Pith. "Pith review of OpenCCA: An Open Framework to Enable Arm CCA Research." pith.science (2026). https://pith.science/paper/FWCCU4OL

@misc{pith2026250605129,
  author       = {Pith},
  title        = {Pith review of: OpenCCA: An Open Framework to Enable Arm CCA Research},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FWCCU4OL}},
  note         = {Machine review of arXiv:2506.05129}
}

abstract

Confidential computing has gained traction across major architectures with Intel TDX, AMD SEV-SNP, and Arm CCA. Unlike TDX and SEV-SNP, a key challenge in researching Arm CCA is the absence of hardware support, forcing researchers to develop ad-hoc performance prototypes on non-CCA Arm boards. This approach leads to duplicated efforts, inconsistent performance comparisons, and high barriers to entry. To address this, we present OpenCCA, an open research platform that enables the execution of CCA-bound code on commodity Armv8.2 hardware. By systematically adapting the software stack -- including bootloader, firmware, hypervisor, and kernel -- OpenCCA emulates CCA operations for performance evaluation while preserving functional correctness. We demonstrate its effectiveness with typical life-cycle measurements and case-studies inspired by prior CCA-based papers on a easily available Armv8.2 Rockchip board that costs $250.

Figures

Figures reproduced from arXiv: 2506.05129 by the authors.

**Figure 1.** OpenCCA tooling. The RK3588 connects over ethernet to a flash server (Raspberry Pi). It controls a MOSFET and power circuit to flash new firmware and exposes UART access. high barrier for entry. We observe that researchers choose different Arm boards for their performance prototypes. These efforts are focused on the scope of the paper and do not lend to full-fledged prototypes that are reusable by others. Thus resea… view at source ↗

**Figure 2.** (a) Arm CCA. (b) OpenCCA implements the realm world in the normal world (EL2-EL0) and root world in EL3 (i.e., secure world). execute in one of the 4 exception levels (EL0-EL3). With CCA, only root world computation can execute in EL3. CCA enables the creation of confidential VMs (CVMs) in the realm world. To isolate mutually distrusting co-resident CVMs, CCA uses a trusted Realm Management Monitor (RMM) in realm E… view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

42 extracted references · 39 canonical work pages

[1]

Intel Trust Domain Extensions (Intel TDX),

Intel, “Intel Trust Domain Extensions (Intel TDX),” Accessed: Sep. 2, 2024

work page 2024
[2]

AMD SEV-SNP Strengthening VM Isolation with In- tegrity protection and more,

AMD, “AMD SEV-SNP Strengthening VM Isolation with In- tegrity protection and more,” Accessed: Sep. 2, 2024

work page 2024
[3]

Arm Confidential Compute Architecture (ARM-CCA),

ARM, “Arm Confidential Compute Architecture (ARM-CCA),” Accessed: Jan. 1, 2025

work page 2025
[4]

Trusted Firmware Implementation of the Realm Manage- ment Monitor (RMM), Project Page,

——, “Trusted Firmware Implementation of the Realm Manage- ment Monitor (RMM), Project Page,” Accessed: Sep. 2, 2024

work page 2024
[5]

Fast Models Fixed Virtual Platforms (FVP), Reference Guide, Version 11.21,

——, “Fast Models Fixed Virtual Platforms (FVP), Reference Guide, Version 11.21,” Accessed: Jan. 1, 2025,

work page 2025
[6]

Arm Trusted Firmware-A, Project Page,

——, “Arm Trusted Firmware-A, Project Page,” Accessed: Sep. 1, 2024,

work page 2024
[7]

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,” in USENIX Security , 2023

work page 2023
[8]

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,” in NDSS, 2024

work page 2024

Show all 42 references

[9]

The HitchHiker’s Guide to High-Assurance System Observability Protection with Efficient Permission Switches,

C. Zhang, J. Zeng, Y. Zhang, A. Ahmad, F. Zhang, H. Jin, and Z. Liang, “The HitchHiker’s Guide to High-Assurance System Observability Protection with Efficient Permission Switches,” in ACM CCS, 2024

2024
[10]

SCRUTINIZER: Towards Secure Forensics on Compromised TrustZone,

Y. Zhang, F. Zhang, X. Luo, R. Hou, X. Ding, Z. Liang, S. Yan, T. Wei, and Z. He, “SCRUTINIZER: Towards Secure Forensics on Compromised TrustZone,” in NDSS, 2025

2025
[11]

SoK: A Com- parison Study of Arm TrustZone and CCA,

H. Huang, F. Zhang, S. Yan, T. Wei, and Z. He, “SoK: A Com- parison Study of Arm TrustZone and CCA,” in 2024 International Symposium on Secure and Private Execution Environment Design (SEED), 2024

2024
[12]

Acai: Protecting Accelerator Execution with Arm Confidential Computing Architecture,

S. Sridhara, A. Bertschi, B. Schl¨ uter, M. Kuhne, A. Aliberti, and S. Shinde, “Acai: Protecting Accelerator Execution with Arm Confidential Computing Architecture,” in USENIX Security , 2024

2024
[13]

RContainer: A Secure Container Architecture through Extending ARM CCA Hardware Primitives,

Q. Zhou, W. Cao, X. Jia, P. Liu, S. Zhang, J. Chen, S. Xu, and Z. Song, “RContainer: A Secure Container Architecture through Extending ARM CCA Hardware Primitives,” in NDSS, 2025

2025
[14]

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),” in IEEE S&P , 2025

2025
[15]

Design and Verification of the Arm Confidential Compute Archi- tecture,

X. Li, X. Li, C. Dall, R. Gu, J. Nieh, Y. Sait, and G. Stockwell, “Design and Verification of the Arm Confidential Compute Archi- tecture,” in USENIX OSDI , 2022

2022
[16]

virtCCA: Virtualized Arm Con- fidential Compute Architecture with TrustZone,

X. Xu, W. Wang, Y. Wu, C. Wang, H. Zhu, H. Ma, Z. Min, Z. Pang, R. Hou, and Y. Jin, “virtCCA: Virtualized Arm Con- fidential Compute Architecture with TrustZone,” arXiv preprint arXiv:2306.11011, 2023

2023
[17]

Sharing is leaking: blocking transient- execution attacks with core-gapped confidential VMs,

C. Castes and A. Baumann, “Sharing is leaking: blocking transient- execution attacks with core-gapped confidential VMs,” in ACM ASPLOS, 2024

2024
[18]

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,” in Proceedings of the 4th Workshop on Machine Learning and Systems, 2024

2024
[19]

CPC: Flexible, secure, and efficient CVM maintenance with confidential procedure calls,

J. Chen, Z. Mi, Y. Xia, H. Guan, and H. Chen, “CPC: Flexible, secure, and efficient CVM maintenance with confidential procedure calls,” in USENIX ATC, 2024

2024
[20]

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

2024
[21]

BarriCCAde: Iso- lating Closed-Source Drivers with ARM CCA,

M. Schulze, C. Lindenmeier, and J. Rockl, “BarriCCAde: Iso- lating Closed-Source Drivers with ARM CCA,” in 2024 IEEE EuroS&PW, 2024

2024
[22]

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

2024 arXiv
[23]

FortifyPatch: Towards Tamper-Resistant Live Patching in Linux- Based Hypervisor,

Z. Ye, L. Zhou, F. Zhang, W. Jin, Z. Ning, Y. Hu, and Z. Qin, “FortifyPatch: Towards Tamper-Resistant Live Patching in Linux- Based Hypervisor,” in ISSTA, 2024

2024
[24]

CubeVisor: A Multi-realm Architecture Design for Running VM with ARM CCA,

J. Chen, Q. Zhou, X. Yan, N. Jiang, X. Jia, and W. Zhang, “CubeVisor: A Multi-realm Architecture Design for Running VM with ARM CCA,” in 2024 Annual Computer Security Applications Conference (ACSAC), 2024

2024
[25]

TwinVisor: Hardware-isolated Confidential Virtual Machines for ARM,

D. Li, Z. Mi, Y. Xia, B. Zang, H. Chen, and H. Guan, “TwinVisor: Hardware-isolated Confidential Virtual Machines for ARM,” in Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles, 2021

2021
[26]

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,” in Proceedings 2025 Network and Distributed System Security Symposium , 2025

2025
[27]

Protecting Accelerator Execution with Arm Confiden- tial Computing Architecture,

A. Bertschi, “Protecting Accelerator Execution with Arm Confiden- tial Computing Architecture,” Master’s Thesis, ETH Zurich, 2023

2023
[28]

OpenSGX: An Open Platform for SGX Research,

P. Jain, S. Desai, S. Kim, M.-W. Shih, J. Lee, C. Choi, Y. Shin, T. Kim, B. B. Kang, and D. Han, “OpenSGX: An Open Platform for SGX Research,” in NDSS, 2016

2016
[29]

Keystone: An Open Framework for Architecting Trusted Execu- tion Environments,

D. Lee, D. Kohlbrenner, S. Shinde, K. Asanovi ´c, and D. Song, “Keystone: An Open Framework for Architecting Trusted Execu- tion Environments,” in EuroSys, 2020

2020
[30]

OpenCCA: An Open Framework to Enable Arm CCA Research, Project Page,

A. Bertschi and S. Shinde, “ OpenCCA: An Open Framework to Enable Arm CCA Research, Project Page,” 2025. [Online]. Available: https://opencca.github.io

2025
[31]

Upstream support for Rockchip’s RK3588: Progress and future plans,

Collabora, “Upstream support for Rockchip’s RK3588: Progress and future plans,” Accessed: Feb. 1, 2025

2025
[32]

Feature names in A-profile architecture,

ARM, “Feature names in A-profile architecture,” Accessed Feb. 1, 2025

2025
[33]

Realm Management Monitor (RMM) Specification (1.0- REL0),

——, “Realm Management Monitor (RMM) Specification (1.0- REL0),” Accessed: Feb. 2, 2025

2025
[34]

Binman, Project Page,

U-Boot, “Binman, Project Page,” Accessed: Feb. 2, 2025

2025
[35]

OpenCCA: An Open Framework to Enable Arm CCA Research, Extended Version,

A. Bertschi and S. Shinde, “ OpenCCA: An Open Framework to Enable Arm CCA Research, Extended Version,” 2025. [Online]. Available: https://opencca.github.io/extended-version

2025
[36]

TF-A: Upstream support for Rockchip’s RK3588, Commit: 44418fce30,

Collabora, “TF-A: Upstream support for Rockchip’s RK3588, Commit: 44418fce30,” Accessed: Feb. 1, 2025

2025
[37]

CCA Host+Guest Patchset for Linux, Version: cca- full/v5+v7, Commit: fad35572db,

ARM, “CCA Host+Guest Patchset for Linux, Version: cca- full/v5+v7, Commit: fad35572db,” Accessed: Feb. 1, 2025

2025
[38]

Linux Kernel: Upstream support for Rockchip’s RK3588, Commit: f7e1ed901e7,

Collabora, “Linux Kernel: Upstream support for Rockchip’s RK3588, Commit: f7e1ed901e7,” Accessed: Feb. 1, 2025

2025
[39]

RMM, Commit: 1313d31ad9,

ARM, “RMM, Commit: 1313d31ad9,” Accessed: Feb. 1, 2025

2025
[40]

U-Boot: Upstream support for Rockchip’s RK3588, Commit: 889c316b59e2,

Collabora, “U-Boot: Upstream support for Rockchip’s RK3588, Commit: 889c316b59e2,” Accessed: Feb. 1, 2025

2025
[41]

Kvmtool for Arm CCA, Version: cca/v3, Commit: 54241e378,

ARM, “Kvmtool for Arm CCA, Version: cca/v3, Commit: 54241e378,” Accessed: Feb. 1, 2025

2025
[42]

FVP Models, Cycle Accuracy,

——, “FVP Models, Cycle Accuracy,” Accessed Feb. 1, 2025

2025

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Intel Trust Domain Extensions (Intel TDX),

Intel, “Intel Trust Domain Extensions (Intel TDX),” Accessed: Sep. 2, 2024

work page 2024

[2] [2]

AMD SEV-SNP Strengthening VM Isolation with In- tegrity protection and more,

AMD, “AMD SEV-SNP Strengthening VM Isolation with In- tegrity protection and more,” Accessed: Sep. 2, 2024

work page 2024

[3] [3]

Arm Confidential Compute Architecture (ARM-CCA),

ARM, “Arm Confidential Compute Architecture (ARM-CCA),” Accessed: Jan. 1, 2025

work page 2025

[4] [4]

Trusted Firmware Implementation of the Realm Manage- ment Monitor (RMM), Project Page,

——, “Trusted Firmware Implementation of the Realm Manage- ment Monitor (RMM), Project Page,” Accessed: Sep. 2, 2024

work page 2024

[5] [5]

Fast Models Fixed Virtual Platforms (FVP), Reference Guide, Version 11.21,

——, “Fast Models Fixed Virtual Platforms (FVP), Reference Guide, Version 11.21,” Accessed: Jan. 1, 2025,

work page 2025

[6] [6]

Arm Trusted Firmware-A, Project Page,

——, “Arm Trusted Firmware-A, Project Page,” Accessed: Sep. 1, 2024,

work page 2024

[7] [7]

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,” in USENIX Security , 2023

work page 2023

[8] [8]

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,” in NDSS, 2024

work page 2024