NVSwitch Is Not Attestable From Inside a TDX Guest: What We Found on an 8x H100 Node, With Logs

This is the third article in a series where we run the attestation checks on our own fleet and publish what comes out, including when it comes out wrong. The first one showed the two proofs a tenant can generate on a single H200 VM. The second replayed them through the API alone. This one is about the thing an eight-GPU node has that a single-GPU VM does not: the NVLink fabric, and whether the tenant can verify it.

Why we tried

On 10 September 2026 we attested an 8x H100 node from inside the TDX guest with NVIDIA’s Python SDK. The node runs in Protected PCIe mode, the multi-GPU confidential mode where nvidia-smi reads “CC State OFF” and “Multi-GPU Mode Protected PCIe”. With ppcie_mode=False the SDK returned one NVIDIA-signed token per GPU, eight in total, each “Attestation Successful” on our nonce. The switch evidence, however, was rejected by the SDK before it reached NVIDIA:

# Same node type, 10 September 2026, Python SDK nv-attestation-sdk
# GPUs: ppcie_mode=False, one NRAS token per GPU, eight tokens, all "Attestation Successful"
# Switches: the SDK rejects the switch evidence before it reaches NVIDIA
errorCode 4005 INVALID_EVIDENCE

Our infrastructure operator told us that the official CLI, nvattest attest --device nvswitch, works on their 8x H200 nodes, same Hopper HGX generation, four LS10 switches per node. That was worth testing from the tenant side rather than taking on trust, because the tenant side is the only side that counts for the claim we sell. So on 16 September we rented the node type again, twelve minutes, three dollars of compute.

What we ran, and what came back

The image (ubuntu-24-04-lts-595) ships nvattest 1.2.0 but not libnvidia-nscq, the library the tool uses to talk to the switches. We installed it by hand, version 615.71.09. The failure then moved exactly one layer down and stopped:

# Inside the TDX guest, 8x H100 node (h100-xlarge), 16 September 2026
# nvattest 1.2.0, driver 595.71.05, libnvidia-nscq 615.71.09 installed by hand

$ lspci -nn | grep -c 22a3          # the four LS10 NVSwitches are on the bus
4
$ ls /dev/nvidia-nvswitch*
/dev/nvidia-nvswitch0  /dev/nvidia-nvswitch1  /dev/nvidia-nvswitch2  /dev/nvidia-nvswitch3

$ sudo nvattest attest --device nvswitch
[switch/nscq_client.cpp:195] Failed to create NSCQ session: NSCQ_RC_WARNING: RDT init failure (Code 1)
[switch/evidence.cpp:178] Failed to initialize NSCQ
Error 600: NSCQ Initialization Failed

Read it carefully, because the detail is the whole finding. The switches are there: four devices with the LS10 identifier on the PCI bus, four device nodes in /dev. The driver sees them. The blocker is the NSCQ session itself, the query channel the attestation tool opens to read a switch’s evidence. It refuses to initialise from inside the Trust Domain. Nothing we tried in the guest changed that, and we stopped before inventing workarounds that would prove nothing.

The second failure, kept separate on purpose

In the same session the CLI also failed to attest the GPUs themselves, which the SDK had attested six days earlier from the same node type. The cause was different and we want it on the record so nobody folds it into the switch result:

# The CLI path to NVIDIA's RIM service, from the same guest, same session
[nv_http.cpp:142] Fatal libcurl error code: SSL connect error (35)
[nv_ocsp.cpp:163] Failed to perform OCSP check with url: https://ocsp.ndis.nvidia.com
[rim.cpp:265] Failed to generate certificate chain claims for RIM with id NV_GPU_DRIVER_GH100_595.71.05
GPU attestation failed! Error 002

# 5 shots at rim.attestation.nvidia.com during the session: four HTTP 200, one timeout at 12 s.
# The Python SDK in REMOTE mode succeeds on the same guest: NRAS does the revocation checks itself.

That is an intermittent egress problem from the node to NVIDIA’s OCSP and RIM endpoints, measured the same day from a smaller VM as well: 14 failures in 40 requests. It is not a platform limit, and the SDK in remote mode is unaffected because NVIDIA’s service performs the revocation checks itself. It is the kind of thing that makes “attestation failed” meaningless without the log line, which is why the log line is published.

What it changes for a buyer of eight-GPU nodes

The honest sentence, the one now on our product page, is: on the 8x H100 tier, each of the eight GPUs is attested by the tenant from inside the guest; the NVSwitch fabric is not verified. We do not write “NVLink attested”, and we would treat any provider who does as owing you the log that shows it. On a multi-GPU workload the activations cross those switches, so the tenant is trusting the host operator for that hop. That is still far less than trusting the operator for everything, which is what a non-confidential node asks of you. It is not zero, and the brochure should say so.

Two things would change our wording. NVIDIA confirming that switch attestation is host-side only in Protected PCIe mode, in which case we would write that no tenant on any provider can obtain it today and cite them. Or a guest-side prerequisite we missed, in which case we rerun the twelve minutes and publish the token. We asked both questions in public, with the logs, on the NVIDIA developer forum on 17 September and as issue 153 on nvtrust on 18 September. This page will be updated with the answer, whichever way it goes.

Reproduce it

Everything from both sessions is in github.com/Jabsama/confidential-gpu-attestation-evidence, folders ppcie-8x-h100-2026-09-10 and nvswitch-2026-09-16, with SHA-256 sums, under CC BY 4.0. The same files are mirrored at /blog/two-proofs/evidence/nvswitch-2026-09-16/. The verifier is voltage-verify (MIT, on PyPI). The per-SKU status of what is and is not attested, as a public JSON, is at /api/attestation/evidence, and the coverage table with the same information for humans is on the Confidential Compute page.