PaperlayerView exact revision on arXiv

Source-linked AI summary

PRISM: Lightweight Enclave Isolation with Prismatic Capabilities

Merve Gülmez, Adam Caulfield, Hakan Englund, N. Asokan, Thomas Nyman

arXiv:2608.26367v1cs.CR

TL;DR

TEEs isolate sensitive code and data but do not inherently prevent memory-safety vulnerabilities, while CHERI-based TEE designs face ownership, physical-isolation, transition, and attestation challenges. PRISM introduces prismatic capabilities that bind enclave hues to physical memory controls and support hardware-assisted lifecycle management and attestation. The reported overhead is approximately 6–15%, with the prototype also imposing scope and latency limitations.

  • Problem

    TEE architectures protect against host interference but leave trusted software exposed to memory-safety vulnerabilities, while CHERI-based designs face costly ownership checks and limited physical isolation and attestation.

  • Method

    PRISM extends CHERI with prismatic capabilities whose machine-mode-managed hues bind enclave capabilities to physical memory access controls and support efficient transitions and attestation.

  • Results

    Approximately 6–15% run-time overhead is reported, while formal analysis establishes the security of PRISM’s attestation protocol.

  • Takeaways & Limitations

    PRISM demonstrates that strong userspace enclaves can be built as a lightweight, capability-native extension combining isolation, memory safety, and remote attestation.

  • Takeaways & Limitations

    Enclave memory is committed once in a fixed physically contiguous region, requiring worst-case provisioning and potentially up to 2× internal fragmentation from NAPOT rounding.

Abstract

from arXiv · show

Trusted execution environments (TEEs) protect sensitive code and data from external interference, but lack inherent memory safety. CHERI can enforce spatial memory safety at the object level. Attempts to establish a TEE using CHERI primitives suffer from (1) expensive capability revocation operations, (2) need to rely on the host operating system (OS) to support provenance tracking and physical memory protection, (3) expensive domain transitions, and (4) lack of support for remote attestation. We introduce prismatic capabilities and present PRISM, a TEE architecture for CHERI leveraging prismatic capabilities to create userspace enclaves while addressing these challenges. PRISM binds enclave 'hues' (identifiers) in prismatic capabilities to physical memory access controls, enables O(1) ownership establishment without memory sweeps, and supports efficient domain transitions that atomically activate and deactivate prismatic capabilities. Additionally, PRISM enables remote attestation of its enclaves. We demonstrate that execution of userspace enclaves in PRISM incurs only moderate overhead (<= 15%), a significant improvement over the same workloads under Intel SGX

1 Introduction

TEEs isolate sensitive code and data from compromised hosts, but their trusted software remains exposed to memory-safety vulnerabilities. PRISM addresses CHERI-based enclave challenges with prismatic capabilities, physical isolation, efficient transitions, and attestation.

  • TEEs protect sensitive code and data from compromised or malicious host operating systems, but trusted software remains vulnerable to memory-safety issues.
  • CHERI enforces object-level spatial memory safety and supports fine-grained compartmentalization through capability sealing and controlled invocation.
  • CHERI-based enclave designs face expensive ownership verification, host-OS dependencies for provenance and physical protection, costly transitions, and missing attestation support.
  • PRISM introduces prismatic capabilities whose enclave hues bind capabilities to physical memory regions, gate access, control invocation, and provide attestation identities.
  • 6–15% run-time overhead is reported for three real-world SGX enclaves recompiled to PRISM.

2 Background

CHERI adds capability-based hardware protection for spatial memory safety, while TEEs provide architectural isolation from host software. Existing TEE and RISC-V designs differ in how they partition resources and manage trusted execution.

  • CHERI extends an ISA with hardware capabilities that enforce spatial pointer safety through hardware-software co-design.
  • 128-bit capabilities on 64-bit platforms include permissions, object types, bounds, and validity tags, plus a separate tag bit preventing unauthorized capability injection.
  • CHERI capability bounds encode valid memory ranges relative to the baseline address, using compression that trades space savings for stricter alignment on larger allocations.
  • TEEs architecturally isolate code and data so that only code within the same TEE can directly call, read, or write them, including against privileged host software.
  • Commercial TEE designs include userspace enclaves in Intel SGX and resource partitioning between normal and secure worlds in ARM TrustZone.
  • Keystone uses RISC-V physical memory protection and a machine-mode reference monitor to control TEE memory access at runtime.

3 Problem Statement

