TEE Technologies: SGX, TDX, SEV-SNP and Friends

Summary

Confidential computing protects data while it is being processed. That is the gap left after at-rest and in-transit encryption. The mechanism is the Trusted Execution Environment (TEE): a hardware enclave that isolates a computation from the rest of the system (OS, hypervisor, cloud provider).

This document walks through the major TEE designs in technical detail.

1. The problem: data in use

Traditional encryption protects data in two states: - At rest: storage encryption (AES-256, LUKS, TDE). - In transit: TLS/SSL on the network.

The gap is data in use. While the CPU is working on it, plaintext sits in RAM. That exposes sensitive workloads to: - Malicious cloud providers or hypervisors. - Row hammer and cold-boot attacks. - Malicious insiders with physical access. - Software vulnerabilities in the host OS.

Confidential computing addresses this by creating hardware-protected enclaves where data is decrypted only for authorized code running inside the TEE.

2. Intel Software Guard Extensions (SGX)

Overview

Intel SGX is the first modern confidential-computing technology, introduced in 2015 with 6th-Generation Core processors (Skylake). It provides fine-grained enclave protection at the application level.

Architecture

┌─────────────────────────────────────────────────────┐
│                User Space                          │
│  ┌─────────┐    ┌─────────┐    ┌─────────┐        │
│  │Regular │    │ Enclave │    │Regular │        │
│  │ App A  │    │ (SGX)   │    │ App B  │        │
│  └─────────┘    └─────────┘    └─────────┘        │
│        │             │             │               │
│        └──────┬──────┘────────────┘               │
│               ▼                                    │
│  ┌─────────────────────────────────────────┐     │
│  │       Operating System (Untrusted)       │     │
│  └─────────────────────────────────────────┘     │
│                      │                            │
│  ┌─────────────────────────────────────────┐     │
│  │     System Firmware / BIOS (Untrusted)  │     │
│  └─────────────────────────────────────────┘     │
│                      ▼                             │
│  ┌─────────────────────────────────────────┐     │
│  │    Processor Reserved Memory (PRM)      │     │
│  │  ┌─────────────���─────────────────────┐  │     │
│  │  │    Enclave Page Cache (EPC)         │  │     │
│  │  │  Encrypted Memory Regions          │  │     │
│  │  └───────────────────────────────────┘  │     │
│  └─────────────────────────────────────────┘     │
│                      ▼                            │
│  ┌─────────────────────────────────────────┐     │
│  │         CPU (Trusted)                   │     │
│  │   Memory Encryption Engine (MEE)       │     │
│  └─────────────────────────────────────────┘     │
└─────────────────────────────────────────────────────┘

Key components

New CPU instructions

• EINIT: initialize and launch an enclave.
• EENTER: transfer control into the enclave.
• EEXIT: exit the enclave.
• EADD: add pages to an enclave.
• EEXTEND: extend the enclave measurement (256-byte chunks).
• EREMOVE: remove pages from the enclave.
• EGETKEY: derive sealing or attestation keys.
• EREPORT: create an attestation report for another enclave.

Security properties

• Memory encryption: EPC contents are encrypted by the MEE using keys burned into the CPU.
• Access control: the CPU blocks all memory access to EPC except from an enclave running in enclave mode.
• Isolation: even privileged software (OS, hypervisor, SMM) cannot read enclave memory.
• Attestation: remote parties can verify the enclave's identity via signed reports.

Limitations

• Small enclave size: EPC is limited to roughly 256MB on most CPUs (128MB max).
• No virtualization: SGX cannot run a full OS; application-level only.
• Page swap limitations: EPC pages can be swapped but require special handling.
• Attack surface: smaller than VM-level solutions but with fewer features.
• Side-channel vulnerabilities: Spectre, L1TF, Foreshadow attacks.

Use cases

• Cryptographic key management.
• Secure authentication.
• Database query processing on sensitive data.
• AI model inference on private data.
• Blockchain privacy (transaction validation).

