CCSI

Lesson 2.1 · 12 min read

Enclaves versus confidential VMs

Two architectural approaches with very different TCBs and porting costs.

Two ways to draw the box

CPU TEEs fall into two broad families. Process-level enclaves (Intel SGX is the main example) protect a portion of a single application's address space. Confidential virtual machines (Intel TDX, AMD SEV-SNP, Arm CCA Realms) protect an entire VM, including its guest kernel, from the hypervisor and host.

Enclave versus confidential VMPROCESS-LEVEL ENCLAVECONFIDENTIAL VMUntrusted app partEnclave (trusted)only selected code + dataOS kernelHypervisor / hostApplicationsGuest kernel + firmwareinside the TCBTDX module / AMD-SP / RMMHypervisor / host
Teal = trusted, red = untrusted. Enclaves keep the TCB small but require partitioning the app; confidential VMs allow lift-and-shift but trust a whole guest OS.
Process-level enclaveConfidential VM
Unit of protectionPart of one processA whole virtual machine
TCB sizeSmall: enclave code plus CPULarger: guest firmware, kernel, user space, plus CPU and its security firmware
Porting effortHigh: partition the app, or use a library OS such as GramineLow: run existing OS images with a TEE-aware kernel
Interface to the hostEnclave calls in and out (ECALL/OCALL)Virtual devices; I/O through shared, unencrypted pages
ExamplesIntel SGXIntel TDX, AMD SEV-SNP, Arm CCA Realms; also used by AWS, Azure and Google Cloud confidential VM offerings

Key takeaways

  • Enclaves minimise the TCB at the cost of re-architecting the application.
  • Confidential VMs are easier to adopt but put an entire guest OS inside the TCB, which then needs hardening and measurement.
  • In a confidential VM, I/O goes through shared memory that the host can see, so encrypt it at the application layer.