Confidential Computing Enclaves
- Confidential computing enclaves are secure execution environments defined by hardware-enforced isolation, crucial for protecting code and data against unauthorized access.
- They employ both process-based and VM-based approaches, utilizing memory encryption and attestation mechanisms to verify integrity and confidentiality.
- Recent research extends enclave designs to accelerator architectures, in-memory compute substrates, and recursive isolation, enhancing secure data processing in modern infrastructures.
Confidential computing enclaves are hardware- and software-backed execution environments offering strong confidentiality and integrity guarantees for code and data—even against a privileged or compromised operating system, hypervisor, or cloud infrastructure. These enclaves form the key primitive underpinning modern Trusted Execution Environments (TEEs), enabling secure in-use data processing, attestation, verifiable integrity, and isolation from co-tenants and adversarial hosts. Recent work generalizes the notion of enclaves from CPU-resident regions (e.g., Intel SGX/TDX, AMD SEV-SNP) to include accelerator-rich architectures, composable cross-device domains, in-memory compute substrates, and unified, recursive isolation APIs for future datacenter fabrics.
1. Architectural Principles and Enclave Taxonomy
Enclaves are defined by a hardware-enforced isolation boundary that protects code and data from all non-enclave software and DMA-capable devices. Two architectural approaches dominate:
- Process-based Enclaves: Hardware partitions a region of system memory for the enclave, with the MMU and on-chip Memory Encryption Engine (MEE) enforcing access control and confidentiality. Enclave state is explicitly entered/exited using instructions such as EENTER/EEXIT (SGX) or via hypercalls (e.g., HyperEnclave, Keystone) (Bourgeat et al., 2018, Jia et al., 2022).
- VM-based Enclaves: TEEs at the virtual machine abstraction (e.g., AMD SEV, Intel TDX) employ full-VM encryption, attestation, and memory integrity. Trusted containers and confidential VMs add management, orchestration, and higher-level attestation (Brasser et al., 2022, Johnson et al., 2023).
Domain-specific extensions include accelerator enclaves (e.g., "Software-Defined Enclaves" for ML (Banerjee et al., 2020)), composite enclaves (configurable cross-device TCBs (Schneider et al., 2020)), and in-memory enclaves ("PIM-Enclave" (Duy et al., 2021)). Some proposals (e.g., Tyche (Ghosn et al., 16 Jul 2025)) unify all of these under a trust-domain abstraction with recursive composition.
Table 1: Major Enclave Frameworks
| Framework | Abstraction | Memory Boundary | Attestation |
|---|---|---|---|
| SGX / TDX | Process, VM | EPC (128 MiB), TDX VM | MRENCLAVE, Quote |
| SEV/SEV-SNP | VM | Full VM | PSP, SNP Attestation |
| Keystone/Sanctum | Process | DRAM partitions | SM measurement, Hash |
| HyperEnclave | Process (VMX) | Hypervisor-enforced | TPM PCR + Hash |
| Tyche | Trust Domain | Arbitrary granularity | Monitor-Signed, TPM |
2. Security Goals, Attestation, and Threat Models
The fundamental enclave security properties are:
- Confidentiality: All code and data inside the enclave are invisible to non-enclave software/devices.
- Integrity: Unauthorized modifications by non-enclave agents are detected or prevented.
- Initial-state and Code Attestation: Enclaves provide cryptographic measurement of loaded code/data (e.g., SHA-256 or SHA-3) at creation; remote parties can verify via a signature chain anchored in a device-bound key (e.g., via Intel’s Quoting Enclave or AMD’s VCEK, or via TPM (Lebedev et al., 2018, Agarwal et al., 6 Nov 2025)).
- Formal Non-Interference: For example, MI6 demands that an attacker’s observations when attacking a co-resident
