PaperlayerView exact revision on arXiv

Source-linked AI summary

NACRE: Rethinking Confidential Containers through Native Architectural Support

Linke Song, Wenhao Wang, Weijie Liu, Rui Hou

arXiv:2609.03849v1cs.CRcs.OS

TL;DR

A compromised host can inspect or modify conventional container state, while existing confidential-computing boundaries do not make a dynamic host-managed Linux process group the protection unit. NACRE uses hardware-recognized container identities, an isolated agent, and a monitor to separate resource management from security authority; its QEMU prototype reports lmbench means within 3.5% of baseline and nginx throughput 1.9% lower.

  • Problem

    Conventional containers rely on the host kernel, which can inspect memory, modify mappings, or forge container metadata when compromised; existing hardware boundaries do not make host-managed process groups the protection unit.

    Source: §I · p. 1, C. RISC-V Support and Missing Primitives · p. 4

  • Method

    NACRE uses hardware-recognized container identities, identity-aware access and event routing, an isolated agent for frequent mediation, and a monitor for security-critical state transitions.

    Source: §I · p. 2

  • Results

    Five lmbench syscall and pipe metric means were within 3.5% of the same-daemon runc-origin baseline, and equally weighted nginx throughput was 1.9% lower.

    Source: §I · p. 2, §X · p. 17

  • Takeaways & Limitations

    The QEMU prototype supports feasibility of separating host resource management from security authority on the modeled data and control paths.

    Source: §X · pp. 16–17

    The prototype establishes feasibility only for modeled paths and does not validate complete multi-container, sharing, multicore, or attestation semantics.

    Source: §VIII · p. 15

Abstract

from arXiv · show

Linux containers achieve high density and fast lifecycle operations by sharing the host kernel, but this design also lets a compromised host inspect or modify container state. Existing confidential-computing systems protect an enclave address space or an entire guest operating system, while recent container-granularity systems still add a separate protection context. These abstractions do not make a dynamic group of host-managed Linux processes the architectural protection unit. This paper presents NACRE, a RISC-V hardware-software co-design for native confidential containers. Its key insight is to separate the host's authority to manage resources from its authority to access or commit protected state. Hardware-recognized container identities direct protected traps to an isolated S-mode agent, while an M-mode monitor commits security- sensitive identity, mapping, and page transitions. The agent delegates services to host Linux without changing satp; services that neither access private bytes nor modify protected state also avoid M-mode. We prototype NACRE by extending QEMU, OpenSBI, Linux, a trusted agent, and runc. The prototype implements the single-container private-memory substrate and covered launch, fault, fork/COW, user-access, and teardown paths. Across five lmbench syscall and pipe metrics, the three-run means remain within 3.5% of the runc-origin baseline. With the eight nginx object-size means weighted equally, aggregate throughput is 1.9% lower.

I. INTRODUCTION

NACRE addresses the mismatch between host-managed Linux containers and confidential-computing boundaries by making a dynamic process group the protection unit. It separates host resource management from security authority and reports near-baseline lmbench means and a small nginx throughput reduction in its QEMU prototype.

I. INTRODUCTION

  • Conventional containers rely on the host kernel, so a compromised host or privileged administrator can inspect memory, alter mappings, or forge container metadata.They therefore cannot protect workloads on infrastructure whose privileged software is not fully trusted.Source: §I · p. 1
  • A native confidential container is a dynamically managed Linux process group protected by hardware while retaining host-native scheduling and resource management.The host must not gain access to protected state or authority over security-sensitive transitions.Source: §I · p. 1
  • Enclave and VM abstractions protect an address space or guest OS, while container-granularity systems add protection contexts rather than making host-managed process groups hardware protection units.These boundaries complicate native process management or separate lifecycle and resource management from host Linux.Source: §I · pp. 1–2
  • NACRE introduces hardware-recognized container identities that govern access checks and event routing, with trusted mechanisms controlling identity creation, inheritance, and revocation.This prevents host-forged membership and access through page remapping.Source: §I · p. 2
  • An isolated trusted agent mediates container interactions while a higher-privilege monitor handles identity management and protected-resource ownership transitions.Protected traps reach the agent rather than exposing architectural state first to the untrusted host.Source: §I · p. 2
  • Delegated services remain in the native address-space and privilege context without VM entry, page-table switching, or TLB flushing; services that avoid private bytes and protected state also avoid M-mode.The host continues scheduling, allocating physical memory, and providing ordinary Linux services.Source: §I · p. 2
  • The QEMU prototype spans OpenSBI, Linux, a trusted agent, and runc, and implements launch, demand paging, protected PTE updates, fork/COW, typed kernel access, and teardown.Evaluation covers the single-container private-memory substrate; cross-container ownership, protected shared objects, and attestation remain design-level mechanisms.Source: §I · p. 2
  • Five lmbench syscall and pipe metric means were within 3.5% of the same-daemon runc-origin baseline, while equally weighted nginx throughput was 1.9% lower.These are QEMU prototype results.Source: §I · p. 2

