{"id":"da30bfeb-762c-4699-9f7a-bdcc17464d7c","arxiv_id":"2506.07034","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"NanoZone combines Arm's POE, PIE, and GPC3 features to build a three-tier isolation hierarchy that supports an effectively unlimited number of intra-process domains inside a CVM-style environment.","lead":"NanoZone adds fine-grained, in-process memory isolation domains on top of Arm's Confidential Computing Architecture, plus a user-level code-pointer integrity mechanism to stop domain-switch abuse. It is a systems-security design that claims roughly 20% overhead while keeping 95% of native throughput on server workloads.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"RNDR-trap switch requests appear unauthenticated: any domain under proc GPT can request an L2/L3 switch, so CPI may not block domain-switch abuse.","rationale":"The reader's weakest assumption is the emulation gap and reliance on unimplemented hardware. That is a valid concern about performance representativeness, but it does not target the security claim as sharply as the RNDR switch-authentication gap. The paper's central contribution is blocking domain-switch abuse; if the only validation of an RNDR-triggered L2/L3 switch is the GPT base, then any domain inside the protected process can ask the Monitor to open any L3 zone without corrupting a single code pointer or return address. This makes the security claim internally under-specified rather than merely unvalidated on real silicon. The concrete test is feasible on the existing FVP prototype and would settle whether the described design actually enforces mutual isolation. I am not alleging misconduct; the paper is honest about its limitations, but this particular omission is not listed among them and is central to the claimed security property. The verdict should therefore be UNVERDICTED until the switch-request authentication protocol is specified and tested, rather than CONDITIONAL on hardware validation alone.","tokens_in":25128,"tokens_out":22228,"duration_ms":246160,"concrete_test":"Obtain the FVP prototype from the authors (no artifact URL is given) and inspect the EL3 RNDR-trap handler. Then from domain A, which has no legitimate access to L3-Zone B, execute the trampoline's RNDR-trigger sequence with B encoded as the target zone; if the Monitor programs GPCBW_EL3 to L3-Zone B and returns to EL0, isolation is broken. Also run a genuine RNDR read inside an OpenSSL handshake and check whether it is misinterpreted as a switch request.","verdict_should_be":"UNVERDICTED","load_bearing_attack":"Section 4.3 uses the Armv8.5 RNG TRAP feature as the trigger for L2/L3 switches: 'any user-space read of RNDR or RNDRRS traps directly to the Monitor.' The only validation described is 'checking the current GPT base'. That check cannot authenticate the requesting domain: every domain of a protected process runs under the same proc GPT, so an untrusted L1 domain can set a target zone identifier using whatever register convention the trampoline uses and execute an RNDR read to request a privileged switch to any L3 zone. The CPI/GCS machinery is not in this path, so the central claim that CPI blocks domain-switch abuse does not cover this vector. The paper also never explains how ordinary RNG consumers (OpenSSL, kernel arch_get_random) are distinguished from switch requests. If all RNDR reads are treated as switches, protected applications lose hardware randomness; if some are treated as RNG reads, an attacker can use the same convention to trigger switches. This is an internal design gap: the described GPT-base check is necessary but not sufficient for mutual isolation between domains.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":25323,"tokens_out":10363,"duration_ms":117349,"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":[{"comment":"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.","section":"§4.3, §6.1"},{"comment":"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.","section":"§5, §7.2"},{"comment":"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.","section":"§4.2"}],"minor_comments":[{"comment":"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.","section":"§7.2, Table 4"},{"comment":"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.","section":"§5"},{"comment":"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.","section":"§7.3"},{"comment":"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.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The RNDR-trap authentication gap is central to the paper's security contribution. If it cannot be closed with an explicit authentication mechanism (e.g., validating the trapping PC against the trampoline or a per-domain capability), the headline switch-abuse resistance claim should be withdrawn. Please also consider requiring artifacts as part of the revision, given that all performance numbers come from emulated hardware."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: NanoZone is a real step forward for intra-process isolation on Arm CCA. The three-tier POE/PIE/GPC3 design and the PIM-based function-pointer protection are new and plausible. The authors are unusually honest about the emulation gap. But the L2/L3 switch trigger via RNDR looks unauthenticated, and that cuts into the paper's central claim about blocking domain-switch abuse.\n\nWhat is actually new: the first combination of POE, PIE, and GPC3 into a unified zone hierarchy, extending the 7-domain POE limit to 28 via unused PIE indexes and then to effectively unlimited by reusing indexes across PASs. The domain-allocation optimization that keeps the L1 switch hit rate around 96% is clever and well evaluated. Extending GCS to protect function pointers with a PIM region is a useful contribution. The paper ships no code or data, which is a real limitation, but the FVP functional prototype and the RK3399 emulation are reasonable given that no commercial hardware yet supports the required features.\n\nThe soft spot that matters: the RNDR-trap switch path. Section 4.3 says any user-space RNDR/RNDRRS read traps to the Monitor and the Monitor validates the request by checking the current GPT base. That only distinguishes proc GPT from OS GPT; it does not authenticate which L1 domain initiated the switch. The trampoline argument does not help if ordinary RNG consumers can execute the trap instruction, and the paper never explains how OpenSSL or kernel RNG reads are distinguished from switch requests. If an attacker in an untrusted L1 domain can set the target zone parameter and execute RNDR, they can request a privileged L2/L3 switch to any zone of the protected process. That undermines mutual isolation and the claim that CPI blocks switch abuse. CPI protects the control-flow path to the trampoline, but this path bypasses it. This needs a concrete fix, such as per-domain authentication in the Monitor or an unforgeable switch token.\n\nThe rest of the security analysis is honest but informal; the CVE table is illustrative rather than proof. Performance numbers are internally consistent but emulated, so absolute overheads may shift on real silicon. The authors acknowledge this, and I do not see a red flag beyond the RNDR gap.\n\nVerdict: this deserves serious peer review. The design is novel and the evaluation is careful, but the RNDR switch path needs to be closed or reworked before the security claims hold. I would want to see the artifact and a threat-model-consistent answer on RNDR before accepting.","headline":"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.","tokens_in":25891,"tokens_out":3266,"would_cite":true,"duration_ms":34541,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"NanoZone splits one process into unlimited secure zones on Arm CCA","keywords":["Arm CCA","intra-process isolation","permission overlay extension","permission indirection extension","granule protection table","code-pointer integrity","guarded control stack","confidential computing"],"falsifier":"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.","tokens_in":24855,"feed_emoji":"🛡️","tokens_out":5692,"duration_ms":53800,"temperature":0.7,"pith_summary":"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.","feed_headline":"Isolation zones go from 7 to unlimited inside one Arm process","feed_subtitle":"Three-tier zone design plus code-pointer integrity blocks kernel and same-process attacks for about 20% overhead.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the POE and PIE hardware layers that form L1 and L2 zones.","marker":"[19]"},{"why":"Supplies the GPT and PAS machinery that forms the L3 physical-address-space layer.","marker":"[20]"},{"why":"Supplies the GPC3 bypass-window register, the per-core mechanism that makes unlimited PAS reuse scalable.","marker":"[21]"},{"why":"Supplies the Guarded Control Stack used for return-address protection inside CPI.","marker":"[22]"},{"why":"Shelter is the process-level CCA isolation baseline that NanoZone extends to intra-process granularity.","marker":"[11]"},{"why":"LightEnclave is the MPK-based intra-enclave design whose 16-domain limit and Intel-only platform motivate the CCA-native scalable design.","marker":"[14]"},{"why":"EPK is the scalable MPK approach it parallels; its 512-EPT ceiling motivates the GPT-based L3 design.","marker":"[29]"},{"why":"CAGE provides the per-PAS-per-GPT baseline used to quantify the initialization-cost advantage of the bypass-window approach.","marker":"[47]"}],"fun_headline_variants":["Unlimited Arm CCA zones: 20% overhead, kernel-proof","7 to unlimited zones in one Arm process, no HW changes","NanoZone: Break Arm's 7-domain ceiling with 20% cost","In-process isolation: unlimited zones on Arm CCA","Arm CCA: unlimited zones, same-process attacks blocked"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Unlimited Arm CCA zones: 20% overhead, kernel-proof","7 to unlimited zones in one Arm process, no HW changes","NanoZone: Break Arm's 7-domain ceiling with 20% cost","In-process isolation: unlimited zones on Arm CCA","Arm CCA: unlimited zones, same-process attacks blocked"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000738,"raw_usage":{"total_tokens":3352,"prompt_tokens":1058,"completion_tokens":2294,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":674,"completion_tokens_details":{"reasoning_tokens":2205}},"tokens_in":674,"tokens_out":2294,"duration_ms":16068,"temperature":1.0,"reasoning_tokens":2205,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T05:42:30.932756+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Permission indirection and permission overlay extensions,","cited_arxiv_id":null,"evidence_quote":"Supplies the POE and PIE hardware layers that form L1 and L2 zones."},{"cited_title":"Learn the architecture - realm management extension,","cited_arxiv_id":null,"evidence_quote":"Supplies the GPT and PAS machinery that forms the L3 physical-address-space layer."},{"cited_title":"Granule protection check bypass window register (el3),","cited_arxiv_id":null,"evidence_quote":"Supplies the GPC3 bypass-window register, the per-core mechanism that makes unlimited PAS reuse scalable."},{"cited_title":"Arm® architecture reference manual for a-profile architec- ture,","cited_arxiv_id":null,"evidence_quote":"Supplies the Guarded Control Stack used for return-address protection inside CPI."},{"cited_title":"Shelter: Extending arm cca with isolation in user space,","cited_arxiv_id":null,"evidence_quote":"Shelter is the process-level CCA isolation baseline that NanoZone extends to intra-process granularity."},{"cited_title":"A {Hardware- Software} co-design for efficient {Intra-Enclave} isolation,","cited_arxiv_id":null,"evidence_quote":"LightEnclave is the MPK-based intra-enclave design whose 16-domain limit and Intel-only platform motivate the CCA-native scalable design."},{"cited_title":"{EPK}: Scalable and efficient memory protection keys,","cited_arxiv_id":null,"evidence_quote":"EPK is the scalable MPK approach it parallels; its 512-EPT ceiling motivates the GPT-based L3 design."},{"cited_title":"Cage: Complementing arm cca with gpu extensions,","cited_arxiv_id":null,"evidence_quote":"CAGE provides the per-PAS-per-GPT baseline used to quantify the initialization-cost advantage of the bypass-window approach."}],"review_version":1}