Confidential Computing on Linux: AMD SEV-SNP and Intel TDX with Remote Attestation in 2026

Confidential computing has finally moved from research labs to general availability across every major cloud provider. AMD SEV-SNP and Intel TDX are now the production foundations for protecting data in use — the third leg of the encryption triad, alongside data at rest and data in transit. So, if you're running Linux workloads that touch regulated data, AI model weights, or cryptographic key material, encrypting just disk and network isn't enough anymore. The hypervisor, the cloud operator, and even a malicious co-tenant all have to be pushed out of your trust boundary.

Honestly, the first time I attested a guest and watched the broker actually return the LUKS key only after the measurement matched — it felt like magic. It's not magic, of course. It's just a lot of careful plumbing.

This guide walks through the full stack: hardware enablement, host kernel setup, guest provisioning, and (most importantly) the remote attestation flows that let you cryptographically prove a workload is running inside a genuine, unmodified Trusted Execution Environment (TEE) before you hand it any secrets.

What Confidential Computing Actually Protects

A confidential VM (CVM) is a guest whose memory is transparently encrypted by the CPU using a key the host literally cannot read, and whose register state is sealed on every VM exit. The hypervisor still schedules the VM and handles I/O — it just can't inspect or tamper with guest memory. Both SEV-SNP and TDX go further than plain memory encryption: they add integrity protections (reverse map tables and SEAM mode, respectively) that block replay attacks, page-remapping attacks, and aliasing tricks that earlier generations like SEV-ES were vulnerable to.

What confidential computing does not protect against:

• Bugs inside your own guest software. Exploits inside the TD or CVM aren't magically stopped by the TEE.
• Side-channels that leak via shared caches, branch predictors, or memory bus timing. TDX and SEV-SNP both have known limitations here — check the threat model in the vendor specs.
• Storage attacks against unencrypted persistent disks. The disk must be encrypted with a key released only after successful attestation.

SEV-SNP vs TDX: How They Differ

Both technologies aim at the same security goal, but their architectures differ enough to affect real operational decisions.

Capability	AMD SEV-SNP	Intel TDX
Hardware	EPYC 7003 "Milan" or newer (best on Genoa/Bergamo)	Xeon Scalable 5th gen "Emerald Rapids" or newer
Isolation primitive	Reverse Map Table (RMP) enforced by the PSP	Secure Arbitration Mode (SEAM) on the main CPU
Attestation signer	VCEK on the AMD Secure Processor	TDX Module via Intel SGX Quoting Enclave
Measurement registers	Launch measurement + ID block	MRTD + 4x RTMR (runtime extendable)
Guest userspace interface	/dev/sev-guest	/dev/tdx_guest + configfs-tsm
vTPM support	Via SVSM at VMPL0	Provided by host or via vTPM-in-TD
Ubuntu host enablement	25.04+	25.10+ (attestation in 26.04 LTS)

In practice, the choice is usually made for you by your cloud provider or hardware vendor. Azure, GCP, and OCI all offer both SEV-SNP and TDX SKUs. AWS Nitro Enclaves is a separate, process-based model and is not covered here.

Setting Up an SEV-SNP Host on Linux

1. BIOS Configuration

SEV-SNP requires explicit firmware enablement. On EPYC platforms, enter the BIOS and set:

• SVM Mode: Enabled
• SMEE (Secure Memory Encryption Enable): Enabled
• SEV-SNP Support: Enabled
• SNP Memory (RMP Table) Coverage: Enabled (covers all host memory)
• SEV-ES ASID Space Limit: a non-zero value (e.g., 10 — leaves remaining ASIDs for legacy SEV)
• IOMMU: Enabled with SNP support

2. Host Kernel and Userland

Use a kernel that's at least 6.9 — 6.11 or newer is preferred because of fixes to ASID accounting and the KVM_X86_SEV_SNP_REQ_CERTS ioctl. On Ubuntu 25.04:

sudo apt update
sudo apt install -y qemu-system-x86 ovmf libvirt-daemon-system

# Verify SEV-SNP is exposed by the kernel
sudo dmesg | grep -i sev
# Expected: "SEV-SNP API:1.55 build:21"

# Confirm KVM has SNP enabled
cat /sys/module/kvm_amd/parameters/sev_snp
# Expected: Y