II. BACKGROUND & MOTIVATIONS

Native containers are dynamically changing host-scheduled Linux process groups whose memory and services follow ordinary Linux lifecycles. Existing enclave, VM, and container-granularity approaches use different protection units and service paths, separating some lifecycle operations from the host-native model.

A. Native Container Execution Model

  • Native execution keeps process lifecycle, resource management, and Linux services on host Linux while protecting confidential state from the untrusted host.Processes use native fork, clone, exec, exit, memory management, and services such as signals, file I/O, shared memory, futexes, pipes, and sockets.Source: A. Native Container Execution Model · p. 3

B. Mismatch Between Existing Works and Native Containers

  • Enclave systems protect an address space or memory region, so multi-process abstractions and resource sharing must be implemented inside runtimes or coordinated across enclave boundaries.Their protection unit is not a dynamically changing group of host-managed Linux processes.Source: B. Mismatch Between Existing Works and… · p. 3
  • CVM-based containers place workloads with a guest kernel inside the VM, making the CVM—not the host-visible process group—the protection and resource-management boundary.Process creation and virtual-memory management occur inside the guest, while physical-resource allocation and virtualized I/O remain coordinated with the VMM and host.Source: B. Mismatch Between Existing Works and… · p. 3
  • Container-granularity approaches add a separate protection context or mediation layer, which can break the direct path to host Linux and increase overhead for frequent operations.Arca's protection unit and service path depend on its selected enclave or CVM backend.Source: B. Mismatch Between Existing Works and… · pp. 3–4

C. RISC-V Support and Missing Primitives

Standard RISC-V mechanisms do not directly provide container-identity-aware protection and trap routing while preserving efficient host service. NACRE separates resource management from security authority, with a threat model that trusts the monitor and agent but excludes several attacks and guarantees.

C. RISC-V Support and Missing Primitives

  • Standard privilege checks, PMP, and trap delegation lack container-aware same-level isolation and source-identity routing without placing frequent events in M-mode.A lightweight handoff must also retain the current address-translation context and avoid M-mode for delegated services that access neither private bytes nor protected state.Source: C. RISC-V Support and Missing Primitives · pp. 4–5

III. THREAT MODEL

  • The threat model treats host Linux and management software as adversarial, trusts the monitor and agent, and excludes denial of service, side channels, and post-release I/O protection.It also assumes authenticated boot and DMA isolation; the QEMU prototype assumes rather than implements these platform properties.Source: §III · p. 5

A. Design Overview

  • NACRE treats each cid as a protection domain, leaving Linux resource management while trusted components mediate confidential traps and commit protected state.Linux-created mappings and metadata are proposals, not authority to alter protected context, mappings, page ownership, or sharing.Source: A. Design Overview · pp. 5–6

B. Protection Substrate

NACRE combines execution identity with physical-page roles to protect confidential address spaces while leaving Linux responsible for ordinary allocation and upper-half kernel mappings. The monitor validates and commits protected updates.

Protection substrate

  • NACRE combines execution identity and physical-page role to check access, while reserved memory holds the agent, monitor metadata, and protected non-root pagetables.Linux cannot directly modify monitor metadata or protected pagetables; hardware uses agent-region bounds and execution state to distinguish agent access from host Linux access.Source: B. Protection Substrate · p. 6
  • NACRE_STATUS carries the registered cid and control-flow state; only monitor restoration or controlled call-and-return instructions can change a registered task’s state.An unregistered task has zero status and follows ordinary Linux access and trap rules.Source: B. Protection Substrate · p. 6, Figure 3
  • Linux allocates root pagetables and user pages, while the monitor assigns ROOT and PRIV roles and allocates protected lower-level pagetables; PEND denies access during a copy transaction.The monitor promotes a successfully copied destination to PRIV and commits its PTE; an uncommitted destination must not return to Linux’s ordinary lifecycle.Source: B. Protection Substrate · p. 6
  • The prototype protects lower-half user PTEs in Sv39, leaves upper-half kernel mappings under Linux control, and mediates protected page-state or pagetable-permission changes.Sv48 and Sv57 are described but not implemented or evaluated; status-aware translation context also prevents incompatible TLB reuse.Source: B. Protection Substrate · pp. 6–7