3. AMD Secure Encrypted Virtualization (SEV)

Evolution

AMD's confidential computing has gone through several generations:

SEV architecture

┌─────────────────────────────────────────────────────┐
│                   Hypervisor (Untrusted)                │
│  ┌─────────────────────────────���─��──────────────────┐ │
│  │           VMs with encrypted memory              │ │
│  │  ┌─────────────┐   ┌─────────────┐               │ │
│  │  │  VM 1 (SEV) │   │  VM 2 (SEV) │               │ │
│  │  │  Key: K1    │   │  Key: K2    │               │ │
│  │  └─────────────┘   └─────────────┘               │ │
│  └──────────────────────────────────────────────────┘ │
│                         │                              │
│  ┌──────────────────────────────────────────────────┐ │
│  │      System BIOS / AMD-V (Untrusted)             │ │
│  └──────────────────────────────────────────────────┘ │
│                         ▼                             │
│  ┌──────────────────────────────────────────────────┐ │
│  │      AMD EPYC CPU (Encrypted Memory Engine)     │ │
│  │   Per-VM encryption keys, isolated address spaces│ │
│  └──────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘

SEV vs SEV-ES vs SEV-SNP

SEV-SNP security properties

1. Confidentiality: each VM has a unique encryption key; the hypervisor cannot read VM memory.
2. Integrity: the RMP (Reverse Map Table) prevents memory remapping attacks. The hypervisor cannot remap a guest physical page to a different host page without invalidating the integrity check.
3. Attestation: SNP provides hardware-attested launch certificates.
4. Migration: supports secure live migration between hosts.

Advantages over SGX

• Full VM isolation: can run entire operating systems.
• Larger workloads: no enclave size limits.
• Standard virtualization: works with KVM, VMware, Hyper-V.
• Multi-vCPU support: scales across multiple cores.

Limitations

• AMD-only: only available on EPYC processors (Zen 2+).
• Hypervisor trust: assumes hypervisor cooperation (though SNP mitigates).
• Performance overhead: ~1-5% latency for encrypted memory operations.
• Live migration: more complex than non-confidential VMs.

4. Intel Trust Domain Extensions (TDX)

Overview

Intel TDX, introduced in 2022, provides VM-level confidential computing. It is designed for cloud environments that need full OS isolation, complementing rather than replacing SGX.

Features

• Confidential VMs: full virtual machines with encrypted memory.
• TDX Module: a new CPU mode for managing confidential VMs.
• TD-Shield: memory encryption and isolation.
• Flexibility: supports both enumerated and flex-attestation.

Architecture

┌─────────────────────────────────────────────────────┐
│              Virtual Machine Monitor               │
│                    (VMM - Untrusted)               │
└��────────────────────────────────────────────────────┘
                         │
              ┌────────┴────────┐
              │   TDX Module     │
              │   (CPU mode)     │
              └────────┬────────┘
                         │
┌─────────────────────────────────────────────────────┐
│              Confidential VMs (TD)                 │
│  ┌─────────────┐   ┌─────────────┐   ┌──────────┐ │
│  │   TD 1      │   │   TD 2      │   │  TD N    │ │
│  └─────────────┘   └─────────────┘   └──────────┘ │
└─────────────────────────────────────────────────────┘

Comparison with SGX

5. Arm Confidential Compute Architecture (CCA)

Overview

Arm CCA, introduced with the Armv9-A architecture (2021), builds on TrustZone and adds Realm execution: a new security world for confidential computing.

TrustZone -> CCA evolution

TrustZone (Armv8):
┌─────────────────────────────────────┐
│     Normal World (Rich OS)          │
├─────────────────────────────────────┤
│         Secure World (TEE)         │
│    (Static, immutable partitions)  │
└─────────────────────────────────────┘

