I let my tenants generate their own Intel TDX quotes. Here is the exact walkthrough

I spent most of last Tuesday SSHed into one of our VMs because a customer asked a question I could not answer without squirming: "If we rent a confidential VM from you, can we prove it is a real Intel TDX trust domain ourselves, or do we have to take your word for it?"

The honest answer, at the time, was that they had to take our word for it. We had attestation, but it ran through our API. We generated the quote, we served the quote, we told you it was fine. That is how most confidential clouds work, and it is quietly absurd. The whole premise of confidential computing is that the tenant does not want to trust the provider. Handing that tenant a provider-generated attestation misses the point of the exercise.

So we flipped it. On the VM tier at VoltageGPU, /dev/tdx_guest is now exposed to you as the tenant, with full root over SSH, and quote generation goes through a bone-stock Linux kernel interface. No vendor SDK, no API of ours in the loop. I verified the full flow end to end on a live VM on September 3, 2026, and what follows is the exact walkthrough, byte counts included.

The part I actually want to teach you is the kernel interface, because it works identically on any TDX guest with a recent kernel, whoever you rent it from. Most people have never seen it because most clouds never let them near it.

The configfs TSM interface, in one paragraph

Since roughly kernel 6.7, Linux ships a vendor-neutral attestation ABI called TSM reports. It lives in configfs at /sys/kernel/config/tsm/report/ and wraps the platform-specific quote machinery (Intel TDX today, AMD SEV-SNP through the same interface) behind three filesystem operations. You mkdir a report entry, write your challenge into a file called inblob, and read a signed quote back out of a file called outblob. No ioctls, no C code, no SDK. If you can drive dd and cat, you can do hardware attestation.

Step 1: prove you are actually inside a TDX guest

First, convince yourself you are in a TDX trust domain and not a plain VM wearing a marketing label. The device node and the two kernel modules are the tell.

# SSH straight into your Confidential VM (Ubuntu 24.04, kernel 6.8)
ssh ubuntu@<your-vm-ip>

# 1. The TDX guest device is present INSIDE the VM
ls -l /dev/tdx_guest

# 2. The attestation kernel modules are loaded
lsmod | grep -E "tdx_guest|tsm"
# both tdx_guest and tsm should be listed

# 3. You have full root
sudo -v && echo "root access: confirmed"

# 4. The GPU is visible from inside the VM
nvidia-smi -L

If /dev/tdx_guest is missing, you are not in a TDX guest, full stop. This is the check that most "confidential" offerings fail from the tenant's seat, because the attestation device is only available to the host operator, never to you.

Step 2: generate a quote with your own report_data

A TDX quote embeds 64 bytes of caller-chosen data called report_data, and this one field is what makes tenant-side attestation worth anything. A quote with empty or vendor-chosen report_data could have been generated last month on some other machine. A quote embedding a value derived from a nonce you generated seconds ago can only have been produced inside a real TDX guest, after your challenge existed. It kills replay dead.

A clean pattern for the 64 bytes: sha512 of a fresh nonce plus a human-readable statement.

# 1. Create a TSM report entry via configfs (kernel 6.8+, tsm module)
sudo mkdir /sys/kernel/config/tsm/report/r1

# 2. Build 64 bytes of report_data that YOU control.
NONCE=$(openssl rand -hex 16)
printf '%s' "audit-$(date -I)-$NONCE" \
  | sha512sum | cut -d' ' -f1 | xxd -r -p > report_data.bin
wc -c report_data.bin
# 64

# 3. Write your report_data into the report's inblob
sudo dd if=report_data.bin \
  of=/sys/kernel/config/tsm/report/r1/inblob bs=64 count=1

# 4. Read the signed quote back out
sudo cat /sys/kernel/config/tsm/report/r1/outblob > quote.bin
wc -c quote.bin
# 5247

On my VM the quote came back at exactly 5247 bytes. That is a TDX v4 quote: a header, the TD report body carrying the measurements and your report_data, then the ECDSA signature and the certification data that chains it to Intel.

Step 3: sanity-check the header

Before real verification, read the first bytes. The header identifies the format version, the attestation key type, and the TEE type, exactly as Intel's public quote format specifies.

# First 6 bytes of the quote header
xxd -l 6 quote.bin
# 00000000: 0400 0200 8100                           ......

# 04 00 : quote format version 4 (little-endian)
# 02 00 : attestation key type, ECDSA-P256
# 81 00 : TEE type field, 0x81 identifies Intel TDX

Step 4: confirm your bytes are actually in there

The quote must contain the exact 64 bytes you wrote into inblob. If it does not, someone handed you a canned quote. One line settles it.

# Your exact 64 bytes must appear inside the signed quote body
xxd -p quote.bin | tr -d '\n' \
  | grep -c "$(xxd -p report_data.bin | tr -d '\n')"
# 1

Step 5: verify offline, against Intel, not against us

A quote you cannot verify is just a binary blob. Pull it off the VM and verify it on your own hardware with Intel's open-source DCAP primitives.

# On YOUR machine, never on ours. Pull the quote off the VM first.
scp ubuntu@<your-vm-ip>:quote.bin .

# Verify offline with Intel's open-source DCAP primitives:
# https://github.com/intel/SGXDataCenterAttestationPrimitives
# The QuoteVerification sample validates the ECDSA signature and
# walks the PCK certificate chain up to the Intel SGX Root CA.
#
# Collateral (PCK certs, TCB info, QE identity) comes from the
# Intel PCS or a cached PCCS mirror, not from your provider.

If verification passes, you have cryptographic proof that the quote was signed by a genuine Intel platform, that the VM is a real TDX trust domain, and that the report_data inside is the exact nonce you generated. Our infrastructure produced the environment, but the evidence chain runs from a device node inside your VM straight to Intel's root CA, and never through us. That is the property this whole post hinges on.

The honest limits

Attestation write-ups that skip the limits are part of the problem, so here are ours, stated plainly. The quote attests the CPU TEE boundary only. GPU confidential computing mode is currently off on these VMs, so do not let anyone, us included, wave a TDX quote at you and call it GPU attestation. Second, container tiers generally do not expose /dev/tdx_guest inside your workload, ours included; the CPU attestation exists at the infrastructure level there, but you cannot generate a tenant quote with custom report_data from inside a container. If you need what this post describes, you need a full VM. Third, our VM tier has no persistent volumes and no self-serve deploy UI yet. VMs are provisioned by email while the UI gets built, so treat the disk as ephemeral and copy your quotes off the box.

Why this is worth an afternoon

Because the interface is just files, it scripts trivially. A cron job that generates a nonce-bound quote per batch run and archives it next to the output hash is about ten lines of shell. And because report_data is yours, you can bind application data into the evidence: put the hash of a model output or a signed document into a fresh quote, and the hardware signs a statement that this exact result was known inside this exact trust domain at this exact moment. For an auditor working through GDPR Article 32 or a similar review, evidence you generated yourself inside the enclave beats a vendor PDF every single time. The auditor can SSH in and run the five commands personally.

The longer version, with an FAQ, lives on our blog: tenant TDX attestation guide. If you want a VM to try it on, the details are on the confidential compute page.

Don't trust us. Verify.