A capability-based TEE must preserve exclusive ownership and physical isolation despite an untrusted OS, while also providing safe transitions, memory safety, and attestation. PRISM’s design goals formalize these requirements.

  • The system assumes a CHERI-enabled processor in pure-capability mode with an MMU and an OS managing multiple userspace processes and address translation.
  • The threat model gives a compromised OS control over arbitrary operations and unprotected memory, allowing it to leak secrets or tamper with enclave code and data.
  • The model assumes CHERI’s spatial-safety and monotonicity properties, including that permissions and bounds can only decrease when deriving capabilities.
  • Enclave software must validate prismatic capabilities received from untrusted software, even though hardware keeps those capabilities opaque to untrusted software and other enclaves.
  • P1 requires exclusive capability ownership without expensive searches and provenance metadata inaccessible to untrusted software.
  • P2 binds enclave capabilities to physical access controls so isolation remains effective against an untrusted host OS managing virtual-to-physical translation.
  • P3–P5 require safe domain transitions, spatial and temporal safety, and cryptographic measurement and attestation bound to the installed TCB and device.

4 Prismatic Capabilities Design

Prismatic capabilities extend CHERI with hue-based physical isolation and color-based temporal safety. PRISM’s machine-mode monitor manages enclave creation, execution, interruption, attestation, and destruction through hardware-assisted lifecycle operations.

  • Prismatic Capabilities: Each enclave receives a machine-mode-assigned hue, while dynamically allocated data capabilities additionally receive colors for temporal-safety protection.
  • Prismatic Capabilities: Hardware compares capability hues against the Hue-Addressed Memory table, which maps contiguous physical regions to enclave identifiers and controls accesses.
  • Prismatic Capabilities: CHERI monotonicity preserves an enclave hue in derived capabilities, while arbitrary-hue capabilities cannot be forged.
  • Enclave Creation: At creation, the HMM assigns a hue, measures enclave code and data, records the binding, and associates the hue with a physical region.
  • Enclave Execution: Enclave invocation validates matching code and data hues, activates the corresponding HAM entry, installs the code capability, and transfers control without an HMM trap.
  • Enclave Execution: Interrupt handling saves enclave state in inaccessible memory, deactivates its HAM entry, scrubs the trap frame, and restores execution when re-invoked.
  • Enclave Execution: Exiting atomically deactivates the hue to re-lock enclave memory while preserving the HAM entry for later re-entry.
  • Attestation: Remote attestation reports include enclave and HMM measurements, the hue, and a challenge, then bind them to the device through a signing key.

5 Implementation Details

PRISM implements prismatic capabilities across CHERI-RISC-V hardware, the HMM, CheriBSD, enclave runtimes, and SGX compatibility. Its implementation uses HAM-based physical isolation, hue-encoded capabilities, controlled transitions, attestation, and lifecycle management.

  • Implementation Components: PRISM has QEMU and FPGA-based CHERI-RISC-V implementations, with an M-mode HMM, CheriBSD driver, and SGX-compatibility runtime.The runtime includes trusted and untrusted components mirroring SGX counterparts.
  • Physical Isolation: HAM is a 64-entry fully associative table that checks post-MMU physical accesses against protected regions and capability hues.The mechanism covers instruction fetches and data loads/stores, binding physical memory access to enclave identity.
  • Physical Isolation: Each HAM entry records a physical-region base, power-of-two size, enclave hue, validity, and active-execution state.The entry fields use 52 bits for the base page, 6 bits for region size, 6 bits for hue, and one bit each for validity and activity.
  • Capabilities and Transitions: Prismatic capability object types encode hue and color, while enclave entry activates the HAM entry only when EInvoke commits.PRISM squashes younger instructions before fetching enclave code, preventing execution under an inactive hue.
  • Lifecycle and Attestation: The HMM assigns hues, measures enclave code and data, programs HAM entries, and manages enclave creation, attestation, and destruction.Destruction scrubs enclave pages and resume state before invalidating the HAM entry and returning memory to supervisor control.
  • Lifecycle and Attestation: PRISM protects interrupt and fault handling by using non-preemptible transition windows, idempotent resume, and HMM-trapped enclave-relevant faults.The HMM reloads saved state for resume and invalidates the HAM entry when a hue-bearing enclave fault occurs.
  • CheriBSD and SGX Compatibility: CheriBSD keeps the kernel untrusted: it allocates and stages memory, invokes the HMM, relays capabilities, and supports enclave lifecycle ioctls.The SGX-compatibility library exposes a small interface in which lifecycle management uses two /dev/tee ioctls plus close, while entry and exit use unprivileged instructions.

6 Evaluation