C. Container Initialization and Runtime Mediation

NACRE registers container tasks, admits execution after monitor validation, and routes confidential traps through an agent that delegates selected services to Linux. The monitor commits protected-memory transitions across faults, process lifecycle operations, and sharing.

Container initialization

  • The launch path registers a task and cid with the monitor before ordinary Linux exec; the prototype accepts supplied identifiers and treats the application image as pretrusted.The prototype therefore validates lifecycle plumbing, not resistance to forged or stale membership, and does not implement image verification.Source: C. Container Initialization and… · p. 7
  • After ELF loading, the monitor enrolls protected pages and maps the agent into a reserved user-address-space slot, then the agent initializes its trap entries and runtime state.The monitor-controlled agent bounds admit agent-state accesses while rejecting protected U-mode and Linux S-mode accesses.Source: C. Container Initialization and… · pp. 7–8

Runtime mediation

  • The monitor restores scheduling state from registered thread contexts, but the prototype lacks a non-bypassable scheduling hook and freshness mechanism against malicious Linux.The target invariant requires a fresh, monitor-bound task, cid, and address-space context before protected user return.Source: C. Container Initialization and… · p. 8
  • Confidential traps first enter the agent, which saves protected registers and delegates a Linux-readable context through a controlled trampoline; Linux returns through the agent.The handoff does not change satp, and delegated services avoid M-mode when they neither access private bytes nor modify protected state.Source: C. Container Initialization and… · pp. 8–9

Private-memory substrate

  • Linux resolves faults and allocates pages, while OpenSBI validates and commits protected PTE and page-role changes, including demand-fault updates.The protected reference count tracks monitor-approved mappings and determines when a private page can be retired.Source: C. Container Initialization and… · p. 9

Container lifecycle

  • Fork and COW use monitor transactions that copy private contents and publish the destination PTE atomically, while Linux retains surrounding process bookkeeping.Fork copies inherited private pages eagerly rather than sharing them between parent and child.Source: C. Container Initialization and… · p. 9
  • On teardown or replacement, OpenSBI validates retired PTEs, decrements private references, clears a page before returning it to NORM, and retires the root last.Protected non-root pagetables return to their protected allocation area, not the Linux buddy allocator.Source: C. Container Initialization and… · p. 9

Controlled sharing

  • Same-cid shared objects require agent-mediated approval and monitor-recorded mappings; detach revokes mappings and stale translations before page reuse.Cross-container mappings require a live monitor-visible grant naming the recipient and permissions.Source: C. Container Initialization and… · p. 10

D. Target Measurement and Attestation

NACRE defines a measured container object bound to a fresh cid and root-pagetable generation, but report generation and verifier integration are outside the current prototype.

Target measurement and attestation

  • Attestation binds the measured container object to a fresh cid and root-pagetable generation, while report generation and verifier integration remain outside the prototype.The object covers monitor and agent configuration, the initial application image, accepted public mappings, and container policy.Source: D. Target Measurement and Attestation · p. 10

V. IMPLEMENTATION

The prototype combines modified QEMU, OpenSBI, Linux, a trusted agent, and minimally changed runc. It keeps ordinary Linux paths intact while routing protected-state commits through OpenSBI.

A. Prototype Organization

  • The prototype modifies QEMU, OpenSBI, Linux, and a trusted agent, while runc adds only one registration call before exec.The remaining OCI launch path is unchanged; ordinary exec, scheduling, VM policy, and kernel metadata stay on standard Linux paths.Source: A. Prototype Organization · p. 10

B. Boot and Launch Integration

  • OpenSBI installs the appended agent before Linux boots, then clears the source copy and descriptor and restricts the installed agent region to M-mode.The prototype assumes the boot artifact and initial container image are pretrusted; it does not implement authenticated boot or an image-manifest protocol.Source: B. Boot and Launch Integration · p. 10
  • Before exec, runc registers the container identifier; Linux forwards the resulting pid/cid tuple to OpenSBI and then continues ordinary exec and ELF loading.The first protected task performs agent bootstrap, while later exec and child paths reuse the installed runtime state.Source: B. Boot and Launch Integration · p. 10
  • Table III lists representative SBI operations for registration, attachment, protected PTE updates, and address-space retirement.The operation names cover lifecycle steps including fork/COW, pagetable allocation and updates, and task unregistration.Source: Table III · p. 11, B. Boot and Launch Integration · p. 11

