Pith. sign in

REVIEW 3 major objections 4 minor 68 references

NanoZone: Scalable, Efficient, and Secure Memory Protection for Arm CCA

T0 review · 3 major / 4 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 NanoZone splits one process into unlimited secure zones on Arm CCA

desk verdict A genuinely novel three-tier CCA isolation design with careful evaluation, but the RNDR-trap switch path looks unauthenticated and undercuts the central switch-abuse claim. read the letter →

arxiv 2506.07034 v1 pith:QEC7JNBB submitted 2025-06-08 cs.CR

Shiqi Liu , Yongpeng Gao , Mingyang Zhang , Jie Wang This is my paper
classification cs.CR
keywords ArmCCAintra-processisolationpermissionoverlayextensionindirectiongranuleprotectiontablecode-pointerintegrityguardedcontrolstackconfidentialcomputing
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

NanoZone sets out to fix a gap in Arm's Confidential Computing Architecture: CCA isolates whole confidential VMs, but nothing inside a VM stops one buggy function from reading another's secrets. The paper's central claim is that by layering three Arm hardware permission mechanisms—user-level POE domains, kernel-level PIE domains, and GPT/GPC3 physical-address-space domains—a single process can host an effectively unlimited number of isolation domains while keeping a compromised OS from reaching them. It further claims that a user-space code-pointer integrity mechanism built on the Guarded Control Stack plus a shadow pointer region blocks the standard attack on such designs, where an in-process adversary hijacks control flow to abuse domain-switch code. If these claims hold, NanoZone would be the first CCA-based design to combine unbounded intra-process domains with protection against domain-switch abuse, at a measured cost of roughly 20% overhead and 95% retained throughput.

What carries the argument

The central object is the three-tier zone: a domain ID is the tuple ⟨PAS, PIE index, POE index⟩, mapped to memory via PTE fields and to physical pages via the GPT. The mechanism that carries scalability is the GPC3 bypass window: each core selectively disables Granule Protection Checks for a pre-defined contiguous PAS range, so many PASs can share the same process image without per-PAS page tables, while other cores still fail the check. The mechanism that carries security is the CPI design: GCS protects return addresses, and a PIM shadow region holds function-pointer backups with pointer-type IDs, enforced by a compiler pass and a binary scan that ensures only the instrumented trampoline can write POR_EL0 or issue the GCS store instruction. The root-world Monitor ties the tiers together by auditing page-table updates, intercepting interrupts, and restoring sensitive register state before the OS can observe it.

What would settle it

Run the three case studies (Nginx, Memcached, and the NVM data-structure benchmarks) on an Armv9.4+ processor with native POE, PIE, GCS, and GPC3 support and compare average domain-switch cycles and throughput against the RK3399 emulation; if native L2/L3 switch latency, TLB-flush semantics, or RNG-trap cost differ materially from the emulated 6,169/6,173 cycles, the reported ~20% overhead and 95% throughput retention would not hold. Separately, a memory-corruption exploit that overwrites a PIM-backed function pointer and still reaches a call site without being caught would refute the CPI claim.

Watch

Extended reading notes

Core claim

The paper claims that the 7-domain limit of Arm's Permission Overlay Extension (POE) can be broken without hardware changes by combining it with the Permission Indirection Extension (PIE) indexes and the Granule Protection Table (GPT) physical address spaces, forming a three-tier zone structure labelled L1 (POE), L2 (PIE), and L3 (PAS). It reports that four spare PIE encodings expand the usable POE domains from 7 to 28, and that reusing the same PIE/POE indexes across different PASs via per-core GPC3 bypass windows removes the ceiling entirely, making the number of domains effectively unlimited while each domain can still hold about 2.2 GB of memory. To prevent an intra-process adversary from reusing the domain-switch trampoline, it adds a code-pointer integrity mechanism: return addresses are protected by the hardware Guarded Control Stack, and function pointers are backed up by an LLVM-instrumented shadow region (PIM) with per-type hashes validated at call sites. The security claims are validated on Arm's official simulator, and performance is measured on a Rockchip RK3399 board that emulates POE, PIE, GPC3, and RNG-trap; the paper reports 74-cycle L1 switches, roughly 300-cycle average switches even at 224 domains, CPI overhead below 7.2% on SPEC rate benchmarks, and 15–23% throughput overhead on Nginx and Memcached while keeping about 95% of the baseline throughput.

Load-bearing premise

The load-bearing premise is that the Arm hardware extensions (RME with GPT, GPC3, PIE, POE, GCS, and RNG-trap) behave exactly as the architecture manuals specify, and that the FVP functional prototype plus the RK3399 emulation faithfully represent that behavior—since all performance numbers come from a board that emulates POE, PIE, GPC3, and RNG-trap rather than from real silicon.

Editorial extensions