If sev_snp isn't Y, append kvm_amd.sev=1 kvm_amd.sev_es=1 kvm_amd.sev_snp=1 to the kernel command line via GRUB and reboot. Also make sure the PSP firmware is recent — dmesg should show API version 1.55 or higher. (Older firmware silently disables some report fields, which is a fun afternoon to debug.)

3. Launching the Guest with QEMU

A minimal SNP-enabled QEMU invocation looks like this:

qemu-system-x86_64 \
  -machine q35,memory-backend=ram1,confidential-guest-support=sev0 \
  -object memory-backend-memfd,id=ram1,size=8G,share=true,prealloc=false \
  -object sev-snp-guest,id=sev0,policy=0x30000,cbitpos=51,reduced-phys-bits=1 \
  -bios /usr/share/OVMF/OVMF_CODE.fd \
  -drive file=guest.qcow2,if=virtio,format=qcow2 \
  -cpu EPYC-v4 -smp 4 -m 8G -nographic -enable-kvm

The policy bitfield controls debug, migration, and SMT behavior. 0x30000 enables SNP-active and SMT-allowed with debug disabled, which is what you want for production. cbitpos=51 tells the firmware where the C-bit lives on Milan and newer parts.

Setting Up an Intel TDX Host on Linux

1. BIOS Configuration

TDX has more BIOS knobs than SEV-SNP, because it depends on Intel's Memory Encryption Multi-Tenant (TME-MT) feature and the SEAM Loader chain:

• TME (Total Memory Encryption): Enabled
• TME-MT: Enabled
• SW Guard Extensions (SGX): Enabled (TDX reuses SGX quoting)
• TDX: Enabled
• SEAM Loader: Enabled (loads the TDX Module from ESP/BIOS at boot)
• TDX Key Split: typically 1 (leaves keys for legacy TME)

2. Host Kernel and TDX Module

On Ubuntu 25.10 or newer, the canonical workflow is to use the upstream canonical/tdx repository, which scripts host enablement end-to-end:

git clone https://github.com/canonical/tdx.git
cd tdx
sudo ./setup-tdx-host.sh
sudo reboot

# After reboot, verify
sudo dmesg | grep -i tdx
# Expected: "tdx: module initialized" and a TDX Module version line

ls /sys/firmware/tdx/
# Should show tdx_module/ directory

If the TDX Module fails to initialize, the most common causes are stale microcode (update to the latest intel-microcode package) or memory-mirroring being enabled in BIOS. TDX is incompatible with the latter, which the error messages don't really make obvious.

3. Launching a TD Guest

qemu-system-x86_64 \
  -accel kvm,kernel-irqchip=split \
  -object '{"qom-type":"tdx-guest","id":"tdx0","quote-generation-socket":{"type":"vsock","cid":"2","port":"4050"}}' \
  -machine q35,confidential-guest-support=tdx0,hpet=off \
  -bios /usr/share/ovmf/OVMF.inteltdx.fd \
  -cpu host,-kvm-steal-time,pmu=off \
  -drive file=td-guest.qcow2,if=virtio,format=qcow2 \
  -smp 4 -m 8G -nographic

kernel_irqchip=split is mandatory for TDX — the in-kernel APIC just can't handle TD interrupt isolation. The quote-generation-socket opens a vsock channel (CID 2, port 4050) so the guest can request attestation quotes from the host's Quote Generation Service (QGS).

Remote Attestation: Proving the TEE Is Real

Encryption alone is worthless without attestation. Before your CI/CD pipeline, key server, or peer service hands the CVM any secret material, it must verify a signed report from the hardware that proves:

1. The VM is running on genuine, unrevoked AMD or Intel silicon.
2. SEV-SNP or TDX is actively enforcing memory encryption and integrity.
3. The launch measurement matches the firmware, kernel, and initrd you expect.
4. The platform firmware (TCB) is at a version that doesn't have known vulnerabilities.

SEV-SNP Attestation with snpguest

Install the snpguest CLI inside the CVM (or build it from github.com/virtee/snpguest):

# Inside the SEV-SNP guest
sudo modprobe sev-guest
ls -l /dev/sev-guest

# Generate a 64-byte nonce that will be embedded in the report
openssl rand -hex 64 > nonce.hex

# Request an attestation report
snpguest report attestation-report.bin nonce.hex