C. NACRE SBI Commit Interfaces

NACRE exposes protected-state commit points through SBI calls that Linux enters after native lifecycle or memory-management work. Linux retains its ordinary accounting and path logic, while OpenSBI validates and commits protected bindings, mappings, copies, and retirement.

C. NACRE SBI Commit Interfaces

  • NACRE SBI calls mark where Linux must enter OpenSBI before protected bindings, pagetable updates, or teardown actions become effective.The interfaces are commit points, not a general metadata-management API.Source: C. NACRE SBI Commit Interfaces · p. 11

D. Single-Container Lifecycle Integration

  • Registration creates monitor-side pid/cid and task-context state; after exec builds an address space, the task attaches through invoke, reexec, or a child path.Later exec and child paths reuse the installed agent runtime rather than repeating the first-process bootstrap.Source: D. Single-Container Lifecycle… · p. 11
  • Linux retains VMAs, page accounting, and ordinary page-table descriptors, while OpenSBI tags root pages and allocates protected non-root pagetable pages from its managed pool.Common RISC-V PTE primitives are redirected when their target slot belongs to protected pagetable state; OpenSBI validates the destination and PFN role before writing the PTE.Source: D. Single-Container Lifecycle… · p. 11
  • During fork, OpenSBI admits at most one fresh child root per monitor-owned fork window and records the exact parent-child relation.For each inherited private leaf, it validates the source and destination, copies into a fresh page in M-mode, and publishes the child PTE with the page's promotion to PRIV as one transaction.Source: D. Single-Container Lifecycle… · p. 11
  • For private COW, OpenSBI validates the source leaf and fresh destination, copies the bytes, and commits the replacement leaf with PEND-to-PRIV promotion and private-reference updates.Linux still allocates and charges the destination and performs its ordinary race check; PEND is transient, with no persistent Linux-controlled copy reservation.Source: D. Single-Container Lifecycle… · pp. 11–12
  • During teardown, OpenSBI retires the old protected leaf's private reference before Linux completes normal page bookkeeping, and batches protected non-root pagetable reclamation after leaf mappings are retired.The root page is retired separately after protected leaves and non-root pages are gone; NACRE_UNREGISTER removes task state rather than cleaning up the address space.Source: D. Single-Container Lifecycle… · p. 12

E. Linux Memory Integration

NACRE integrates private-memory handling into selected Linux memory paths while preserving ordinary Linux behavior elsewhere. Its trap path delegates services through the agent, with M-mode used for operations that access private bytes or change protected state.

E. Linux Memory Integration

  • NACRE preserves the vDSO ABI by copying an accepted image into protected memory, while VVAR remains a separately bound public mapping with read-only, non-executable user permissions.Linux retains the supervisor mapping used to update VVAR time data.Source: E. Linux Memory Integration · p. 12
  • VM_NACC_APP marks candidate private-anonymous mappings and _PAGE_NACC carries private-data intent in leaf PTEs, routing fault, COW, uaccess, and teardown paths.The markers describe candidates and exceptions; they do not authorize protected ownership.Source: E. Linux Memory Integration · p. 12
  • For marked private ranges, explicit uaccess enters OpenSBI to resolve and perform reads, writes, copies, or clears in M-mode; non-private ranges use normal Linux helpers.A valid write-protected private destination triggers the ordinary Linux writable-fault/COW path, then retries after the protected leaf is replaced.Source: E. Linux Memory Integration · p. 12
  • For raw S-mode aliases, Linux specifies the intended access and range to OpenSBI, which validates the protected context and performs the operation in M-mode; other accesses to PRIV PFNs are denied.Linux retains its native call path but does not directly dereference or modify PRIV PFNs.Source: E. Linux Memory Integration · p. 12

F. Trap and Architectural Support

  • Registered tasks trap first to the agent, which prepares a Linux-readable frame and delegates through acall; Linux returns through aret for the agent to restore the sanitized frame.acall/aret does not enter M-mode, but delegated services that access private bytes use typed OpenSBI operations.Source: F. Trap and Architectural Support · p. 12
  • QEMU separates translation context by NACRE execution state and checks page roles for final physical addresses before installing translations.It also enforces agent bounds and invalidates cached translations across virtual CPUs when OpenSBI changes a page role.Source: F. Trap and Architectural Support · pp. 12–13

