Survey and test cloud provider / machine-type combinations for TDX validator support

[0xHansLee]

Description and context

Today our TEE validator path only supports Intel SGX. We are adding Intel TDX as a second backend. Unlike SGX, TDX support cannot be enabled with a single code measurement — the platform identity is part of the measured boot and it varies per cloud provider and machine type. The TDXValidationHook gates each validator on two commitments:

• Binary commitment (matched against DKG.codeCommitment): keccak256(RTMR3). The kernel self-extends RTMR3 exactly once during TD bootstrap with SHA-384 of its own ELF, so this register reflects our Go binary and is independent of the cloud provider.
• Platform commitment (enforced via the approvedPlatforms whitelist): keccak256(MRTD || RTMR0 || RTMR1 || RTMR2), where
  • MRTD + RTMR0 pin the cloud SKU / TDVF (virtual firmware),
  • RTMR1 pins the boot chain (OVMF + bootloader),
  • RTMR2 pins the TD initrd + kernel cmdline (our boot image).

The problem: the platform commitment is a function of the host firmware / TD module / virtual firmware shipped by each cloud and our boot image, and the MRTD/RTMR0/RTMR1 halves differ across providers, machine types, and firmware vintages (I have already observed that RTMR1 is a function of firmware vintage, so two instances of the same SKU can diverge). We cannot blindly support "any TDX VM" — we must empirically discover which (provider, machine type) combinations produce a stable, reproducible platform commitment, then enroll exactly those via approvePlatform(bytes32 platformCommitment, label).

This task is to survey which cloud providers and machine types offer Intel TDX with DCAP attestation, measure their platform commitments, verify stability, and determine which combinations we can register as approved platforms in the TDXValidationHook.

Candidate providers / machine types to investigate

• GCP — C3 confidential VMs with Intel TDX (baseline reference).
• Alibaba Cloud — g8i / TDX-enabled confidential instances.
• Oracle Cloud (OCI), IBM Cloud, OVHcloud, and any bare-metal providers (e.g. Equinix Metal) exposing raw TDX-capable hardware.

Hard gating criterion: our only quote-acquisition path (direct vendor) uses the upstream Linux configfs-tsm guest interface (kernel ≥ 6.7), which requires a non-paravisor (bare) TDX guest. A provider is a candidate only if it exposes this interface.

Explicitly out of scope

• Azure — Confidential VM TDX (DCesv5/v6, ECesv6, …) is paravisor-mediated (OpenHCL). The upstream Linux TDX driver rejects these hosts ("Invalid offer 3"; configfs-tsm returns ENXIO), so the direct vendor cannot acquire a raw quote / inject REPORT_DATA there. Supporting Azure would require a separate paravisor/vTPM vendor adapter — out of scope for this task.
• AWS — Intel TDX not offered (Nitro Enclaves / AMD SEV-SNP only). Document the gap; no testing.

Key questions per (provider, machine type)

1. Is Intel TDX available (region, SKU, GA vs preview), and is it provisionable self-service?
2. Does the platform support DCAP quote generation + TCB info (PCCS), so our on-chain Automata DCAP verifier can validate the quote?
3. What are the measured MRTD, RTMR0, RTMR1, RTMR2 values, and therefore the derived platform commitment keccak256(MRTD||RTMR0||RTMR1||RTMR2)?
4. Is the platform commitment stable across multiple fresh instances of the same machine type (including snapshot/relaunch and across firmware updates)? Since MRTD/RTMR0/RTMR1 are provider-controlled, this decides whether one approvedPlatform entry covers the SKU or whether firmware-vintage drift forces multiple entries / re-enrollment.
5. Confirm RTMR2 (initrd + cmdline) is reproducible from our boot image build across providers, and RTMR3 (binary) matches DKG.codeCommitment.
6. Cost and minimum instance shape.

Suggested solution

1. Build a matrix of (provider × machine type) → availability / self-service / DCAP support / measured MRTD,RTMR0,RTMR1,RTMR2 / platform commitment / stability.
2. For each TDX+DCAP-capable combination:
   • boot the TDX validator binary,
   • generate a TDX quote and verify it against the on-chain Automata DCAP verifier contracts,
   • extract and record the platform commitment (keccak256(MRTD||RTMR0||RTMR1||RTMR2)) and confirm keccak256(RTMR3) == DKG.codeCommitment,
   • launch ≥2 independent instances (and a snapshot relaunch) to confirm the platform commitment is reproducible.
3. For combinations with a stable platform commitment, document the exact approvedPlatform value to enroll via TDXValidationHook.approvePlatform(...), with a human-readable label.
4. Flag combinations where RTMR1/firmware-vintage drift makes the platform commitment non-stable (i.e. unsuitable for a single approved-platform entry, or requiring an operational re-enrollment policy).
5. Recommend an initial supported set (primary + fallback) for validator operators.

Definition of done

• Provider × machine-type matrix committed (availability, self-service, DCAP, MRTD/RTMR0/RTMR1/RTMR2 measurements, platform commitment, stability).
• For each supportable combination: documented quote generation + on-chain DCAP verification result, the captured platform commitment, and a verified keccak256(RTMR3) == DKG.codeCommitment.
• Platform-commitment stability verified with ≥2 fresh instances (+ snapshot relaunch) per candidate machine type, with firmware-vintage / RTMR1 drift caveats noted.
• Concrete list of approvedPlatform values (with labels) ready to enroll via TDXValidationHook.approvePlatform, per supported (provider, machine type).
• AWS (and any other no-TDX provider) gap explicitly documented.
• Recommended initial supported provider/machine-type set for operators.