# Fetch the VCEK + ARK + ASK certs from AMD's KDS
snpguest fetch ca pem milan ./certs
snpguest fetch vcek pem milan ./certs attestation-report.bin

# Verify the full certificate chain and signature
snpguest verify certs ./certs
snpguest verify attestation ./certs attestation-report.bin

A typical verifier-side workflow looks like this. The verifier (running on your trusted side — your laptop, your CI, an HSM-backed key broker) checks four things: the certificate chain rolls up to the AMD Root Key, the report signature is valid, the REPORT_DATA field matches the nonce it sent (this is what prevents replay), and the launch measurement equals a known-good golden value.

# Verifier extracts and inspects key fields
snpguest display report attestation-report.bin | grep -E 'Measurement|Policy|TCB|Report Data'

Intel TDX Attestation via configfs-tsm

TDX uses the kernel's unified configfs-tsm interface, which (handily) also works for SEV-SNP and ARM CCA. Inside the TD:

# Load the guest module
sudo modprobe tdx_guest

# Mount configfs if not already
sudo mount -t configfs none /sys/kernel/config 2>/dev/null

# Create a report request
sudo mkdir /sys/kernel/config/tsm/report/report0
echo -n "$(openssl rand -hex 32)" | sudo tee /sys/kernel/config/tsm/report/report0/inblob
sudo cat /sys/kernel/config/tsm/report/report0/outblob > tdreport.bin

# Convert the TDREPORT into a signed Quote via the host QGS
trustauthority-cli quote --report tdreport.bin --out quote.bin

The Quote is signed by Intel's Quoting Enclave and can be verified by any party using Intel's PCS (Provisioning Certification Service) collateral. For production, most teams just delegate verification to a managed service like Intel Trust Authority, Microsoft Azure Attestation, or the open-source Trustee project from Red Hat. Rolling your own verifier is doable, but it's a lot of cert-chain plumbing to get exactly right.

Wiring Attestation Into Disk Decryption

The canonical use case here is unlocking an encrypted root or data disk only after a CVM proves it's trustworthy. The pattern, sometimes called "attested LUKS unlock," works like this:

1. The CVM boots from a small unencrypted initrd that contains an attester agent and the public key of your key broker.
2. The agent fetches a fresh attestation report (or quote) with a nonce supplied by the broker.
3. The broker verifies the quote, checks the measurement against an expected policy, and — only if everything matches — returns the LUKS passphrase encrypted to the CVM's ephemeral key.
4. The agent unlocks the LUKS device and pivots root.

A minimal client-side flow looks like this:

# In the initrd, after networking is up
NONCE=$(curl -s https://broker.internal/v1/nonce)
snpguest report report.bin <(echo -n "$NONCE")
KEY=$(curl -s --data-binary @report.bin \
        -H "Content-Type: application/octet-stream" \
        https://broker.internal/v1/unlock)
echo -n "$KEY" | cryptsetup luksOpen /dev/vda2 root --key-file -

Open-source brokers that implement this pattern in 2026 include Trustee (Red Hat / CNCF Confidential Containers), Veraison (Linux Foundation), and keylime (which now has SEV-SNP and TDX backends).

Confidential Kubernetes: Kata and CoCo

Most production workloads do not want to manage CVMs by hand. Fair enough. Two projects bridge confidential computing into Kubernetes:

• Kata Containers with the qemu-tdx or qemu-snp runtime: each pod runs inside its own CVM. Lower overhead than a full VM-per-pod model, and opaque to most workloads.
• Confidential Containers (CoCo): a CNCF project that pairs Kata with the Trustee key broker and an encrypted container image pipeline. Images get pulled, decrypted, and verified inside the CVM — so even a compromised registry or kubelet cannot see the workload code.

Red Hat's April 2026 Developer Preview of confidential clusters for OpenShift on Azure SEV-SNP is the first commercial offering that establishes hardware-rooted trust at the cluster (rather than the pod) level. Worth tracking if you need attestation for an entire control plane.

Operational Hardening Checklist

• Pin TCB versions. Your attestation policy should require a minimum REPORTED_TCB (SEV-SNP) or tee_tcb_svn (TDX). When AMD or Intel publishes a TCB recovery for a vulnerability, treat unpatched hosts as compromised. Full stop.
• Disable debug. The SEV-SNP policy bit DEBUG and TDX ATTRIBUTES.DEBUG must be zero in production. Reject any attestation report that has them set.
• Pre-compute golden measurements. Build the OVMF firmware, kernel, and initrd in a reproducible pipeline and store the expected launch measurement in your broker policy. Without this, you cannot tell a legitimate boot from a tampered one.
• Use vTPM for sealing. SEV-SNP via SVSM and TDX via vTPM-in-TD both expose a standard TPM 2.0 interface. Use it for sealing application keys to PCR state, so secrets become unrecoverable if the boot chain changes.
• Encrypt every disk. The Confidential VM Storage Attack Scenarios paper (Red Hat, May 2026) shows that unencrypted persistent storage on a CVM is a trivial bypass — the hypervisor can just swap blocks underneath you. dm-crypt with integrity (dm-integrity) is mandatory, not optional.
• Disable swap to host disk. Or use encrypted swap with a key released by the same attestation broker.
• Avoid S3/suspend. TDX is destroyed by S3 and deeper power states, and SEV-SNP loses keys too. Disable suspend in systemd: systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target.

Performance Considerations

Recent peer-reviewed measurements (ACM SIGMETRICS 2025) put the overhead of SEV-SNP and TDX in roughly the same range for compute-bound workloads — somewhere between 1 and 5% — with larger penalties on network and storage paths, primarily from bounce buffers (swiotlb) used for unencrypted DMA. Three tuning levers help:

• Use virtio-blk with PCIe pass-through where possible, and size the swiotlb pool generously: swiotlb=262144 on the guest cmdline.
• Enable TDX I/O (TDISP) or SEV-TIO on hardware that supports it, to allow trusted DMA without bounce buffers.
• Pin guest vCPUs to NUMA-local cores. Cross-socket memory access is meaningfully more expensive under TME-MT and RMP enforcement than on plain VMs.

Frequently Asked Questions

Is confidential computing production-ready in 2026?

Yes. AMD SEV-SNP has been generally available on Azure since 2022 and on GCP since 2023; Intel TDX reached GA on Azure and GCP in 2024, and on OCI in 2025. The major caveats are attestation tooling maturity (still evolving — prefer managed services if you can't operate Trustee or Veraison yourself) and CVM disk storage attack surface (always pair with dm-crypt + dm-integrity).

What's the difference between AMD SEV-SNP and Intel TDX?

Both encrypt VM memory and provide integrity protection. SEV-SNP uses a separate AMD Secure Processor (PSP) and a Reverse Map Table to detect host tampering, and attestation reports are signed by a per-chip VCEK. TDX uses a special CPU mode (SEAM) and the TDX Module, and attestation goes through Intel's SGX Quoting Enclave. From a security model perspective they're very similar; operationally, TDX has a slightly more complex attestation pipeline but a unified Linux kernel interface (configfs-tsm).

Which Linux distributions support confidential VMs?

Ubuntu 24.04 LTS supports both as a guest. 25.04 added SEV-SNP host enablement, and 25.10 added TDX host enablement. RHEL 10, SLES 15 SP6, and Fedora 41 all ship sev-guest and tdx_guest modules. For full-stack attestation, Ubuntu 26.04 LTS (April 2026) is the first LTS with TDX attestation fully integrated.

Does confidential computing protect against side-channel attacks?

Only partially. Memory encryption blocks cold-boot and DMA attacks. It does not block timing side channels, cache side channels, or speculative-execution attacks that share microarchitectural state with the host. Both AMD and Intel publish ongoing CVEs for side-channel issues, so track them and pin a minimum TCB version in your attestation policy.

How do I verify an attestation report without trusting the cloud provider?

Fetch the certificate chain directly from the silicon vendor: AMD's Key Distribution Service (kdsintf.amd.com) for SEV-SNP, and Intel's Provisioning Certification Service (api.trustedservices.intel.com) for TDX. The cloud provider only operates the host — the signing keys are rooted in hardware, and the verifier should ignore any cloud-mediated certificate path.

Conclusion

Confidential computing closes the last real gap in the encryption story: the running process itself. For Linux operators in 2026, the practical path is pretty clear. Pick the TEE that matches your cloud SKU. Build reproducible CVM images so you have a stable golden measurement. Wire attestation into your secret release flow with Trustee or Veraison. And require a minimum TCB version in policy.

The hardware is ready, the kernel interfaces are stable, and the cost is small relative to what's being protected. The remaining work is operational discipline — not feasibility.