pith. sign in

arxiv: 2605.26018 · v1 · pith:SAG3IUD6new · submitted 2026-05-25 · 💻 cs.CR

Shielded but Lightweight: Building Practical Confidential Containers with ARM CCA

Pith reviewed 2026-06-29 21:17 UTC · model grok-4.3

classification 💻 cs.CR
keywords confidential containersARM CCAcontainer runtimehardware isolationtrusted computing basemicroVMcloud security
0
0 comments X

The pith

Fasco maps each confidential container directly to an ARM CCA realm to cut startup latency versus microVM designs.

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

The paper introduces Fasco, a confidential container runtime built on ARM Confidential Compute Architecture. It instantiates containers as independent Container Realms that receive hardware-enforced isolation for data confidentiality and integrity. A separate System Realm supplies services through exception forwarding and shared buffers, preserving isolation across realms without a heavy microVM stack. Prototype measurements on ARMv8 hardware indicate lower startup times and runtime overhead for short-lived workloads while keeping the trusted computing base small.

Core claim

Fasco shows that direct instantiation of containers as CCA Container Realms, coordinated by a System Realm via exception forwarding and shared buffers, reduces startup latency and performance overhead compared with microVM-based confidential containers while maintaining a small TCB.

What carries the argument

Container Realm instantiation under CCA hardware isolation, supported by a System Realm that uses exception forwarding and shared buffers for service delivery and inter-realm isolation.

Load-bearing premise

That CCA hardware isolation together with exception forwarding and shared buffers between Container Realms and the System Realm will preserve confidentiality and integrity without introducing new attack surfaces or high performance costs.

What would settle it

A side-channel or memory-access attack that extracts data from one Container Realm into another, or a benchmark in which Fasco startup latency equals or exceeds that of existing microVM confidential container systems.

Figures

Figures reproduced from arXiv: 2605.26018 by Bin Zhou, Fengwei Zhang, Jie Yu, Liantao Song, Yan Ding, Yiming Zhang, Yusong Tan.

