Learn Cloud Hypervisor - Confidential Computing: TDX & SGX

#Introduction

So far we've assumed the host is a trusted party. But what if it isn't? In the public cloud, you rent a VM on a server owned by someone else — who guarantees the cloud admin can't read your VM's memory? This is the problem confidential computing answers: guest memory is encrypted at the CPU level so that even the host can't read it.

In episode 14 we cover two Intel technologies — TDX (Trust Domain Extensions) and SGX (Software Guard Extensions) — which Cloud Hypervisor supports experimentally, plus the attestation mechanism for proving that a VM runs in a genuinely trusted environment.

#The Confidential Computing Concept

#The Threat It Fights

In the traditional security model, the hypervisor/host is considered trusted: it can read VM memory because it allocates it. Confidential computing changes this model: VM memory is encrypted with a key only the CPU knows, so the host (including its kernel, drivers, and admins) can only see ciphertext. If the host tries to read VM memory, all it gets is encrypted data it can't decrypt.

This matters for workloads like AI models with sensitive data, encryption keys, or medical data in the public cloud.

#Intel's Two Approaches

TDX and SGX take different paths:

• SGX: protects an enclave — a special memory region within an application process. The enclave is isolated even from its parent process and the OS.
• TDX: protects the entire VM (Trust Domain). The guest VM is the security unit: its whole memory is encrypted by hardware, and the VMM can only interact through a restricted interface.

In the Cloud Hypervisor context, TDX is more relevant because it fits the "entire VM protected" model. SGX is better suited for isolation at the application process level.

#TDX in Cloud Hypervisor

#Architecture and Status

TDX support in Cloud Hypervisor is experimental. The architecture: Cloud Hypervisor acts as the VMM for the non-confidential parts (devices), while the confidential part (vCPU, memory) is handled by TDX hardware. Trust Domain memory is encrypted automatically; the VMM can only access allowed regions.

Hardware prerequisites:

grep -o "tdx" /proc/cpuinfo | head -1
ls /dev/tdx_guest /dev/tdx_host 2>/dev/null

This feature only exists on certain Intel CPU generations (Sapphire Rapids and later), and the host must enable TDX in the BIOS and load the related kernel modules.

#Running a TDX VM

Booting a TDX VM is basically the same, with dedicated firmware and flags:

cloud-hypervisor \
  --firmware tdx-firmware.fd \
  --kernel kernel-tdx \
  --disk path=os.raw \
  --cpus boot=4 \
  --memory size=4G \
  --tdx

--tdx marks the VM as a Trust Domain. Inside the guest, a TDX-aware kernel sees the encrypted memory transparently — applications don't need changes, because encryption happens in hardware.

#SGX in Cloud Hypervisor

SGX works at the application enclave level, not the whole VM. In Cloud Hypervisor, SGX support lets a guest run applications with hardware-protected enclaves — the host can't read enclave memory.

grep -o "sgx" /proc/cpuinfo | head -1

Common SGX use cases: key management, virtual HSMs, and multi-party computation. Because the enclave is inside the guest, the threat from the host is still addressed, but the enclave remains vulnerable to a compromised guest kernel — which is why the TDX + SGX combination is often considered the strongest.

#Attestation: Proving the Environment

#Why Attestation

Memory encryption alone isn't enough — how do you know the memory is really encrypted and the VM runs on a legitimate CPU? The answer is attestation: the process of generating a quote — cryptographic proof from the CPU that the environment is running as promised.

#The Attestation Flow

VM boot →  CPU menghasilkan quote (tanda tangan hardware)
    ↓
Quote dikirim ke verifier (bisa lokal atau cloud provider)
    ↓
Verifier memeriksa quote terhadap kebijakan (policy)
    ↓
Jika valid → kunci/setup dipercaya untuk memulai workload

The quote is signed with a key embedded in the CPU and is only valid for a specific configuration. Inside the guest, this mechanism is exposed through a tool or library:

tdx-attest --quote /tmp/quote.bin

#Verifying the Quote

The verifier checks several things: the CPU's identity (via the quote signature), the measurement of the image/firmware, and the allowed policy. After the quote is verified, you can be confident the VM's memory can't be read by the host before you send sensitive data.

#Limitations and Pitfalls

• Rare hardware: TDX/SGX need specific Intel CPUs; in the public cloud, only instances that expose these features (the "confidential" class).
• Experimental: don't make it a production foundation before the feature is considered stable on the roadmap.
• Guest kernel: the guest must boot with a kernel supporting TDX/SGX; a standard cloud image kernel may not be enough.
• Attestation uses external services: the verifier needs access to Intel/cloud services to validate the quote — prepare the connectivity.
• Performance: memory encryption has overhead; benchmark your workload before committing.

#Conclusion

Key takeaways:

• Confidential computing encrypts VM memory so the host can't read it.
• TDX protects the entire VM; SGX protects enclaves at the process level.
• TDX/SGX support in Cloud Hypervisor is still experimental and needs special hardware.
• Attestation/quote is cryptographic proof that the environment runs as promised.
• "Verify before trust": give data only after attestation succeeds.
• Encryption has overhead — benchmark before production.

In the next episode, episode 15, we'll run Windows guests in Cloud Hypervisor — booting Windows 10/Server via UEFI (CLOUDHV.fd), installing virtio drivers, the differences between upstream edk2 and the CLOUDHV fork (especially on AArch64), and best practices for stable Windows on virtio. From Linux, we jump into the Windows world!