PRISM is evaluated across performance, hardware cost, and security. It delivers modest overhead relative to PICASSO, substantially lower overhead than SGX in tested applications, moderate hardware costs, and strong memory-safety and attestation results.

  • Performance: PRISM incurs a ≈1.06x geomean overhead factor versus ≈1.05x for PICASSO across SPEC CPU 2006 benchmarks.The authors report libquantum as the exception and characterize PRISM’s baseline-execution overhead as modest.
  • Performance: PRISM’s relative overhead is 1.06x–1.15x for SGX_SQLite versus 1.67x–1.81x for SGX, and 0.72x–1.13x for sgx-kmeans versus 3.90x–81.8x.The comparison normalizes PRISM to PICASSO and SGX to non-SGX execution; tested SGX enclaves exclude memory encryption.
  • Performance: Hardware-mediated, trap-free domain transitions and a shared fast resumption path explain PRISM’s lower overhead than SGX across evaluated applications.PRISM handles enclave entry and exit in the HAM without HMM traps, while SGX uses microcode mediation, EPCM validation, and AEX/ERESUME state handling.
  • Fixed costs: PRISM adds ≈16% logic, ≈11% registers, and ≈8% memory overhead over unmodified CHERI-Toooba, while the HMM occupies 273.7KB.The measurements synthesize implementations on the VCU118 FPGA at 25MHz.
  • Security Analysis: PRISM detects all 392 vulnerable Juliet use-after-free cases and produces no false positives across 392 benign cases.The test cases execute unmodified inside a PRISM enclave through the standard SGX ECALL interface.
  • Security Analysis: PRISM’s attestation analysis proves report authenticity, HMM integrity, enclave integrity, and key secrecy properties.These sub-properties collectively support the protocol’s attestation security property.

7 Related Work

PRISM is positioned as a capability-based TEE that combines isolation, memory safety, and attestation under an untrusted paging OS. Compared with prior designs, it also supports unmodified SGX applications on real RTL hardware.

  • PRISM and prior capability-based TEEs: PRISM combines hardware-enforced enclave isolation, in-enclave spatial and temporal safety, and remote attestation under an untrusted paging OS.The paper presents this combination as a capability-based TEE distinction from prior work.
  • PRISM and prior capability-based TEEs: Prior systems generally provide only subsets of PRISM’s isolation, memory-safety, attestation, virtual-memory, or hardware-realization features.The comparison includes software-hardening approaches, CHERI extensions, RISC-V TEEs, and earlier capability-based TEEs.
  • Implementation distinction: PRISM runs unmodified SGX applications on a real RTL implementation, unlike earlier capability-based TEE designs described by the paper.Only source adaptation for CHERI C/C++ conformance and recompilation for the PRISM-enabled CHERI-Toooba target are excepted.

8 Discussion and Future Work

PRISM’s discussion identifies bounded revocation, memory-region provisioning, sweep latency, side-channel scope, and future composition as important design boundaries. It also describes mechanisms for safer revocation, enclave growth, and memory-safety enforcement while outlining unresolved limitations.

  • Revocation: 63 concurrent enclave instances are supported by the default 6-bit hue namespace, while retired hues are quarantined and reclaimed through batched system-wide sweeps.Destruction remains constant-cost, but sweep cost is amortized across enclave lifetimes and can still require scanning tagged memory.
  • Revocation: A naïve single-pass sweep is unsound under concurrent untrusted execution because stale capabilities can be copied after the sweep passes their original locations.The proposed prismatic capability store barrier instead clears tags whenever U-/S-mode stores a capability bearing a retired hue.
  • Prototype boundary: The prototype performs hue-reclamation sweeps with host S-/U-mode execution halted, making worst-case latency proportional to physical memory size.This is presented as acceptable for a prototype because availability is out of scope and sweeps are rare by construction.
  • Enclave sizing: PRISM enclaves use one physically contiguous, fixed-size region, requiring worst-case provisioning and incurring up to 2× internal fragmentation from NAPOT rounding.Growth can add privileged regions, but the current design shares a fixed 64-entry HAM and leaves unrestricted growth infeasible.
  • Threat model and future work: PRISM does not claim immunity from transient-execution attacks, instead leaving side-channel resistance to enclave software and selectively composable mechanisms.Future work also considers nesting PRISM enclaves within CoVE TVMs, but memory ownership, layered attestation, and world-switch interactions remain open questions.

9 Conclusion