Figure 1
Figure 1. Figure 1: Comparison of different container architectures [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: ARM CCA architecture control, CCA divides the physical address space into separate Phys￾ical Address Spaces (PAS): secure space, insecure space, root space, and realm space. Through hardware access control and memory en￾cryption keys for each realm space, the realm space is isolated from all software outside the realm space, including the host operating system and hypervisor. CCA introduced the RMM, a smal… view at source ↗
Figure 3
Figure 3. Figure 3: Design of Fasco Realm. This ensures that untrusted components can be used to improve performance without weakening the security guarantees of Realm-based execution. 3.2 System Realm Container Realms require system service support to operate. One straightforward approach is to have the Container Realm directly rely on the normal operating system for system calls, file access, and exception handling. However… view at source ↗
Figure 4
Figure 4. Figure 4: Container stage-2 memory isolation RMM (Realm Management Monitor) (EL2) Trusted Firmware-A / Secure Monitor (EL3) Normal World (Untrusted) Fasco Container Realm (EL0) Realm World Untrusted Host Component (Host OS / Hypervisor / KVM) System Realm (EL1) Stage-2 PT Management (3) Handling Complete System Realm Runtime Secure Signal Handling Container Code & Signal Return to System Realm Switch VBAR_EL1 Restor… view at source ↗
Figure 5
Figure 5. Figure 5: Exception forwarding and Interrupt handling [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Memory permission change of Fasco The container creation path. The creation handler initializes the metadata associated with the newly created confidential con￾tainer. It records the container’s protected memory regions, vector table locations, stack pointers, entry point, and the operating system page table base address used before entering the isolation context. Furthermore, it initializes the page table… view at source ↗
Figure 7
Figure 7. Figure 7: UnixBench Test Result Fasco again demonstrates superior performance in pipe through￾put and pipe-based context switching, with higher index scores. These metrics are essential for evaluating multitasking and inter￾process communication efficiency, areas where Fasco’s architecture appears to provide enhanced throughput. Both testing environ￾ments show similar capabilities in process creation and the execu￾t… view at source ↗
Figure 8
Figure 8. Figure 8: Micro-references performance overhead and application workloads [PITH_FULL_IMAGE:figures/full_fig_p010_8.png] view at source ↗
read the original abstract

The rapid advancement of cloud-native technologies has created an urgent need for security. Currently, confidential containers are increasingly deployed in multi-tenant environments. Existing confidential container designs mainly adopt a microVM-based architecture. Although this approach improves inter-container isolation, its complex software stack leads to high startup latency and significant resource overhead, making it unsuitable for short-lived container workloads. In this paper, we propose Fasco, a lightweight confidential container runtime based on the ARM Confidential Compute Architecture (CCA). Fasco directly instantiates each container as an independent Container Realm, leveraging CCA's hardware-enforced isolation to ensure the confidentiality and integrity of application data inside the container. In addition, Fasco introduces a dedicated System Realm to provide system services and resource management for container realms. Through exception forwarding and shared buffers, Fasco ensures isolation among different container realms. We have implemented a prototype of Fasco and evaluated its performance on ARMv8 hardware. Experimental results show that Fasco reduces the startup latency and performance overhead of existing confidential container architectures while maintaining a small TCB.

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 proposes Fasco, a lightweight confidential container runtime for ARM CCA. Each container runs as an independent Container Realm with hardware-enforced isolation; a System Realm supplies services via exception forwarding and shared buffers. The design claims to reduce startup latency and performance overhead relative to microVM-based confidential containers while preserving a small TCB. A prototype was implemented and evaluated on ARMv8 hardware.

Significance. If the security properties of the forwarding and buffer mechanisms are rigorously established and the performance claims are backed by concrete, reproducible measurements with appropriate baselines, the work would offer a practical alternative for short-lived container workloads in multi-tenant clouds, addressing a recognized limitation of existing confidential-computing runtimes.

major comments (2)
  1. [Abstract, §4] Abstract and §4 (evaluation): the central performance claim—that Fasco reduces startup latency and overhead—is stated without any quantitative results, baselines, workload descriptions, or error bars. Because the claim is entirely experimental, the absence of these data prevents evaluation of whether the result holds.
  2. [§3] §3 (architecture) and threat-model discussion: the confidentiality and integrity guarantees rest on exception forwarding and shared buffers between Container Realms and the System Realm, yet no threat model, enumeration of System Realm contents, or analysis of potential cross-realm leakage or DoS vectors is supplied. This is load-bearing for both the security and “small TCB” assertions.
minor comments (2)
  1. [§3] Notation for realm boundaries and buffer ownership is introduced without a diagram or explicit invariants, making the isolation argument harder to follow.
  2. [Abstract] The abstract states “experimental results show…” but the manuscript supplies no table or figure reference for those results.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. We address the two major comments below and will revise the manuscript to strengthen both the experimental reporting and the security analysis.

read point-by-point responses
  1. Referee: [Abstract, §4] Abstract and §4 (evaluation): the central performance claim—that Fasco reduces startup latency and overhead—is stated without any quantitative results, baselines, workload descriptions, or error bars. Because the claim is entirely experimental, the absence of these data prevents evaluation of whether the result holds.

    Authors: We agree the current manuscript states the performance claims without the supporting quantitative data, baselines, workload details, or error bars. In the revised version we will add concrete measurements (startup latency in ms, runtime overhead percentages), explicit baselines (e.g., microVM-based confidential containers), workload descriptions, and error bars from repeated runs to allow proper evaluation of the claims. revision: yes

  2. Referee: [§3] §3 (architecture) and threat-model discussion: the confidentiality and integrity guarantees rest on exception forwarding and shared buffers between Container Realms and the System Realm, yet no threat model, enumeration of System Realm contents, or analysis of potential cross-realm leakage or DoS vectors is supplied. This is load-bearing for both the security and “small TCB” assertions.

    Authors: We acknowledge that a dedicated threat-model discussion and analysis of the forwarding and buffer mechanisms are required to substantiate the security and TCB claims. We will expand §3 with a threat model that enumerates System Realm contents, examines cross-realm leakage and DoS vectors, and explains how CCA hardware isolation plus our design choices mitigate them. revision: yes

Circularity Check

0 steps flagged

No circularity: claims rest on implementation and experiments, not self-referential derivation

full rationale

The paper describes an engineering prototype (Fasco) that instantiates containers as CCA realms, adds a System Realm for services, and uses exception forwarding plus shared buffers. All load-bearing claims are supported by prototype implementation on ARMv8 hardware and measured startup/performance numbers. No equations, fitted parameters renamed as predictions, self-citation chains, uniqueness theorems, or ansatzes appear in the abstract or description. The derivation chain is therefore self-contained against external benchmarks (real hardware runs) and does not reduce to its own inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Abstract-only review supplies no explicit free parameters, axioms, or invented entities.

pith-pipeline@v0.9.1-grok · 5724 in / 902 out tokens · 24401 ms · 2026-06-29T21:17:20.044526+00:00 · methodology

discussion (0)

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

Reference graph

Works this paper leans on

20 extracted references · 3 canonical work pages

  1. [1]

    Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran, Dan O’keeffe, Mark L Stillwell, et al. 2016. {SCONE}: Secure linux containers with intel {SGX}. In 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16). 689–703

  2. [2]

    Andrew Baumann, Marcus Peinado, and Galen Hunt. 2015. Shielding applications from an untrusted cloud with haven.ACM Transactions on Computer Systems (TOCS)33, 3 (2015), 1–26

  3. [3]

    Andrin Bertschi and Shweta Shinde. 2025. OpenCCA: An Open Framework to Enable Arm CCA Research.arXiv preprint arXiv:2506.05129(2025)

  4. [4]

    Ferdinand Brasser, David Gens, Patrick Jauernig, Ahmad-Reza Sadeghi, and Emmanuel Stapf. 2019. SANCTUARY: ARMing TrustZone with User-space Enclaves.. InNDSS

  5. [5]

    Zhichao Hua, Jinyu Gu, Yubin Xia, Haibo Chen, Binyu Zang, and Haibing Guan

  6. [6]

    In26th USENIX Security Sympo- sium (USENIX Security 17)

    {vTZ}: virtualizing {ARM} {TrustZone}. In26th USENIX Security Sympo- sium (USENIX Security 17). 541–556

  7. [7]

    Zhichao Hua, Yang Yu, Jinyu Gu, Yubin Xia, Haibo Chen, and Binyu Zang. 2021. TZ-container: Protecting container from untrusted OS with ARM TrustZone. Science China Information Sciences64, 9 (2021), 192101

  8. [8]

    Mark Kuhne, Supraja Sridhara, Andrin Bertschi, Nicolas Dutly, Srdjan Capkun, and Shweta Shinde. 2024. Aster: Fixing the android tee ecosystem with arm cca. arXiv preprint arXiv:2407.16694(2024)

  9. [9]

    Dingji Li, Zeyu Mi, Yubin Xia, Binyu Zang, Haibo Chen, and Haibing Guan

  10. [10]

    In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles

    Twinvisor: Hardware-isolated confidential virtual machines for arm. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles. 638–654

  11. [11]

    Fan Sang, Jaehyuk Lee, Xiaokuan Zhang, and Taesoo Kim. 2025. 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, 4099–4116

  12. [12]

    Youren Shen, Hongliang Tian, Yu Chen, Kang Chen, Runji Wang, Yi Xu, Yubin Xia, and Shoumeng Yan. 2020. Occlum: Secure and efficient multitasking inside a single enclave of intel sgx. InProceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems. 955–970

  13. [13]

    Jiacheng Shi, Jinyu Gu, Yubin Xia, and Haibo Chen. 2025. Serverless functions made confidential and efficient with split containers. In34th USENIX Security Symposium (USENIX Security 25). 1091–1110

  14. [14]

    Confidential Containers Specification. 2024. Confidential containers without confidential hardware,. https://confidentialcontainers.org/blog/2024/12/03/ confidential-containers-without-confidential-hardware/ Conference, June 03–05, 2018, Woodstock, NY Song et al

  15. [15]

    Chia-Che Tsai, Donald E Porter, and Mona Vij. 2017. {Graphene-SGX}: A practical library {OS} for unmodified applications on {SGX}. In2017 USENIX annual technical conference (USENIX ATC 17). 645–658

  16. [16]

    Enriquillo Valdez, Salman Ahmed, Zhongshu Gu, Christophe De Dinechin, Pau- Chen Cheng, and Hani Jamjoom. 2024. Crossing Shifted Moats: Replacing Old Bridges with New Tunnels to Confidential Containers. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security. 1390–1404

  17. [17]

    Alexander Van’t Hof and Jason Nieh. 2022. {BlackBox}: a container security monitor for protecting containers on untrusted operating systems. In16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22). 683–700

  18. [18]

    Xiangyi Xu, Wenhao Wang, Yongzheng Wu, Chenyu Wang, Huifeng Zhu, Haocheng Ma, Zhennan Min, Zixuan Pang, Rui Hou, and Yier Jin. 2023. virtCCA: Virtualized Arm Confidential Compute Architecture with TrustZone.arXiv preprint arXiv:2306.11011(2023)

  19. [19]

    Yiming Zhang, Yuxin Hu, Zhenyu Ning, Fengwei Zhang, Xiapu Luo, Haoyang Huang, Shoumeng Yan, and Zhengyu He. 2023. {SHELTER}: Extending arm {CCA} with isolation in user space. In32nd USENIX Security Symposium (USENIX Security 23). 6257–6274

  20. [20]

    Qihang Zhou, Wenzhuo Cao, Xiaoqi Jia, Peng Liu, Shengzhi Zhang, Jiayun Chen, Shaowen Xu, and Zhenyu Song. 2025. RContainer: A Secure Container Architec- ture through Extending ARM CCA Hardware Primitives. InNDSS