If this is right

  • If NanoZone is right, CCA applications can isolate per-client secrets in their own domains without paying a kernel trap on every switch: 96.5% of switches stay at L1 (POE) even with 224 domains per core.
  • A compromised OS no longer implies compromised process memory: the root-world Monitor's dual-GPT setup and interrupt interception prevent the kernel from remapping or reading delegated pages, as demonstrated by the two privileged-attack experiments in Section 6.2.
  • Domain-switch abuse—the classic confused-deputy attack on MPK-style systems—is blocked not by whitelisting call sites but by validating the whole control-flow chain through GCS and PIM, covering both return addresses and function pointers.
  • Real server workloads keep most of their speed: Nginx throughput drops 22.67% versus native, of which only 4.40% is the added fine-grained isolation over the process-level baseline, and Memcached retains 95.85% of that baseline's throughput.
  • The design supports memory-heavy isolation domains: each L3 zone can be a contiguous region up to 64 GB, giving roughly 2.2 GB usable per domain under the bypass-window limit.

Reading between the lines

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

  • If native Armv9.4+ silicon ships with these extensions, the emulated costs are likely upper bounds: the RK3399 emulation uses svc/smc and full TLB flushes in place of the RNG-trap and tlbi paallos primitives, so real hardware may be faster, not slower.
  • The three-tier idea could generalize to other architectures that have similar nested permission layers (e.g., x86 MPK plus EPT), suggesting a general recipe: reuse index encodings across independent permission layers to lift domain-count ceilings without hardware changes.
  • The CPI scheme's type-ID hashing explicitly does not cover C++ vtable pointers or data-oriented programming; closing that gap with backup and verification for vtable and data pointers is a natural next step that the paper itself names as future work.
  • The data-centric workflow (per-request domains) may make NanoZone applicable beyond servers, such as isolating plugin or extension code in browsers, since domain creation and teardown can reuse the same GPC3 windows.
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.

Referee Report

3 major / 4 minor

Summary. NanoZone proposes a three-tier isolation model for Arm CCA: L1 (POE), L2 (PIE), and L3 (GPT/GPC3), with a claimed effectively unlimited number of intra-process domains. It augments this with a user-level CPI mechanism based on GCS and a PIM region to block domain-switch abuse, and a root-world Monitor to defend against a compromised OS. The paper presents a functional prototype on Arm FVP, a performance prototype on RK3399 with emulated hardware extensions, and evaluation on SPEC, Nginx, Memcached, and NVM data structures, reporting roughly 20% overhead and 95% throughput versus a no-isolation baseline.

Significance. If correct, NanoZone would be the first CCA-based design to combine scalable intra-process isolation with a defense against domain-switch abuse, and it creatively combines POE, PIE, and GPC3 while keeping the TCB in the root world. The FVP functional validation and the explicit disclosure that all performance measurements come from emulated extensions are strengths. However, the security claim depends on the RNDR-trap switch path being properly authenticated, which the paper does not establish, and the performance claims rest on an emulation platform without shipped artifacts.

major comments (3)
  1. [§4.3, §6.1] The claim that CPI blocks domain-switch abuse does not cover the RNDR-trap switch path. The paper states that 'the Monitor validates each request by checking the current GPT base,' but the GPT base is the same for every domain of a protected process, so this check authenticates only that execution is under the proc GPT, not which domain is requesting. An untrusted L1 domain can set the target zone identifier and execute a user-space RNDR read to request a privileged L2/L3 switch; the GCS/CPI machinery is not in this path. The paper also does not explain how legitimate RNG consumers of RNDR/RNDRRS are distinguished from switch requests, since the trap is triggered by any user-space read. This gap undermines the mutual-isolation and switch-abuse-resistance claims.
  2. [§5, §7.2] The headline performance figures are measured on a platform that emulates the required features: L1 switches via TPIDR_EL0, L2 via AFSR0_EL1, L3 via ACTLR_EL3 plus svc/smc, and gcsstr via a normal store. The claimed overheads in Tables 3–5 and Figures 12–14 therefore reflect emulation costs rather than real POE/PIE/GPC3/GCS behavior. The paper acknowledges this for L2/L3 but still presents absolute overheads (e.g., 'roughly 20%' in the abstract). Without artifacts or a calibration study, the efficiency claim cannot be independently evaluated; the claims should be softened or supported by reproducible measurements.
  3. [§4.2] The security argument assumes that a post-compilation binary scan removes every pre-inlined gcsstr and POR_EL0-write instruction while preserving instrumentation and the trampoline. The paper gives no algorithm, no completeness argument, and no evaluation of the scanner's coverage on the evaluated programs. Because the CPI mechanism is the stated defense against domain-switch abuse, an undetected pre-inlined instruction would let an attacker bypass the trampoline; this needs to be addressed.