G. Prototype Scope

The QEMU prototype implements a single-container private-memory substrate and key lifecycle paths, while leaving several target-system protections incomplete. The security analysis describes how the design's isolation, transition, and execution rules address specified attack paths, alongside remaining host-service risks.

G. Prototype Scope

  • The prototype implements protected pagetable updates, bitmap/reference-count metadata, private-memory transitions, agent trap delegation, and principal fork/COW/exit paths.Its fork path selects one child root and uses FORK_COPY_INSTALL rather than shared private PFNs or persistent copy reservations.Source: G. Prototype Scope · p. 13
  • The prototype omits cross-container isolation, shared-object modeling, stale-identity protection, and attestation, and lacks complete exact-slot authorization and malicious-host-safe teardown rollback.Agent entry is validated only on the cooperative prototype path and has not been established for concurrent multicore execution; these limits bound the security claims.Source: G. Prototype Scope · p. 13

VI. SECURITY ANALYSIS

  • The target design requires monitor-only protected commits, treats Linux-supplied policy and PTEs as untrusted proposals, binds execution to task/cid/root/context, and restricts protected mappings by owner.Protected execution also requires authenticated initialization of the image, address space, agent, and public-mapping policy.Source: §VI · p. 13

A. Memory Isolation

  • Page-role checks deny ordinary U-mode and Linux S-mode access to PRIV pages, including through direct-map or temporary aliases, while protected application and agent execution can access them.Protected non-root page tables are S/U-readable but M-mode writable, and only the monitor commits lower-half ROOT entries; Linux retains upper-half kernel mappings.Source: A. Memory Isolation · p. 13

B. Lifecycle Transitions

  • On private faults, the monitor records the private role before publishing the leaf; fork and COW copy into PEND pages in M-mode and atomically publish the new PTE with PRIV promotion.The reverse transition removes mappings and stale translations, verifies the last reference is gone, clears the page in trusted mode, and only then returns it to NORM.Source: B. Lifecycle Transitions · p. 13

C. Execution and Trap Mediation

  • The monitor admits protected user returns only when task, cid, root, and saved context satisfy I3; traps pass through the agent before delegated Linux services.The agent does not verify arbitrary Linux results, so service outputs remain untrusted and Linux may return errors, delay, or refuse service.Source: C. Execution and Trap Mediation · pp. 13–14

D. Mediated Data Access and Sharing

NACRE mediates private-byte access and approved sharing while reserving protected mappings and metadata changes for the monitor. Its QEMU evaluation covers selected single-container paths, but does not establish the full malicious-host contract.

D. Mediated Data Access and Sharing

  • Typed monitor operations resolve private user addresses, check leaf permissions and access direction, then copy or clear bytes; their security depends on authorizing each purpose and range.Recognized public mappings are allowed, while writable sharing requires protected objects and revocation of authorized mappings before reuse.Source: D. Mediated Data Access and Sharing · p. 14

E. Prototype Security Boundary

  • The prototype implements agent-first traps, protected-page checks, and monitor-owned fork/COW transactions, but incomplete authorization and rollback leave the full malicious-host contract unestablished.Protected shared objects, cross-container grants, multicore-safe agent entry, authenticated initialization, DMA enforcement, and attestation remain outside the prototype.Source: E. Prototype Security Boundary · p. 14

VII. EVALUATION

  • Evaluation separates repeated measurements from functional and diagnostic tests, and its QEMU results characterize the software prototype rather than other deployment environments.The experiments use modified QEMU 9.2.0 with a RISC-V Ubuntu 22.04 guest; lmbench compares patched runc with an unmodified runc-origin arm under one Docker daemon.Source: A. Experimental Scope and Methodology · p. 14, §VII · p. 14

B. RQ1: Which Linux Paths Does the Prototype Execute?

  • The broad eight-path regression completed with expected outputs and no logged access denial or guest failure, but it predates the final fork transaction.LTP records do not support a Linux-ABI completeness claim because NACRE coverage is incomplete and the records are dominated by capability and seccomp policy.Source: B. RQ1: Which Linux Paths Does the… · p. 14
  • A dedicated protected-fork test passed on the implemented monitor-owned transaction, complementing—but not replacing—a broad regression on the same revision.The fork test produced expected output, exited with code zero, and showed no NACRE rejection or guest crash.Source: B. RQ1: Which Linux Paths Does the… · p. 14

