Generate Your Own Intel TDX Quote as a Tenant: Hands-On Guide (2026)

Every confidential cloud says some version of the same sentence: “your workload runs in a hardware enclave.” Almost none of them let you check. The attestation, if you get one at all, is generated by the provider, on the provider’s schedule, through the provider’s API. You are trusting the party you were trying not to trust.

As of this week, VoltageGPU’s Confidential VM tier works the other way around. You SSH into your VM, you find /dev/tdx_guest waiting for you, and you generate your own Intel TDX quote with your own 64-byte challenge, using nothing but the Linux kernel’s standard TSM interface. Then you verify that quote against Intel’s root of trust, offline, on your own machine. We verified this end to end on a live VM on September 3, 2026, and this article is the exact walkthrough.

This is the companion to our earlier remote attestation guide, which covered pulling quotes through our API. The difference here: no VoltageGPU API in the loop at all. Don’t trust us. Verify.

What the Confidential VM tier gives you

• A full Ubuntu 24.04 VM (kernel 6.8) running as an Intel TDX Trust Domain.
• Direct SSH access with complete root via sudo.
• /dev/tdx_guest present inside the VM, with the tdx_guest and tsm kernel modules loaded.
• The GPU attached and visible inside the VM.
• The kernel’s configfs TSM report interface, which is what we use below to generate quotes as a tenant.

Step 1: confirm the TDX guest environment

First, prove to yourself that you are actually inside a TDX guest and not a plain VM with 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, not to you.

Step 2: generate a quote with your own report_data

The kernel exposes attestation through configfs at /sys/kernel/config/tsm/report/. You create a directory, write your challenge into inblob, and read the signed quote from outblob. The 64 bytes of report_data are yours to choose. That single fact is what makes the quote replay-proof: nobody could have produced it before your nonce existed.

# 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.
#    A clean pattern: sha512 of a fresh nonce plus a statement.
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 our test VM the quote came back at exactly 5247 bytes. That is a TDX v4 quote: header, 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: read the header

Before doing any real verification, sanity-check the first bytes. The quote 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 report_data is embedded

The quote must contain the exact 64 bytes you wrote into inblob. If it does not, someone handed you a canned quote. One line of shell 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’s roots

A quote you cannot verify is a binary blob. The verification step uses Intel’s open-source DCAP libraries and Intel-published collateral, which means the entire trust decision runs on your hardware against Intel’s PKI. We did exactly this with the quote above: parsed, signature-checked, and chained to the Intel root, with VoltageGPU having no role in the process.

# 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 VoltageGPU.

# If verification passes, you have cryptographic proof that:
#  - the quote was signed by a genuine Intel platform
#  - the VM is a real TDX Trust Domain
#  - the report_data inside is the exact nonce YOU generated

This is the property the whole article hinges on. Our infrastructure produced the environment, but the evidence chain runs from a device node inside your VM to Intel’s root CA, and never through us.

What tenant-generated quotes unlock

• Audit evidence you produced yourself. For CSRD, GDPR Article 32, or a notified-body review, evidence generated by the auditee’s own tooling inside the enclave beats a vendor PDF every time. The auditor can even SSH in and run the five commands personally.
• Regulated workloads with a paper trail. Legal, healthcare, and finance teams can attach a fresh nonce-bound quote to each processing session and archive it next to the logs.
• Application-level attestation chains. Because report_data is yours, you can put a hash of your computation result (a model output, a signed document, a batch artifact) into a fresh quote. The hardware then signs a statement that this exact result was known inside this exact Trust Domain at this exact point.

The honest limits

Three things this does not give you today, stated plainly because attestation articles that skip the limits are part of the problem:

• The container tier does not expose /dev/tdx_guest. On standard confidential containers, CPU attestation exists at the infrastructure level only. You cannot generate a tenant quote with custom report_data from inside a container. If you need what this article describes, you need the VM tier.
• The TDX quote never covers the GPU. It attests the CPU TEE boundary. On single-GPU H200 VMs, GPU confidential-computing mode is ON (verified September 4, 2026, NVIDIA remote attestation successful) and the GPU has its own nonce-bound attestation report. The 8x H200 node, RTX 6000B VMs and the container tier all read CC State OFF. Do not represent a TDX quote as GPU-side attestation.
• No persistent volumes on the VM tier yet. Deploying and releasing are self-serve from the dashboard, but the disk is ephemeral: copy your quotes and artifacts off the box before you release it.

Related reading

• Remote attestation through the API: pull, verify, bind your model
• What Intel TDX actually does: the deep-dive
• Intel TDX vs AMD SEV-SNP for confidential AI: the comparison
• GDPR and AI: why a DPA is not enough
• Two proofs: adding the NVIDIA H200 GPU attestation to this TDX quote, tenant-side, with the raw files from 4 September 2026 to download.
• Two pitfalls found by tenants on this exact procedure: concurrent quotes fail with EINVAL (serialise, retry on EINVAL only) and two GPU reports are never byte-identical (pin the verified claims, not a hash of the blob).

FAQ