Verifying Intel TDX and NVIDIA GPU attestation from inside a rented VM, and what it can't prove

I run a small confidential GPU cloud. We rent Intel TDX virtual machines with an H100, H200 or RTX PRO 6000 Blackwell passed through, and customers kept asking the only question that matters: how do I know the enclave is real, and that the provider is not in the loop?

"Trust our dashboard" is not an answer to that question. So I wrote a verifier the tenant runs themselves, with nothing from us in the trust chain. It's open source: voltage-verify.

The workflow

On your laptop, write a manifest with a fresh challenge:

voltage-verify manifest --image ghcr.io/you/app:1.4.2 --artifact model.safetensors \
    --statement "inference run for customer X" -o manifest.json

Copy it into the VM, then as root inside the VM:

sudo -E python -m voltage_verify attest --manifest manifest.json -o bundle.json

Copy the bundle back and verify it anywhere, offline if you like:

voltage-verify verify bundle.json --challenge <the challenge printed by manifest>
voltage-verify verify bundle.json --offline

Exit code 0 means verified, 1 means a required check failed.

How the two proofs are bound together

1. The manifest carries a random challenge.
2. Inside the VM, the tool asks the kernel's TDX interface (configfs TSM, /sys/kernel/config/tsm/report) for a quote whose report_data is the SHA-512 of that manifest. The quote is verified up to the pinned Intel SGX Root CA, with Intel's PCS collateral (TCB info, QE identity, CRLs) embedded in the bundle so it also verifies offline.
3. It asks NVIDIA's Remote Attestation Service for GPU tokens whose nonce is the SHA-256 of the same manifest, and checks measurements, secure boot, debug off, signature and certificate chain.

Both proofs answer the same challenge, so a bundle can't be replayed from another machine or another day. Neither path goes through our API: it's the Linux kernel and NVIDIA's own service. The same commands should work on any TDX host with a GPU in confidential mode, though we haven't tried every cloud.

Published bundles anyone can re-verify, a single H200, a single H100, an 8x H100 node and an RTX PRO 6000 Blackwell, plus a weekly run, are listed here: https://voltagegpu.com/api/attestation/evidence

What it does not prove

Our VMs boot a stock Ubuntu image and the tenant gets root. So this attests the hardware and the enclave, not which application runs inside. If someone with root on the VM wants to put a different hash in report_data, they can.

Proving workload identity to a third party would need a customer-supplied measured image (your own kernel, initramfs and a dm-verity root, no SSH), so the measurements cover the whole workload. We don't offer that today. I'd rather say it here than have someone discover it in production.

Two things I learned the hard way

NVSwitch doesn't verify from inside the guest. On 8-GPU HGX nodes the GPUs run in NVIDIA's multi-GPU "Protected PCIe" mode, and all eight attest fine. The NVSwitch fabric is another story. With the right libnvidia-nscq (unsuffixed, pinned to the driver version) the NSCQ session opens and switch evidence is collected, but it then fails certificate-chain validation because ocsp.ndis.nvidia.com is unreachable over TLS from the guest. So a tenant VM can't prove the NVLink fabric today. Raw logs: nscq-retest-2026-09-19.

"Random" attestation failures are often egress. The same OCSP problem makes nvattest's local check fail intermittently inside a CVM, while the remote path through NRAS succeeds, because NVIDIA runs the revocation checks on its side. If your GPU attestation fails one run in three, look at the guest's outbound network before you look at the GPU.

Try it

pip install "voltage-verify[attest]"

MIT, Python 3.10+. The repo has example bundles you can verify right away without renting anything. If you go into the TDX quote format or the NRAS token claims and something looks off, tell me in the comments, I'd rather fix it than defend it.