Armv9 CCA:
┌─────────────────────────────────────┐
│     Normal World (Rich OS/VM)       │
├─────────────────────────────────────┤
│         Secure World (TEE)          │
├─────────────────────────────────────┤
│      NEW: Realm World               │
│   (Dynamic, confidential VMs)     │
└─────────────────────────────────────┘

Key components

Security model

• Realm Management Monitor (RMM): small TCB firmware that mediates all Realm operations.
• Hyp switch: hypervisor requests become RMM calls rather than direct hardware access.
• Dynamic allocation: Realms can grow and shrink memory dynamically.
• Attestation: RMM provides secure attestation of Realm state.

Advantages

• Full VM support: runs entire OSes in Realms.
• Hardware-verified monitor: RMM in verified ARM assembly.
• Performance: uses VHE (Virtualization Host Extension) for minimal overhead.
• Ecosystem: builds on the TrustZone ecosystem.

6. Comparison matrix

When to use each

7. Cloud provider offerings

AWS Nitro Enclaves

• Uses the Nitro hypervisor (custom).
• Provides isolated execution environments.
• VPC-attached encrypted containers.
• No dedicated hardware TEE; relies on the Nitro security model.

Azure Confidential Computing

• Intel SGX: DCsv2, DCsv3, DCdsv2 VMs.
• AMD SEV-SNP: DCasv5 / ECasv5 / DCadsv5 series.
• Intel TDX: DCesv5 / ECesv5 series (distinct from the SEV-SNP DCasv5).
• Attestation: Microsoft Azure Attestation (MAA).

Google Cloud Confidential VMs

• AMD SEV (legacy): N2D, C2D.
• AMD SEV-SNP: N2D (Milan, GA June 2024) and newer.
• Intel TDX: C3 (Sapphire Rapids), preview/GA depending on region.
• NVIDIA H100 CC: A3 Confidential (preview as of late 2025).
• Confidential Space: container-based enclaves.
• Customer-managed encryption keys with Cloud KMS.

Comparison matrix

8. Attack surface and mitigations

Known attacks

Defense layers

1. Hardware root of trust: keys burned into the CPU.
2. Secure boot chain: verify firmware before execution.
3. Attestation: prove TCB state to remote parties.
4. Encryption: all data at rest inside the TEE.
5. Isolation: no direct hardware access from untrusted software.

Best practices

• Use the latest TEE generation (SEV-SNP > TDX > SGX).
• Keep TCB updated.
• Combine multiple TEE generations for defense in depth.
• Use constant-time code to prevent timing attacks.

9. Implementation considerations

For developers

1. Pick a TEE: SGX for fine-grained, SEV/TDX/CCA for full VMs.
2. Minimize TCB: only put sensitive code in the enclave.
3. Design for attestation: plan how to verify enclave identity.
4. Handle secrets carefully: never log or expose them.
5. Test side-channel resistance: use constant-time patterns.
6. Use a library OS (Gramine, Occlum) for running unmodified apps.

For infrastructure

1. Hardware selection: ensure the CPU supports the required TEE.
2. Firmware updates: keep CPU microcode current.
3. Secure boot: enable measured/verified boot.
4. Key management: use hardware-backed key storage.
5. Monitoring: log TEE operations for audit.
6. Attestation service: set up remote-attestation services for verification.

Recommended frameworks

• Gramine: library OS for running unmodified apps in SGX.
• Occlum: memory-safe OS for SGX enclaves.
• Kata Containers: VM-based containers with TEE.
• Confidential Containers (CoCo): Kubernetes integration.
• Marblerun: CoCo orchestrator for Kubernetes.

10. Further reading

• Confidential Computing Consortium
• Intel SGX Developer Guide
• AMD SEV-SNP Specification
• Arm CCA Architecture
• Cloud Security Alliance - Confidential Computing
• Gramine Project
• Occlum

Part of the Ungovernable.tech knowledge base. Last updated: April 2026

Continue with TEE state, recovery and revocation.