Secure Enclaves on RISC-V: Implementation Challenges and Solutions

Secure enclaves — isolated execution environments where code can run protected from the rest of the system, including the operating system — are one of the most powerful tools in the hardware security architect's toolkit. Intel SGX and ARM TrustZone brought enclave technology to mainstream silicon, but both have well-documented limitations. RISC-V offers the opportunity to design enclave architectures without inheriting those limitations.

The challenge is that RISC-V also offers no standard enclave mechanism. Where x86 has SGX and ARM has TrustZone, RISC-V has a variety of proposals, experimental implementations, and research projects — but no standardized, production-hardened enclave technology with widespread silicon support. This is simultaneously RISC-V's limitation and its opportunity.

Why Existing Enclave Architectures Fall Short

Intel SGX, despite being a mature and widely deployed enclave technology, has a well-documented vulnerability history. Speculative execution attacks (Spectre, Meltdown, and their descendants) have repeatedly compromised SGX enclaves by exploiting microarchitectural behaviors that cross trust domain boundaries. The fundamental issue is that SGX isolation, while architecturally sound, does not account for side-channel leakage through shared microarchitectural state.

ARM TrustZone provides a simpler isolation model (two worlds: secure and normal) that is less vulnerable to speculative execution attacks but has its own limitations. The coarse-grained two-world model does not support multiple mutually distrusting secure enclaves. A vulnerability in any one trusted application can potentially compromise the entire secure world. This architectural limitation has been demonstrated in practice by vulnerabilities in TrustZone-based trusted execution environments including OP-TEE and various vendor-specific TEE implementations.

RISC-V, designed after both of these architectures were deployed at scale, can learn from their limitations. The modular nature of the RISC-V ISA means that enclave-relevant extensions can be added without the legacy constraints that shaped SGX and TrustZone designs.

RISC-V Enclave Primitives

The RISC-V architecture provides two hardware mechanisms that are relevant to enclave implementation:

Physical Memory Protection (PMP): PMP provides machine-mode-controlled access restrictions on memory regions. A properly configured PMP can prevent a supervisor-mode OS kernel from accessing enclave memory. However, PMP has a fixed number of regions (typically 8 or 16), which limits the number of concurrent enclaves and the granularity of protection.

RISC-V Hypervisor Extension (H-extension): The H-extension enables hardware-assisted virtualization with two-level address translation. Enclave architectures that use the H-extension can leverage hardware-enforced VM-level isolation with lower overhead than software-based approaches. The H-extension is now ratified and available in several commercial RISC-V implementations.

The most mature RISC-V enclave framework is Keystone, a research project from UC Berkeley that uses PMP and a security monitor running in machine mode to provide enclave isolation. Keystone has been deployed on multiple RISC-V platforms and has been used to demonstrate several enclave use cases. Its main limitations are the PMP region count constraint and the fact that the security monitor is a significant TCB that must be carefully audited.

Keystone in Detail: Strengths and Gaps

Keystone's architecture provides several important security properties. The security monitor (SM) runs in machine mode and manages PMP configurations, ensuring that enclave memory regions are inaccessible to the OS kernel during enclave execution. The SM also provides enclave lifecycle management: creation, attestation, and destruction with appropriate isolation guarantees at each phase.

The gaps in Keystone for production use are primarily two: performance and TCB size. The security monitor represents a significant trusted code base that must be verified as correct, and each SM entry (for PMP reconfiguration) adds latency to enclave operations. For high-throughput enclave workloads, this overhead can be significant.

Research teams at several universities are actively working on Keystone extensions that address these limitations, including hardware-accelerated PMP management and formal verification of the security monitor. We expect Keystone-derivative architectures to reach production quality within the next 12-18 months.

Side-Channel Considerations

The fundamental challenge in building side-channel-resistant enclaves on RISC-V — or on any shared microarchitecture — is that isolation primitives protect logical access but do not prevent information leakage through shared physical resources: caches, branch predictors, execution units, and buses.

For RISC-V SoC designs targeting enclave workloads, we recommend the following design-time mitigations:

• Cache partitioning: Hardware-enforced cache way partitioning prevents cache-timing attacks across enclave boundaries
• Constant-time cryptographic primitives: Cryptographic operations in enclave code must be implemented using constant-time algorithms that do not branch on secret data
• Microarchitectural flush on context switch: Flushing branch predictors and other speculative state on enclave entry and exit prevents information leakage via speculative channels
• Memory access pattern obfuscation: For enclaves that handle sensitive data, access pattern oblivious algorithms or oblivious RAM (ORAM) schemes prevent memory access timing attacks

These mitigations add implementation complexity and some have performance costs. The appropriate set of mitigations depends on the threat model: a medical device enclave handling patient data may require all of them, while an industrial controller enclave protecting calibration parameters may require fewer.

The Path to Production Enclaves on RISC-V

Production-quality enclave support on RISC-V is approaching but not yet universally available. The RISC-V International organization has active working groups developing enclave-relevant specifications, and several commercial RISC-V SoC vendors have announced proprietary enclave implementations.

The RISC-V Security Model specification, currently in development through RISC-V International, will provide a standardized framework for security domains and isolation that enclave implementations can target. When this specification is ratified, it will provide a stable foundation for enclave interoperability across RISC-V implementations — similar to how ARM's TrustZone specification enabled a class of compatible TEE implementations.

For teams designing RISC-V-based products that require enclave functionality today, the most reliable path is to use a RISC-V SoC with a dedicated hardware security subsystem that provides enclave-like isolation for security-critical operations, rather than attempting to implement a full general-purpose enclave on current-generation RISC-V cores without dedicated enclave hardware support.

The zeroRISC platform is designed to interface with both dedicated security subsystems and emerging RISC-V enclave implementations. Our SDK provides abstraction layers that will support both current hardware-security-subsystem-based architectures and future standardized RISC-V enclave implementations as they become production-ready. Contact us to discuss enclave architecture for your specific use case.