Confidential VMs & Tenant Attestation
A full virtual machine running as an Intel TDX Trust Domain, with root access and a GPU attached. You generate your own attestation quote from inside the VM and verify it offline against Intel's root CA. VoltageGPU is not in the trust path.
VM Tier vs Container Tier
The confidential container tier gives you a hardware-sealed container inside an Intel TDX enclave: your workload is protected, but attestation happens at the infrastructure level and the container does not expose /dev/tdx_guest. You have to trust the platform's attestation reports.
The Confidential VM tier removes that trust requirement. You get a full Ubuntu VM that itself runs as a TDX Trust Domain, with the TDX guest device exposed inside the VM. You generate the signed quote yourself, bind it to your own nonce, and verify the signature chain offline with Intel's open-source tooling. Nothing in the verification path is operated by VoltageGPU.
| Capability | Confidential Containers | Confidential VMs |
|---|---|---|
/dev/tdx_guest exposed | No | Yes |
| Attestation | Infrastructure-level | Tenant-generated TDX quote |
| Access level | Container root | Full VM root via sudo |
| Provisioning | Self-serve (API, dashboard, CLI) | On request via email |
| Persistent volumes | Available | Not yet, disk is ephemeral |
What You Get Inside the VM
Ubuntu 24.04 LTS
Ubuntu 24.04 LTS with kernel 6.8, running as an Intel TDX Trust Domain. Full root via sudo and direct SSH access, install anything you need.
GPU Attached
The GPU is attached to the VM and visible from inside it: nvidia-smi works out of the box for your training and inference workloads.
TDX Guest Interface
The VM exposes /dev/tdx_guest plus the tdx_guest and tsm kernel modules, everything you need to generate signed quotes via configfs TSM.
Request a Confidential VM
Provisioning is currently on request: there is no self-serve deploy UI for the VM tier yet. Email us and we set the VM up for you.
We Provision
We provision the VM as an Intel TDX Trust Domain on our infrastructure and reply with your SSH connection details.
SSH In
Connect with your key, verify the TDX environment, and run your workload. You have full root via sudo.
No deploy UI yet. The VM tier is provisioned manually while we build out self-serve deployment. Container-tier pods remain fully self-serve.
Verify the Environment
Once you are in, confirm you are actually inside a TDX guest: the TDX guest device must exist, the kernel modules must be loaded, and the GPU must be visible.
$ ls -l /dev/tdx_guest crw------- 1 root root 10, 127 ... /dev/tdx_guest
$ lsmod | grep -E 'tdx_guest|tsm' tdx_guest ... tsm ...
$ nvidia-smi
Generate a TDX Quote
Step 1: Create a Report Entry
Quotes are generated through the kernel's configfs TSM interface. Creating a directory under /sys/kernel/config/tsm/report opens a new report request.
sudo mkdir /sys/kernel/config/tsm/report/r1
Step 2: Write Custom report_data
Write exactly 64 bytes of custom report_data into inblob. Binding a hash of a fresh nonce is the standard way to prove the quote was generated now, for you, and is not a replay. SHA-512 output is exactly 64 bytes, so it fits inblob perfectly.
head -c 32 /dev/urandom > nonce.bin openssl dgst -sha512 -binary nonce.bin | \ sudo tee /sys/kernel/config/tsm/report/r1/inblob > /dev/null
Keep the nonce. The verifier needs nonce.bin later to confirm the quote embeds the SHA-512 of that exact nonce in its report_data field.
Step 3: Read the Signed Quote
Reading outblob triggers quote generation inside the Trust Domain and returns the signed quote. On this tier the output is a TDX quote v4 of 5247 bytes.
sudo cat /sys/kernel/config/tsm/report/r1/outblob > quote.bin ls -l quote.bin # 5247 bytes
Step 4: Sanity-Check the Header
Before running full verification, eyeball the first header bytes. A valid quote from this tier starts with 04 00 02 00 81 00.
$ xxd -l 6 quote.bin 00000000: 0400 0200 8100 ......
Header Fields
04 00 | bytes 0-1 | Quote format version 4 |
02 00 | bytes 2-3 | Attestation key type: ECDSA-P256 |
81 00 ... | bytes 4-7 | TEE type 0x81: Intel TDX |
Verify Offline with Intel DCAP
Verification is fully offline and uses Intel's open-source DCAP stack (SGXDataCenterAttestationPrimitives). The quote's ECDSA signature chains through the platform's PCK certificate up to Intel's root CA. VoltageGPU operates nothing in that chain: if the quote verifies, the guarantee comes from Intel silicon, not from us.
git clone https://github.com/intel/SGXDataCenterAttestationPrimitives # Build the Quote Verification Library (QVL) sample and run it # against quote.bin. It validates the signature chain up to the # Intel root CA, entirely offline.
Check report_data Freshness
A valid signature is not enough: also confirm the quote embeds your report_data. Recompute sha512(nonce.bin) and compare it with the 64-byte report_data field inside the quote body. A match proves the quote was generated after you wrote your nonce, inside that specific Trust Domain.
Full walkthrough. The complete step-by-step guide, including the exact DCAP build commands and the report_data offset inside the quote body, is published at voltagegpu.com/blog/tenant-tdx-attestation-guide.
Honest Limits
Confidential computing claims are only worth something when the boundaries are stated plainly. Here is exactly what this tier does and does not attest.
The container tier has no tenant attestation
Confidential container pods do not expose /dev/tdx_guest. On that tier, attestation is infrastructure-level only: you cannot generate your own quote from inside a container. If tenant-side attestation is a requirement, use the VM tier documented on this page.
The quote attests the CPU TEE boundary, not the GPU
GPU Confidential Computing state is OFF on this tier. The TDX quote attests the CPU Trust Domain boundary: VM memory is protected from the host, but the GPU itself is not part of the attested enclave. We never claim GPU attestation, and neither should you when building on this tier.
No persistent volumes, no deploy UI
The VM disk is ephemeral: when the VM is released, the disk is gone. Persistent volumes are not available on the VM tier yet, so copy models, checkpoints, and results off the box (e.g. via scp or rsync) before tearing it down. Provisioning is manual via email, there is no self-serve deploy UI yet.