PRISM combines prismatic capabilities with a minimal M-mode monitor to provide lightweight, secure userspace enclaves on CHERI. Implementations and evaluation show modest hardware and runtime costs alongside modeled attestation security.

  • Contributions: PRISM binds enclave capabilities to unforgeable hues that enforce exclusive physical-memory access.Hue checks occur through hardware structures after address translation, protecting enclave memory from a malicious OS.
  • Contributions: PRISM avoids memory sweeps and revocation trees, supports trap-free enclave entry, and provides remote attestation through a minimal M-mode monitor.These mechanisms address several constraints of prior capability-based TEE designs.
  • Implementation and evaluation: PRISM was implemented on CHERI-RISC-V QEMU and a CHERI-Toooba FPGA softcore, with CheriBSD and an SGX-compatibility layer.The compatibility layer runs unmodified enclaves, and evaluation covers three real-world SGX applications.
  • Results: 16% logic and approximately 6–15% runtime overhead were reported, while symbolic Tamarin analysis established attestation-protocol security.Together, these results support lightweight capability-native userspace enclaves.

A Additional Performance Evaluation

The additional evaluation separates PRISM execution cost from enclave lifecycle cost and compares both with PICASSO. Results vary by application and input, with lifecycle operations often dominating end-to-end overhead.

  • Measurement: PRISM reports end-to-end time including creation and destruction, while PRISM Exec. measures isolated execution alone; PICASSO reports execution time only.This comparison distinguishes enclave lifecycle costs from temporally safe execution costs.
  • CryptoEnclave: 0.95%–4.46% execution overhead occurs for CryptoEnclave file-taking operations, while lifecycle operations raise end-to-end overhead to 20.7%–71.7%.For simpler command-line variants, execution time is negligible and lifecycle operations account for most PRISM overhead.
  • SGX_SQLite: 4.9%–5.7% execution overhead is added for selected SGX_SQLite tests, while ib tests reduce execution overhead by 5.6%–6.4%.Including enclave creation and destruction produces 1.19%–13.3% end-to-end overhead.
  • sgx-kmeans: 0.33%–0.70% execution-overhead reductions occur for sgx-kmeans inputs N = 100K, 700K, and 900K, while other input sizes incur up to 11.7%.End-to-end overhead ranges from 0.01%–11.7% and is heavily influenced by ECALL data marshaling.

B Tamarin Model

The Tamarin model represents PRISM’s measurement and remote-attestation protocol as multiset-rewriting rules and formalizes its sub-security properties as lemmas.

  • Modeling approach: PRISM’s measurement and remote-attestation process is modeled in Tamarin using protocol rules and lemmas for each sub-security property.The model uses hashing, signing, and natural-number built-ins for cryptographic and arithmetic behavior.

B.1 Rule-based Model.

The rule-based model encodes PRISM initialization, enclave creation, attestation requests, report generation, and verification as precondition, action, and postcondition transitions.

  • Rule structure: Each Tamarin rule specifies required preconditions, logged action facts, and produced postconditions.This structure captures how protocol state changes across modeled steps.
  • Initialization: Rule 5 models HMM installation by generating fresh secret-key and HMM values, then initializing system state, a public key, network output, and an empty hue table.The empty hue table is represented with the natural-number counter %1.
  • Enclave creation: Rule 6 permits enclave creation only after hue-table initialization and records the enclave software and incremented hue.The rule logs an Encl_install action for later lemma verification.
  • Performance comparison: Figure 8 compares PICASSO total end-to-end time, PRISM total end-to-end time, and PRISM execution time excluding enclave creation and destruction.The figure presents three timing series for the enclave-application comparison.
  • Attestation request: Rule 7 models receipt of a hue and challenge, logging the request and producing Get_Report for report generation.The request arrives from the verifier over the network.
  • Report generation: Rule 8 generates a signed report when initialization, the request, and the requested enclave hue are present.The signed contents include the hue, challenge, HMM measurement, and enclave measurement.
  • Verification: Rule 9 verifies packed report data and signatures using the prover’s public key, logging the verification attempt without a postcondition.The modeled result is recorded in a Verified action fact.

B.2 Security Sub-properties.

PRISM’s attestation security is decomposed into sub-properties covering authenticity, integrity, secrecy, and freshness. Tamarin verifies these properties as lemmas, and all lemmas pass.

  • Security sub-properties: Report authenticity requires every accepted report to be signed with the verifier’s expected private key.Lemma 0 checks that a successful verification implies a prior matching signature.
  • Security sub-properties: Key secrecy requires that an adversary cannot learn or derive the signing secret key from observable channels.Lemma 3 models this condition using Tamarin’s adversary-knowledge rule.
  • Security sub-properties: Freshness requires every accepted response to use the verifier’s challenge from a prior attestation request.Lemma 4 ensures responses are produced per request, and all lemmas pass verification.
Loading 2608.26367v1…