minor comments (4)
  1. [§7.2, Table 4] The text says that 'expanding to 28 domains' yields an L1 hit rate of 98.21%, but Table 4 reports 98.21% for 14 domains and 97.32% for 28 domains; the narrative and table should be reconciled.
  2. [§5] The statement that 'actual hardware overhead will therefore be lower than our emulation' is asserted only for L2/L3 transitions; for the emulated L1 path and gcsstr replacement, the direction of any hardware/emulation difference is not justified and should be discussed more carefully.
  3. [§7.3] The comparisons against lwC are labeled as simulated ('Hook+lwC (simulated)') in Figures 12 and 13; the text should state explicitly that the lwC numbers are estimates from prior work and are not measured on the test platform, since the claimed 20.07% throughput advantage over lwC depends on that estimate.
  4. [General] No code or data artifacts are provided, so the FVP security evaluation and the RK3399 performance measurements cannot be reproduced; at minimum, a detailed artifact appendix or a public release would strengthen the paper.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: NanoZone's claims are empirical measurements and hardware-feature compositions, not derivations from fitted inputs or self-citations.

full rationale

NanoZone is a systems paper whose central claims are empirical measurements and architectural compositions of Arm hardware primitives, so there is no derivation chain that reduces to its own inputs. The claimed scalability (28 POE/PIE domains per L3-Zone, effectively unlimited via GPT PASs) is a construction: 7 usable POE indexes times 4 unused PIE indexes, with each GPC3 bypass window isolating a separate PAS. The claimed defense against domain-switch abuse rests on GCS-protected return addresses plus an LLVM pass that backs up function pointers in a PIM region, with binary scanning to strip pre-inlined switching and gcsstr instructions; this is an implementation mechanism, not a result defined in terms of itself. The performance figures (74-cycle L1 switches, 6,169-cycle L2/L3 switches, Nginx 22.67%, Memcached 15.10%, CPI 7.13% on SPEC rate2017) are PMU measurements and workload traces, not outputs of a model fitted to the same data; the L1/L2/L3 hit rates (96.72%, 2.73%, 0.55%) are measured, and the ~300-cycle average cost is an accounting identity over those measurements. No load-bearing step is justified by a self-citation: the design cites Arm architecture references and external prior systems (Shelter, CAGE, lwC), and no confirmed author-overlap citation carries the argument. No uniqueness theorem is imported from the authors' own prior work. Two caveats are non-circular but worth weighing elsewhere: (1) the abstract's '20% overhead / 95% throughput' is not directly reconciled with the measured Nginx (22.67%) and Memcached (15.10%) overheads, an internal-consistency issue; (2) Section 4.3 states that the RNG-trap Monitor 'validates each request by checking the current GPT base, blocking domain-switching abuse,' but the described check authenticates the GPT in use rather than the requesting domain, and every domain of a protected process executes under the same proc GPT; that is a security-correctness gap to evaluate, not a circular reduction, because the claim does not follow from the check by definition.

Assumptions & free parameters 0 free parameters · 5 assumptions · 2 invented entities

Free parameters are not applicable in the usual fitting sense. The paper adds two architectural entities: the PIM region (a protected memory region for pointer backups) and the co-opted RNDR-trap path. The axioms are hardware-spec assumptions and two toolchain- and binary-scan completeness assumptions. These are the load-bearing premises: if any of them fail on real Arm silicon or in a full compiler toolchain, the security and performance claims could break.

assumptions (5)
  • domain assumption Arm hardware implements RME/GPT, GPC3, PIE, POE, GCS, and RNDR-trap exactly as documented, including TLB behavior and trap costs.
    The entire design relies on these extensions; the paper states (Section 5) that no commercial hardware yet supports them, so functional behavior is tested on FVP and performance on an emulated RK3399 prototype.
  • domain assumption The FVP functional prototype and the RK3399 emulation faithfully represent the performance and security semantics of the real hardware features.
    Section 5 maps POE to TPIDR_EL0, PIE to AFSR0_EL1, GPC3 to ACTLR_EL3, and RNG-trap to svc/smc. The 74-cycle and 6,100-cycle switch costs are measured on this emulation and may differ on real silicon.
  • ad hoc to paper The binary scan can reliably remove all pre-inlined gcsstr and POR_EL0-write instructions, leaving only the instrumentation and the trampoline able to modify them.
    Section 4.2 states that a binary scan replaces any other occurrence of the dedicated instruction with a standard store. The paper does not provide a proof that the scan is complete against all compiler and inline-assembly patterns.
  • domain assumption The Monitor in the root world correctly intercepts all user-to-kernel transitions and all RNDR/RNDRRS reads, and cannot be bypassed by the OS or by user code.
    Section 4.3 relies on interrupt interception and RNG-trap co-option. The paper argues the Monitor is at EL3 and flushes TLB on transitions, but the proof of completeness is informal.
  • ad hoc to paper LLVM IR strong typing and the type-hash scheme preserve type identity for all function pointers, including void* casts and global pointers.
    Section 4.2 handles bitcast and global pointers with extra checks, but the completeness of the type-ID propagation is asserted, not formally verified. C++ vtables are explicitly out of scope.
