Key Takeaways
- Four mechanisms, two vendors. Intel TDX encrypts the VM’s memory with a key the host cannot read. The GPU’s confidential computing mode closes its debug paths and keeps its memory behind access controls. The driver and the GPU exchange data encrypted and authenticated, through bounce buffers. Two attestations, Intel’s and NVIDIA’s, let you check the result.
- Shown with our own files. A TDX quote and an NRAS token from an H200 VM, nvidia-smi readings from an RTX PRO 6000 Blackwell VM and an 8x H100 node, and an offline verification we ran again on 27 October 2026.
- It has limits. The host still controls availability and sees encrypted traffic. GPU memory is not encrypted. Sophisticated physical attacks are outside both vendors’ threat models. On 8-GPU Hopper nodes, NVLink is not encrypted, and we have not verified the NVSwitch fabric.
A GPU is confidential only when several mechanisms work together, and they come from two vendors: Intel for the CPU and the VM, NVIDIA for the GPU. This guide takes them in the order your data meet them: the VM’s memory, the GPU, the path between the two, and the proofs. For each one we show what our own Confidential VMs printed, with the file it comes from, and we end with what the host still sees and where the protection stops.
The sources are Intel’s, NVIDIA’s and the Linux kernel’s public documents, linked where they are used. The commands below ran on 27 October 2026 on Ubuntu 24.04 under WSL2, in fresh directories, on files downloaded from this site; their output is pasted as printed.
The files behind this guide
Three published runs, served byte for byte. Each folder has a README that says what its files show and what they do not.
H200, one GPU, 4 September 2026
RTX PRO 6000 Blackwell, one GPU, 9 October 2026
8x H100 node, Protected PCIe, 10 September 2026
Part 1: Intel TDX encrypts the VM’s memory
On Intel CPUs, a confidential VM is a trust domain (TD). A module signed by Intel, the TDX module, runs in a CPU mode of its own, SEAM, and “sits between the host and the guest and manages the guest/host separation” (Linux kernel documentation). The memory of each TD is encrypted with a key the CPU generates: Intel’s TDX white paper describes “a CPU-generated, unique, and ephemeral AES-XTS 128-bit key” for each key ID, programmed so that it is not accessible “by software or by using external interfaces to an SOC.” The same paper describes two integrity modes: a cryptographic one, with a 28-bit SHA-3-based code on each cache line, against software tampering and some hardware-based corruption, and a logical one, a one-bit ownership tag that prevents software access to the TD’s ciphertext. We have not checked which mode our hosts use.
A TD has two kinds of memory. Private memory gets these protections. Shared memory “is expected to be shared between guest and hypervisor and does not receive full TDX protections.” The guest picks, page by page, with a bit in its page tables. All its memory starts private; drivers convert buffers to shared when a device must reach them, and Linux in a TD “uses SWIOTLB for most DMA allocations” (kernel documentation). SWIOTLB is the kernel’s bounce-buffer allocator: in a confidential VM, “the bounce buffer memory is set up as unencrypted,” and the CPU copies data between it and private memory (kernel documentation). TDX does not encrypt what sits in those buffers. For the GPU, the NVIDIA driver encrypts it itself (Part 3); for other devices, such as the network card, protect the data yourself, with TLS for example.
The CPU side proves itself with a TDX quote: a structure signed through Intel’s certificate chain, which carries the measurements of the TD and 64 bytes chosen by whoever asked for it, REPORTDATA. The quote below comes from our single-GPU H200 Confidential VM, on 4 September 2026; the tenant wrote report_data.bin through the kernel’s configfs TSM interface (README).
BASE=https://voltagegpu.com/blog/two-proofs/evidence
D=$(mktemp -d) && cd "$D"
for f in SHA256SUMS quote.bin report_data.bin nras_token.json gpu_report.bin nonce.txt; do curl -fsSO "$BASE/$f"; done
sha256sum -c SHA256SUMS
xxd -l 8 quote.bin
python3 -c 'q=open("quote.bin","rb").read(); r=open("report_data.bin","rb").read(); print(len(q), "bytes; bytes 568-631 equal report_data.bin:", q[568:632] == r)'gpu_report.bin: OK quote.bin: OK report_data.bin: OK nras_token.json: OK nonce.txt: OK 00000000: 0400 0200 8100 0000 ........ 5243 bytes; bytes 568-631 equal report_data.bin: True
The five checksums match the SHA256SUMS published with the files. The first eight bytes are the quote header: version 4 (0400), attestation key type 2 (0200, ECDSA with the P-256 curve in Intel’s quote header definitions) and TEE type 0x81 (8100 0000), which is TDX. Bytes 568 to 631 are REPORTDATA, and they equal report_data.bin byte for byte. Checking the signatures up to Intel’s root is a separate step: Verify an Intel TDX Quote From Any Cloud does it in one command, and Read an Intel TDX Quote, Field by Field explains the other fields.
A quote says nothing about the GPU. In NVIDIA’s words, “CPU evidence alone does not establish the state of the attached GPUs.”
Part 2: the GPU switches to confidential computing mode
NVIDIA Hopper and Blackwell GPUs have three modes. CC-Off is normal operation. In CC-On, “all firewalls are active, and all performance counters have been disabled to prevent their use in side-channel attacks” (NVIDIA, August 2023). CC-DevTools keeps the encryption paths but unblocks the performance counters, for profiling (NVIDIA white paper, version 1.3, August 2025). In CC-On, management paths expose “limited health information,” JTAG is disabled and the performance counters are blocked (NVIDIA threat model).
Inside the GPU, plaintext is protected by access control, not by encryption: “Within GPU memory, hardware access controls protect plaintext data; GPU memory encryption is not the protection mechanism.” NVIDIA’s 2023 post says the same of the HBM, which “is considered secure against everyday physical attack tools and is not encrypted.” Each GPU is assigned whole to one VM.
In NVIDIA’s deployment flow, the host sets the mode with a privileged call before it passes the GPU to the VM (NVIDIA deployment guide); the tenant reads it from inside. Our RTX PRO 6000 Blackwell VM printed this on 9 October 2026 (conf-compute.txt, the output of nvidia-smi conf-compute -q and -gm):
==============NVSMI CONF-COMPUTE LOG==============
CC State : ON
Multi-GPU Mode : None
CPU CC Capabilities : INTEL TDX
GPU CC Capabilities : CC Capable
CC GPUs Ready State : Ready
GPU 0: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-bfc8c5a7-1b18-5fe4-b326-aaaa928b330a)
Protected memory size: 99463296 KiB
Unprotected memory size: 0 KiBCC State ON with Multi-GPU Mode None is the single-GPU CC mode, and CPU CC Capabilities names the CPU side, Intel TDX. The two memory lines are what nvidia-smi calls the “confidential compute GPU protected/unprotected memory sizes”: 99,463,296 KiB protected, none unprotected. The ready state matters too. In NVIDIA’s documented flow, “The GPU doesn’t accept work until a user in the CVM sets the ready state,” with nvidia-smi conf-compute -srs 1 after attestation (Attesting the GPU). The ready state is not evidence; the attestation in Part 4 is.
Eight GPUs: Protected PCIe
Eight-GPU Hopper systems use another mode. Our 8x H100 node read this on 10 September 2026 (node-state.txt, excerpt):
==============NVSMI CONF-COMPUTE LOG==============
CC State : OFF
Multi-GPU Mode : Protected PCIe
CPU CC Capabilities : INTEL TDX
GPU CC Capabilities : CC Capable
CC GPUs Ready State : ReadyCC State OFF is how this mode reports; the Multi-GPU Mode line is the one to read. NVIDIA describes Protected PCIe as encrypting the traffic between the CPU and the GPUs through bounce buffers, “while data traffic between GPUs over NVLINK remains unencrypted,” and the CC and Protected PCIe modes are mutually exclusive for each GPU. On that node, NVIDIA’s service attested all eight GPUs (README). The NVSwitch fabric is not verified; our NVSwitch article has the logs.
Part 3: an encrypted channel through bounce buffers
The first two parts leave a gap. The VM’s data sit in private memory, and the GPU, like any device, “is blocked by the CPU hardware from directly accessing the CVM memory” (NVIDIA, 2023). The NVIDIA driver in the guest and the GPU work around it through shared memory:
- A session. The guest driver “establishes a protected session with each GPU,” over SPDM, and the session keys are ephemeral (threat model; NVIDIA, 2023).
- Encrypted buffers. The driver encrypts the data with AES-GCM and places it in a buffer in shared memory. The GPU’s DMA engines, which “are allowed to access shared memory pages only to retrieve and place data,” fetch it; the GPU checks the authentication tag, decrypts the data and processes it in its protected memory. Results come back the same way (white paper).
- Everything that crosses. Command buffers and CUDA kernels are encrypted and signed too, and Unified Memory pages are encrypted when they migrate (NVIDIA, 2023).
- No replay. Each message uses a new 96-bit initialization vector from a counter that both ends keep, so a captured message sent again fails its authentication check, and keys are replaced before the counter runs out (white paper).
So what the host can read in shared memory is ciphertext: the bounce buffer “contains only encrypted data” (white paper). The cost is the copies and the CPU’s encryption. In 2023 NVIDIA measured the CPU-to-GPU bandwidth at “roughly 4 GBytes/sec,” limited by CPU encryption, with GPU compute and memory bandwidth at par. That figure is NVIDIA’s, for Hopper with the software of the time; we have not measured our VMs.
Code mostly runs as it is: NVIDIA says CUDA applications “should run without any changes” once the system is set up and the GPU attested. We have met one exception, the V2 model runner of vLLM 0.30 on our H100 VM; the workaround is in our vLLM write-up.
For Blackwell, NVIDIA describes a second path without bounce buffers, PCIe TDISP with IDE, when the CPU, firmware and driver support it. PCIe TDISP and Intel TDX Connect explains what changes; our VMs do not use it.
Part 4: two attestations, tied to one challenge
The GPU proves itself with its own attestation. Each H100 carries a device-unique private key “burned into the fuses” (NVIDIA, 2023), whose certificate chains to NVIDIA. During attestation, “the GPU collects and signs measurements, and the verifier compares the measurements to known-good reference measurements” (NVIDIA). NVIDIA’s Remote Attestation Service, NRAS, is that verifier as a web service: it “validates evidence collected from GPUs against trusted reference values and produces cryptographically signed attestation tokens” (NRAS documentation). A local verifier is the other option.
The NRAS token from the same H200 VM, decoded in the same directory as the quote:
python3 - <<'PY'
import base64, json
def part(jwt, i):
p = jwt.split('.')[i]
return json.loads(base64.urlsafe_b64decode(p + '=' * (-len(p) % 4)))
claims = json.load(open('nras_token.json'))[1]['REMOTE_GPU_CLAIMS']
platform, gpu = claims[0][1], claims[1]['GPU-0']
print('alg', part(platform, 0)['alg'])
p = part(platform, 1)
for k in ('iss', 'x-nvidia-overall-att-result', 'eat_nonce', 'iat'):
print(k, p[k])
g = part(gpu, 1)
for k in ('hwmodel', 'x-nvidia-gpu-driver-version', 'x-nvidia-gpu-vbios-version', 'secboot', 'dbgstat', 'measres',
'x-nvidia-gpu-attestation-report-nonce-match', 'x-nvidia-gpu-attestation-report-signature-verified',
'x-nvidia-gpu-attestation-report-cert-chain-validated'):
print(k, g[k])
PYalg ES384 iss https://nras.attestation.nvidia.com x-nvidia-overall-att-result True eat_nonce 6154dbb21ed4bf90d79e4464aa5ea4c2cf4dbc7e1a814a13c0a131c0bb598d05 iat 1788525065 hwmodel GH100 x-nvidia-gpu-driver-version 595.71.05 x-nvidia-gpu-vbios-version 96.00.CF.00.02 secboot True dbgstat disabled measres success x-nvidia-gpu-attestation-report-nonce-match True x-nvidia-gpu-attestation-report-signature-verified True x-nvidia-gpu-attestation-report-cert-chain-validated True
The token is signed with ES384 and issued by https://nras.attestation.nvidia.com. The overall result is true, and iat is 4 September 2026, 12:31:05 UTC. For GPU-0: a GH100 chip, driver 595.71.05, VBIOS 96.00.CF.00.02, secure boot on, debug disabled, measurements matching the reference values (measres success), and the report’s nonce, signature and certificate chain checked. Decoding is not verifying: these claims count because NVIDIA signed them, and you check that signature with NVIDIA’s published keys (the README gives the steps).
These two files came from two separate rounds that day, with different nonces (README), so nothing in them ties this GPU token to that quote. That is the gap NVIDIA’s threat model points to: the tenant’s policy must cover both. Our open-source verifier, voltage-verify, ties them with one challenge. It writes a manifest that holds a random challenge; inside the VM, the SHA-512 of the manifest goes into the quote’s REPORTDATA and its SHA-256 becomes the NVIDIA nonce. The RTX PRO 6000 Blackwell bundle of 9 October 2026, checked again offline:
V=$(mktemp -d) && python3 -m venv "$V" && "$V/bin/pip" install -q voltage-verify && export PATH="$V/bin:$PATH" BASE=https://voltagegpu.com/blog/two-proofs/evidence/rtx6000b-2026-10-09 D=$(mktemp -d) && cd "$D" && for f in SHA256SUMS manifest.json bundle.json conf-compute.txt gpu.txt kernel.txt; do curl -fsSO "$BASE/$f"; done && sha256sum -c SHA256SUMS voltage-verify --version voltage-verify verify bundle.json --offline --challenge 627ba9c51d4719038e917c7431675b183ac576c819d712178dc8a100f4409a45 --hwmodel GB20X --gpus 1
manifest.json: OK bundle.json: OK conf-compute.txt: OK gpu.txt: OK kernel.txt: OK voltage-verify 0.2.3 [PASS] manifest.format manifest is well formed [PASS] manifest.commitments bundle commitments match the manifest [PASS] manifest.challenge challenge is the one this verifier issued [PASS] tdx.structure TDX quote v4, TEE 0x81, 4940 bytes [PASS] tdx.debug TD attributes 0000001000000000 (0x10000000), DEBUG (bit 0) off: not a debug TD [PASS] tdx.report_data quote report_data equals SHA-512 of the manifest [PASS] tdx.signatures attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA [PASS] tdx.collateral TCB info and QE identity signed by Intel (bundle (fetched 2026-10-09T21:54:01+00:00)) [PASS] tdx.tcb platform TCB UpToDate, QE UpToDate, TDX_03 UpToDate [PASS] tdx.revocation PCK certificate not revoked (57 entries in CRL) [PASS] tdx.revocation PCK CA certificate not revoked (0 entries in CRL) [PASS] nvidia.signatures 2 NVIDIA-signed tokens verify, keys from the bundle chained to a pinned NRAS intermediate (offline) [PASS] nvidia.nonce NRAS eat_nonce equals SHA-256 of the manifest [PASS] nvidia.policy overall result true, every GPU: measurements ok, secure boot on, debug off, nonce matched, report signature and chain validated [PASS] nvidia.freshness token issued 0s from bundle creation TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d... TCB UpToDate QE UpToDate GPU: GPU-0 GB20X driver 595.71.05 vbios 98.02.9E.00.01 measurements success RESULT: VERIFIED
The tdx lines check Intel’s side, with the Intel collateral stored in the bundle on 9 October: structure, debug bit off, REPORTDATA equal to the SHA-512 of the manifest, signatures up to the pinned Intel root, TCB UpToDate, nothing revoked. The nvidia lines check NVIDIA’s side: two NVIDIA-signed tokens, chained to a pinned NRAS intermediate, an eat_nonce equal to the SHA-256 of the same manifest, and the policy for each GPU. On 9 October, the same bundle checked against a wrong challenge failed (verify-wrong-challenge.txt). The verify.txt published on 9 October came from version 0.2.1; version 0.2.3 gives the same results and adds the tdx.debug line.
Both proofs commit to one manifest built on your challenge, so both were made after you chose it, for this run. The binding does not show by itself that the attested GPU is the one wired to that TD: the software in the guest that collected both, the attestation tool and the NVIDIA driver, is part of what you trust, and NVIDIA lists the guest driver and the workload in the trusted computing base.
What the host sees, and what it does not
| Path | What the host gets | Source |
|---|---|---|
| The VM’s private memory | No plaintext: encrypted with the TD’s key, integrity-protected | Intel TDX white paper |
| Shared memory and bounce buffers | Readable, but only ciphertext; changed or replayed messages fail authentication | NVIDIA white paper |
| GPU memory and GPU state | Blocked by the GPU’s access controls; health information only, JTAG off, counters off in CC-On | NVIDIA threat model |
| The GPU mode | Set by the host in NVIDIA’s flow; you read it in nvidia-smi and a verifier checks it in the attestation | NVIDIA deployment guide and threat model |
| The VM’s life cycle | Full control: it can stop the VM, cut the network, detach devices, cut the power | NVIDIA threat model, Intel TDX white paper |
| Network traffic and disk | Outside these mechanisms: encrypt them yourself | NVIDIA threat model |
Where the protection stops
- Physical attacks. Intel’s white paper says TDX defends against “limited forms of attacks that use physical access,” such as cold-boot attacks, and “does not defend against replay of memory through physical attacks.” NVIDIA puts “invasive package probing and fault injection” outside its GPU threat model. In September 2026 the DDRop research showed a physical attack on TDX; our article on DDRop says what it changes for a tenant.
- Side channels. CPU side-channel coverage “follows the CPU vendor’s model” (NVIDIA). On the GPU, CC-On blocks the performance counters; a production policy must refuse CC-DevTools, which unblocks them.
- The software in your VM. Your guest kernel, the NVIDIA driver, CUDA, your code and anyone with access inside the guest are in the trusted computing base. In NVIDIA’s words, attestation does not establish that the approved code has no vulnerabilities.
- Eight-GPU Hopper nodes. NVLink traffic is not encrypted in Protected PCIe mode, so the fabric and physical access belong in your assessment (NVIDIA), and we have not verified the NVSwitch fabric.
- One whole GPU per VM. MIG, MPS and GPUDirect RDMA “are not supported in the CC configurations” NVIDIA describes.
- The verifier. NRAS is an NVIDIA web service, and NVIDIA “will collect IP addresses and information about your GPU, including the device’s unique identity” (NRAS documentation). NVIDIA offers local verification for air-gapped cases, and warns that revocation data held locally can be stale.
- Firmware versions. “A valid signature alone does not establish that a firmware version is acceptable” (NVIDIA): your policy has to reject the versions you do not accept.
What this guide shows, and what it does not
Shown:
- From the H200 files of 4 September 2026: a TDX v4 quote that carries the tenant’s 64 bytes, and an NRAS token stating that GPU-0, a GH100, passed with secure boot on and debug off. Here we decoded the token; we did not check its signature.
- From the RTX PRO 6000 Blackwell bundle of 9 October 2026: both proofs bound to one manifest, verified offline again on 27 October 2026 with voltage-verify 0.2.3, and nvidia-smi reading the single-GPU CC mode.
- From the 8x H100 node of 10 September 2026: the Protected PCIe reading.
Not shown:
- The state of a VM you rent today. Generate the proofs in it (Confidential VM guide) and check them on your machine (tutorial).
- That the text files are unedited. The quote and the NRAS tokens are signed; conf-compute.txt, node-state.txt and the READMEs are text printed by the VM or written by us.
- That the attested GPU is the one wired to the TD. See Part 4.
- Anything about your workload, your disk or your network traffic.
- The physical security of the machines, the NVSwitch fabric, or B200 and B300 GPUs, which we have not verified.
- A performance figure of ours. The only number here is NVIDIA’s, from 2023.
Confidential VMs at VoltageGPU
Our Confidential VMs are Intel TDX guests with NVIDIA GPUs passed through, billed per second. NVIDIA attestation run from inside the VM, by tier: single-GPU H200 (4 September 2026), H100 (16 September 2026) and RTX PRO 6000 Blackwell (17 September and 9 October 2026, then the weekly run shown on /proofs); the 8x H100 node in Protected PCIe mode (10 September 2026: eight GPUs attested, NVSwitch fabric not verified). The 8x H200 node reads the same mode, but its attestation has not been run. Stock and prices are live on Confidential Compute, and the commands to generate both proofs in your VM are in the Confidential VM guide.