C. RQ2: What Cost Appears on Common Paths?

The QEMU measurements show small reported differences on selected syscall, pipe, and nginx workloads. The evaluation also identifies limits in performance attribution, scalability evidence, and the prototype’s security and deployment scope.

C. RQ2: What Cost Appears on Common Paths?

  • Within 3.5%: all five retained same-daemon lmbench syscall and pipe means were within 3.5% of their corresponding baseline means across three runs.The reported conclusion is limited to retained metrics; omitted cases had missing values or large outliers, and aggregate measurements do not attribute cost to individual mechanisms.Source: C. RQ2: What Cost Appears on Common… · p. 15

D. RQ3: Can the Prototype Run Service Workloads?

  • 1.87% lower: equally weighted nginx mean throughput was 16,557.46 versus 16,873.20 KB/s, with the NACRE/baseline ratio at 0.9813 across eight object sizes.All 48 runs completed with zero failed requests; the matrix does not provide a confidence interval over independent experiment matrices.Source: D. RQ3: Can the Prototype Run Service… · p. 15
  • Netperf, SQLite, and memcached completed their tested workloads, but these tests lack repeated, controlled comparative measurements and support execution evidence only.Hackbench’s single-run observations exposed capacity and lifecycle work, not steady-state scalability; the larger NACRE run failed to attach a child after reaching CONTAINER_FULL.Source: D. RQ3: Can the Prototype Run Service… · p. 15, E. RQ4: What Remains Open? · p. 15

E. RQ4: What Remains Open?

  • Security testing supports exercised single-container paths, not a complete malicious-host or compatibility claim; wrong-owner, stale-binding, permission-change, and clear-before-reuse negative tests remain unrun.The prototype also excludes cross-container sharing, multicore agent entry, and attestation from evaluation.Source: E. RQ4: What Remains Open? · p. 15, §VIII · p. 15

VIII. DISCUSSION AND LIMITATIONS

  • The architectural mechanisms are represented by a QEMU functional model; the paper does not evaluate security or performance of potential Arm or x86 ports.Such ports could reintroduce address-space switches, additional trusted software, or extra privilege transitions; Linux and its device drivers also remain outside the TCB, so trusted paths need separate protection.Source: §VIII · p. 15

IX. RELATED WORK

NACRE targets the Linux container process group as a protection and lifecycle unit while retaining host-native scheduling and resource management. The conclusion reports feasibility on modeled paths, with cooperative checks still delimiting its malicious-host claim.

IX. RELATED WORK

  • Enclave systems protect an application address space, so multi-process and resource-sharing semantics must be reconstructed within or coordinated across enclave boundaries.NACRE instead targets the dynamically changing Linux process group.Source: §IX · p. 16
  • Confidential-VM systems protect a guest OS and preserve Linux semantics inside it, but place the guest rather than each container at the protection boundary.NACRE explores container-granularity protection while leaving host Linux responsible for scheduling and resource management.Source: §IX · p. 16
  • Prior container-granularity systems use varied trusted service layers and protection contexts; NACRE adds hardware-recognized container identity, peer-privilege event routing, and monitor-committed transitions.The cited approaches include TrustZone, virtualization, container monitors, and confidential-computing extensions.Source: §IX · p. 16
  • Overshadow and InkTag use virtualization with trusted or authenticated memory-management interfaces, while Dune exposes privileged CPU facilities outside the kernel; Iago attacks show that OS-controlled call results also matter.NACRE applies host-service versus protected-transition separation to container identity, trap delivery, and Linux lifecycle operations.Source: §IX · p. 16
  • ParaCell optimizes paravirtualized secure-container efficiency under a trusted-host model, while reusable-enclave and serverless work optimizes environment creation or reuse rather than NACRE’s untrusted-host protection boundary.NACRE focuses on keeping a dynamic Linux container as the hardware-recognized unit.Source: §IX · p. 16

X. CONCLUSION

  • NACRE makes a Linux container process group the protection unit and retains host scheduling and resource management; its QEMU prototype exercises single-container paths with lmbench means within 3.5% and nginx ratio 0.981.The conclusion limits the malicious-host claim because identity and lifecycle checks remain cooperative.Source: §X · pp. 16–17
Loading 2609.03849v1…