invented entities (2)
  • PIM (Pointer-Integrity Memory) region
    purpose: Shadow storage for function-pointer backups, writable only through a dedicated unprivileged instruction (gcsstr) and readable by user code for CPI checks.
    The paper introduces PIM as a new memory region managed by the Monitor. It is a design entity, not a new physical object. Its security depends on the binary scan and GCS attributes. There is no falsifiable handle outside the paper beyond the claimed CPI resistance.
  • L2-Zone and L3-Zone switching via RNDR-trap co-option
    purpose: Firmware-level trigger for PIE and GPC3 register updates without passing through the kernel.
    This is a novel use of an existing architectural behavior (user-space RNDR reads trap to EL3). The entity is the co-opted trap path, not a new physical feature. Its correctness depends on Arm's RNG-trap semantics.

how reviews work

0 comments
Cite this review

Pith. "Pith review of NanoZone: Scalable, Efficient, and Secure Memory Protection for Arm CCA." pith.science (2026). https://pith.science/paper/QEC7JNBB

@misc{pith2026250607034,
  author       = {Pith},
  title        = {Pith review of: NanoZone: Scalable, Efficient, and Secure Memory Protection for Arm CCA},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QEC7JNBB}},
  note         = {Machine review of arXiv:2506.07034}
}
read the original abstract

Arm Confidential Computing Architecture (CCA) currently isolates at the granularity of an entire Confidential Virtual Machine (CVM), leaving intra-VM bugs such as Heartbleed unmitigated. The state-of-the-art narrows this to the process level, yet still cannot stop attacks that pivot within the same process, and prior intra-enclave schemes are either too slow or incompatible with CVM-style isolation. We extend CCA with a three-tier zone model that spawns an unlimited number of lightweight isolation domains inside a single process, while shielding them from kernel-space adversaries. To block domain-switch abuse, we also add a fast user-level Code-Pointer Integrity (CPI) mechanism. We developed two prototypes: a functional version on Arm's official simulator to validate resistance against intra-process and kernel-space adversaries, and a performance variant on Arm development boards evaluated for session-key isolation within server applications, in-memory key-value protection, and non-volatile-memory data isolation. NanoZone incurs roughly a 20% performance overhead while retaining 95% throughput compared to the system without fine-grained isolation.

Figures

Figures reproduced from arXiv: 2506.07034 by the authors.

Figure 1
Figure 1. Comparison between NANOZONE and other CCA-based TEEs. for core functions like scheduling and memory management. These kernels often include many unnecessary components, such as legacy or device-specific drivers, which expand the Trusted Computing Base (TCB) without benefiting the workload. With recent Linux releases exceeding 40M lines of code (LoCs), the risk of privilege-escalation bugs [5], [6], [7] rises sharply… view at source ↗
Figure 2
Figure 2. Domain-switching scenarios for 1,000 Memcached requests in [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Combination of permission indirection and overlay. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (10 more)
Figure 4
Figure 4. Figure 4: The architecture of CCA and its PAS access permissions. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: The architecture of NANOZONE. highest privilege. Therefore, NANOZONE offloads essential security operations (e.g., configuring PIE and POE indexes) to the root world, rather than relying on the untrusted OS. System Architecture. The architecture of NANOZONE is illustra…
Figure 6
Figure 6. Figure 6: Structure of the domain extension: (a) shows the extension via [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Intra-process permission switching in the N [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 10
Figure 10. Figure 10: A dual-GPT design blocking OS access to secure memory. [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 9
Figure 9. Figure 9: Instrumentation code for pointer backup and call verification. [PITH_FULL_IMAGE:figures/full_fig_p008_9.png]
Figure 11
Figure 11. Figure 11: Performance overhead on the SPEC CPU2017 C benchmarks. [PITH_FULL_IMAGE:figures/full_fig_p011_11.png]
Figure 12
Figure 12. Figure 12: Comparison of Throughput Overhead on Nginx. [PITH_FULL_IMAGE:figures/full_fig_p012_12.png]
Figure 13
Figure 13. Figure 13: Comparison of Throughput Overhead on Memcached. [PITH_FULL_IMAGE:figures/full_fig_p012_13.png]
Figure 14
Figure 14. Figure 14: Data-structure benchmarks: (a) linked list (20 KB per domain); (b) B+ tree (5 MB per domain); (c) hash table (20 KB per domain). [PITH_FULL_IMAGE:figures/full_fig_p013_14.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

68 extracted references · 65 canonical work pages

  1. [1]

    Amd secure encrypted virtualization (SEV),

    AMD, “Amd secure encrypted virtualization (SEV),” 2023, https: //www.amd.com/en/developer/sev.html

    work page 2023

  2. [2]

    Intel trust domain extensions (intel TDX),

    Intel, “Intel trust domain extensions (intel TDX),” 2023, https://ww w.intel.com/content/www/us/en/developer/articles/technical/intel-tru st-domain-extensions.html

    work page 2023

  3. [3]

    Confidential compute architecture,

    Arm, “Confidential compute architecture,” 2023, https://www.arm.co m/architecture/security-features/arm-confidential-compute-architect ure

    work page 2023

  4. [4]

    Trustzone: Integrated hardware and software security,

    T. Alves, “Trustzone: Integrated hardware and software security,” Information Quarterly, vol. 3, pp. 18–24, 2004

    work page 2004

  5. [5]

    Retspill: Igniting user-controlled data to burn away linux kernel protections,

    K. Zeng, Z. Lin, K. Lu, X. Xing, R. Wang, A. Doup ´e, Y . Shoshi- taishvili, and T. Bao, “Retspill: Igniting user-controlled data to burn away linux kernel protections,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security , 2023, pp. 3093–3107

    work page 2023

  6. [6]

    ret2dir: Rethinking kernel isolation,

    V . P. Kemerlis, M. Polychronakis, and A. D. Keromytis, “ret2dir: Rethinking kernel isolation,” in 23rd USENIX Security Symposium (USENIX Security 14) , 2014, pp. 957–972

    work page 2014

  7. [7]

    Dirtycred: Escalating privilege in linux kernel,

    Z. Lin, Y . Wu, and X. Xing, “Dirtycred: Escalating privilege in linux kernel,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security , 2022, pp. 1963–1976

    work page 2022

  8. [8]

    The matter of heartbleed,

    Z. Durumeric, F. Li, J. Kasten, J. Amann, J. Beekman, M. Payer, N. Weaver, D. Adrian, V . Paxson, M. Bailey et al. , “The matter of heartbleed,” in Proceedings of the 2014 conference on internet measurement conference, 2014, pp. 475–488

    work page 2014

Show all 68 references
  1. [9]

    Gramine-tdx: A lightweight os kernel for confidential vms,

    D. Kuvaiskii, D. Stavrakakis, K. Qin, C. Xing, P. Bhatotia, and M. Vij, “Gramine-tdx: A lightweight os kernel for confidential vms,” in Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security , 2024, pp. 4598–4612

    2024

  2. [10]

    Rcontainer: A secure container architecture through ex- tending 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 ex- tending arm cca hardware primitives,” in NDSS, 2025

    2025

  3. [11]

    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 32nd USENIX Security Symposium (USENIX Security’23) , 2023

    2023

  4. [12]

    Intel® software guard extensions (intel® SGX),

    Intel, “Intel® software guard extensions (intel® SGX),” 2023, https: //www.intel.com/content/www/us/en/architecture-and-technology/so ftware-guard-extensions.html

    2023

  5. [13]

    Nested enclave: Supporting fine-grained hierarchical isolation with sgx,

    J. Park, N. Kang, T. Kim, Y . Kwon, and J. Huh, “Nested enclave: Supporting fine-grained hierarchical isolation with sgx,” in 2020 ACM/IEEE 47th Annual International Symposium on Computer Ar- chitecture (ISCA). IEEE, 2020, pp. 776–789

    2020

  6. [14]

    A {Hardware- Software} co-design for efficient {Intra-Enclave} isolation,

    J. Gu, B. Zhu, M. Li, W. Li, Y . Xia, and H. Chen, “A {Hardware- Software} co-design for efficient {Intra-Enclave} isolation,” in 31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 3129– 3145

    2022

  7. [15]

    Intel® 64 and ia-32 architectures software developer manuals,

    Intel, “Intel® 64 and ia-32 architectures software developer manuals,” 2024, https://www.intel.com/content/www/us/en/developer/articles/t echnical/intel-sdm.html

    2024

  8. [16]

    The road to trust: Building enclaves within confidential vms,

    W. Wang, L. Song, B. Mei, S. Liu, S. Zhao, S. Yan, X. Wang, D. Meng, and R. Hou, “The road to trust: Building enclaves within confidential vms,” in NDSS, 2025

    2025

  9. [17]

    Shreds: Fine- grained execution units with private memory,

    Y . Chen, S. Reymondjohnson, Z. Sun, and L. Lu, “Shreds: Fine- grained execution units with private memory,” in 2016 IEEE Sympo- sium on Security and Privacy (SP) . IEEE, 2016, pp. 56–71

    2016

  10. [18]

    Armlock: Hardware-based fault isolation for arm,

    Y . Zhou, X. Wang, Y . Chen, and Z. Wang, “Armlock: Hardware-based fault isolation for arm,” in Proceedings of the 2014 ACM SIGSAC conference on computer and communications security, 2014, pp. 558– 569

    2014

  11. [19]

    Permission indirection and permission overlay extensions,

    Arm, “Permission indirection and permission overlay extensions,” 2024, https://developer.arm.com/documentation/102376/0200/Pe rmission-indirection-and-permission-overlay-extensions

    2024

  12. [20]

    Learn the architecture - realm management extension,

    ——, “Learn the architecture - realm management extension,” 2023, https://developer.arm.com/documentation/den0126/latest

    2023

  13. [21]

    Granule protection check bypass window register (el3),

    ——, “Granule protection check bypass window register (el3),” 2024, https://developer.arm.com/documentation/ddi0601/2024-12/AArch6 4-Registers/GPCBW-EL3--Granule-Protection-Check-Bypass-Win dow-Register--EL3-

    2024

  14. [22]

    Arm® architecture reference manual for a-profile architec- ture,

    ——, “Arm® architecture reference manual for a-profile architec- ture,” 2024, https://developer.arm.com/documentation/ddi0487/latest/

    2024

  15. [23]

    The geometry of innocent flesh on the bone: Return- into-libc without function calls (on the x86),

    H. Shacham, “The geometry of innocent flesh on the bone: Return- into-libc without function calls (on the x86),” in Proceedings of the 14th ACM conference on Computer and communications security , 2007, pp. 552–561

    2007

  16. [24]

    Intel control-flow enforcement technology,

    Intel, “Intel control-flow enforcement technology,” 2023, https://ww w.intel.com/content/www/us/en/content-details/785687/complex-sha dow-stack-updates-intel-control-flow-enforcement-technology.html

    2023

  17. [25]

    {Light-Weight} contexts: An {OS} abstraction for safety and performance,

    J. Litton, A. Vahldiek-Oberwagner, E. Elnikety, D. Garg, B. Bhat- tacharjee, and P. Druschel, “ {Light-Weight} contexts: An {OS} abstraction for safety and performance,” in 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16) , 2016, pp. 49–64

    2016

  18. [26]

    You shall not (by) pass! practical, secure, and fast pku-based sandboxing,

    A. V oulimeneas, J. Vinck, R. Mechelinck, and S. V olckaert, “You shall not (by) pass! practical, secure, and fast pku-based sandboxing,” in Proceedings of the Seventeenth European Conference on Computer Systems, 2022, pp. 266–282

    2022

  19. [27]

    Donky: Domain keys–efficient {In- Process} isolation for {RISC-V} and x86,

    D. Schrammel, S. Weiser, S. Steinegger, M. Schwarzl, M. Schwarz, S. Mangard, and D. Gruss, “Donky: Domain keys–efficient {In- Process} isolation for {RISC-V} and x86,” in 29th USENIX Security Symposium (USENIX Security 20) , 2020, pp. 1677–1694

    2020

  20. [28]

    libmpk: Software abstraction for intel memory protection keys (intel MPK),

    S. Park, S. Lee, W. Xu, H. Moon, and T. Kim, “libmpk: Software abstraction for intel memory protection keys (intel MPK),” in 2019 USENIX Annual Technical Conference (USENIX ATC 19) , 2019, pp. 241–254

    2019

  21. [29]

    {EPK}: Scalable and efficient memory protection keys,

    J. Gu, H. Li, W. Li, Y . Xia, and H. Chen, “ {EPK}: Scalable and efficient memory protection keys,” in 2022 USENIX Annual Technical Conference (USENIX ATC 22) , 2022, pp. 609–624

    2022

  22. [30]

    Lightzone: Lightweight hardware-assisted in-process isolation for arm64,

    Z. Yuan, S. Hong, R. Guo, R. Chang, M. Gao, W. Shen, and Y . Zhou, “Lightzone: Lightweight hardware-assisted in-process isolation for arm64,” in Proceedings of the 25th International Middleware Con- ference, 2024, pp. 467–480

    2024

  23. [31]

    Iago attacks: Why the system call api is a bad untrusted rpc interface,

    S. Checkoway and H. Shacham, “Iago attacks: Why the system call api is a bad untrusted rpc interface,” ACM SIGARCH Computer Architecture News, vol. 41, no. 1, pp. 253–264, 2013

    2013

  24. [32]

    Jump-oriented programming: a new class of code-reuse attack,

    T. Bletsch, X. Jiang, V . W. Freeh, and Z. Liang, “Jump-oriented programming: a new class of code-reuse attack,” inProceedings of the 6th ACM symposium on information, computer and communications security, 2011, pp. 30–40

    2011

  25. [33]

    An Off-Chip attack on hardware enclaves via the memory bus,

    D. Lee, D. Jung, I. T. Fang, C.-C. Tsai, and R. A. Popa, “An Off-Chip attack on hardware enclaves via the memory bus,” in 29th USENIX Security Symposium (USENIX Security 20) , 2020

    2020

  26. [34]

    Cold boot attacks are still hot: Security analysis of memory scramblers in modern processors,

    S. F. Yitbarek, M. T. Aga, R. Das, and T. Austin, “Cold boot attacks are still hot: Security analysis of memory scramblers in modern processors,” in 2017 IEEE International Symposium on High Performance Computer Architecture (HPCA). IEEE, 2017, pp. 313– 324

    2017

  27. [35]

    Flipping bits in memory without accessing them: An experimental study of dram disturbance errors,

    Y . Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, and O. Mutlu, “Flipping bits in memory without accessing them: An experimental study of dram disturbance errors,” ACM SIGARCH Computer Architecture News, vol. 42, no. 3, pp. 361–372, 2014

    2014

  28. [36]

    Meltdown,

    M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, S. Mangard, P. Kocher, D. Genkin, Y . Yarom, and M. Hamburg, “Meltdown,”arXiv preprint arXiv:1801.01207, 2018

    2018 arXiv

  29. [37]

    Spectre attacks: Ex- ploiting speculative execution,

    P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Ham- burg, M. Lipp, S. Mangard, T. Prescher et al., “Spectre attacks: Ex- ploiting speculative execution,” Communications of the ACM, vol. 63, no. 7, pp. 93–101, 2020

    2020

  30. [38]

    Counterfeit object-oriented programming: On the difficulty of preventing code reuse attacks in c++ applications,

    F. Schuster, T. Tendyck, C. Liebchen, L. Davi, A.-R. Sadeghi, and T. Holz, “Counterfeit object-oriented programming: On the difficulty of preventing code reuse attacks in c++ applications,” in 2015 IEEE Symposium on Security and Privacy . IEEE, 2015, pp. 745–762

    2015

  31. [39]

    Data-oriented programming: On the expressiveness of non-control data attacks,

    H. Hu, S. Shinde, S. Adrian, Z. L. Chua, P. Saxena, and Z. Liang, “Data-oriented programming: On the expressiveness of non-control data attacks,” in 2016 IEEE Symposium on Security and Privacy (SP). IEEE, 2016, pp. 969–986

    2016

  32. [40]

    Thwarting memory disclosure with efficient hypervisor-enforced intra-domain isolation,

    Y . Liu, T. Zhou, K. Chen, H. Chen, and Y . Xia, “Thwarting memory disclosure with efficient hypervisor-enforced intra-domain isolation,” in Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security , 2015, pp. 1607–1619

    2015

  33. [41]

    Capacity: Cryptographically-enforced in-process capabilities for modern arm architectures,

    K. Dinh Duy, K. Cho, T. Noh, and H. Lee, “Capacity: Cryptographically-enforced in-process capabilities for modern arm architectures,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security , 2023, pp. 874–888

    2023

  34. [42]

    Sok: Soft- ware compartmentalization,

    H. Lefeuvre, N. Dautenhahn, D. Chisnall, and P. Olivier, “Sok: Soft- ware compartmentalization,” in 2025 IEEE Symposium on Security and Privacy (SP) . IEEE Computer Society, 2024, pp. 75–75

    2025

  35. [43]

    Arm® cortex®-x925 core technical reference manual,

    Arm, “Arm® cortex®-x925 core technical reference manual,” 2024, https://developer.arm.com/documentation/102807/latest/

    2024

  36. [44]

    Fixed virtual platforms,

    ——, “Fixed virtual platforms,” 2023, https://developer.arm.com/do wnloads/-/arm-ecosystem-models

    2023

  37. [45]

    Patchwork - the linux kernel archives,

    linux foundation, “Patchwork - the linux kernel archives,” 2024, https: //patchwork.kernel.org/

    2024

  38. [46]

    Rock 4b, an upgraded rock 4a sbc with wifi5 & bt5 and poe support,

    radxa, “Rock 4b, an upgraded rock 4a sbc with wifi5 & bt5 and poe support,” 2024, https://radxa.com/products/rock4/4b/

    2024

  39. [47]

    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 Proceedings of the 31st Annual Network and Distributed System Security Symposium, 2024

    2024

  40. [48]

    Spec cpu® 2017 benchmark,

    S. P. E. Corporation, “Spec cpu® 2017 benchmark,” 2025, https: //www.spec.org/cpu2017/

    2017

  41. [49]

    Lmbench - tools for performance analysis,

    L. McV oy and C. Staelin, “Lmbench - tools for performance analysis,” 2025, https://lmbench.sourceforge.net/

    2025

  42. [50]

    ERIM: Secure, efficient in-process isolation with protection keys (MPK),

    A. Vahldiek-Oberwagner, E. Elnikety, N. O. Duarte, M. Samm- ler, P. Druschel, and D. Garg, “ERIM: Secure, efficient in-process isolation with protection keys (MPK),” in 28th USENIX Security Symposium (USENIX Security 19) , 2019, pp. 1221–1238

    2019

  43. [51]

    nginx is an http and reverse proxy server, a mail proxy server, and a generic tcp/udp proxy server

    I. Sysoev, “nginx is an http and reverse proxy server, a mail proxy server, and a generic tcp/udp proxy server.” 2024, https://nginx.org

    2024

  44. [52]

    Openssl library,

    O. Foundation, “Openssl library,” 2024, https://www.openssl.org/

    2024

  45. [53]

    ab is a tool for benchmarking your apache hypertext transfer protocol (http) server

    A. S. Foundation, “ab is a tool for benchmarking your apache hypertext transfer protocol (http) server.” 2024, https://httpd.apac he.org/docs/current/programs/ab.html

    2024

  46. [54]

    memcached - a distributed memory object caching system,

    A. V orobey, B. Fitzpatrick, and A. D. Kasindorf, “memcached - a distributed memory object caching system,” 2024, https://memcache d.org/

    2024

  47. [55]

    A tool for measuring memcached server performance,

    twitter, “A tool for measuring memcached server performance,” 2024, https://github.com/twitter-archive/twemperf/

    2024

  48. [56]

    Merr: Improving security of persistent memory objects via efficient memory exposure reduction and randomization,

    Y . Xu, Y . Solihin, and X. Shen, “Merr: Improving security of persistent memory objects via efficient memory exposure reduction and randomization,” in Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Sys...

    2020

  49. [57]

    Hardware-based domain virtu- alization for intra-process isolation of persistent memory objects,

    Y . Xu, C. Ye, Y . Solihin, and X. Shen, “Hardware-based domain virtu- alization for intra-process isolation of persistent memory objects,” in 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2020, pp. 680–692

    2020

  50. [58]

    Pkru-safe: Automatically locking down the heap between safe and unsafe languages,

    P. Kirth, M. Dickerson, S. Crane, P. Larsen, A. Dabrowski, D. Gens, Y . Na, S. V olckaert, and M. Franz, “Pkru-safe: Automatically locking down the heap between safe and unsafe languages,” in Proceedings of the Seventeenth European Conference on Computer Systems, 2022, pp. 132–148

    2022

  51. [59]

    Put your memory in order: Efficient domain- based memory isolation for wasm applications,

    H. Lei, Z. Zhang, S. Zhang, P. Jiang, Z. Zhong, N. He, D. Li, Y . Guo, and X. Chen, “Put your memory in order: Efficient domain- based memory isolation for wasm applications,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, 2023, pp. 904–918

    2023

  52. [60]

    Flexos: Towards flexible os isolation,

    H. Lefeuvre, V .-A. B ˘adoiu, A. Jung, S. L. Teodorescu, S. Rauch, F. Huici, C. Raiciu, and P. Olivier, “Flexos: Towards flexible os isolation,” in Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, 20...

    2022

  53. [61]

    Moat: towards safe bpf kernel extension,

    H. Lu, S. Wang, Y . Wu, W. He, and F. Zhang, “Moat: towards safe bpf kernel extension,” in 33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 1153–1170

    2024

  54. [62]

    Fast core scheduling with userspace process abstraction,

    J. Lin, Y . Chen, S. Gao, and Y . Lu, “Fast core scheduling with userspace process abstraction,” in Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles , 2024, pp. 280– 295

    2024

  55. [63]

    Beyond the edges of kernel control-flow hijacking protection with hek-cfi,

    L. Maar, P. Nasahl, and S. Mangard, “Beyond the edges of kernel control-flow hijacking protection with hek-cfi,” in Proceedings of the 19th ACM Asia Conference on Computer and Communications Security, 2024, pp. 1214–1230

    2024

  56. [64]

    {PAC} it up: Towards pointer integrity using {ARM} pointer authentication,

    H. Liljestrand, T. Nyman, K. Wang, C. C. Perez, J.-E. Ekberg, and N. Asokan, “ {PAC} it up: Towards pointer integrity using {ARM} pointer authentication,” in 28th USENIX Security Symposium (USENIX Security 19) , 2019, pp. 177–194

    2019

  57. [65]

    Tightly seal your sensitive pointers with {PACTight},

    M. Ismail, A. Quach, C. Jelesnianski, Y . Jang, and C. Min, “Tightly seal your sensitive pointers with {PACTight},” in 31st USENIX Security Symposium (USENIX Security 22) , 2022, pp. 3717–3734

    2022

  58. [66]

    Panic: Pan-assisted intra-process memory isolation on ARM,

    J. Xu, M. Xie, C. Wu, Y . Zhang, Q. Li, X. Huang, Y . Lai, Y . Kang, W. Wang, Q. Wei et al. , “Panic: Pan-assisted intra-process memory isolation on ARM,” in Proceedings of the 2023 ACM SIGSAC Confer- ence on Computer and Communications Security, 2023, pp. 919–933

    2023

  59. [67]

    Interstellar: Fully par- titioned and efficient security monitoring hardware near a processor core for protecting systems against attacks on privileged software,

    Y . Song, B. Woo, Y . Han, and B. B. Kang, “Interstellar: Fully par- titioned and efficient security monitoring hardware near a processor core for protecting systems against attacks on privileged software,” in Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Co...

    2024

  60. [68]

    Veil: A protected services framework for confidential virtual machines,

    A. Ahmad, B. Ou, C. Liu, X. Zhang, and P. Fonseca, “Veil: A protected services framework for confidential virtual machines,” in Proceedings of the 28th ACM International Conference on Architec- tural Support for Programming Languages and Operating Systems, Volume 4, 2023, pp. 378–393

    2023

Pith tools

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