Update, 19 September 2026: we were wrong about the cause
NVIDIA answered on issue 153. The library we had installed was the wrong package: the branch-suffixed libnvidia-nscq-595 comes from Ubuntu’s archive and does not match the driver. The correct one is libnvidia-nscq without a suffix, from NVIDIA’s own repository, pinned to the driver version. We rented the same node type again and reran it. With the matched library, the NSCQ session opens from inside the TDX guest and switch evidence is collected. There is no RDT init failure any more, so the explanation below, that NSCQ cannot initialise from a guest, is retired.
The fabric is still not verified, and we still do not claim it. The run now fails later, at certificate chain validation, because ocsp.ndis.nvidia.com cannot be reached over TLS from the guest. That looks like a network or trust-store question rather than an architectural one, and we have asked NVIDIA about it. Raw logs of all three runs are published, including this correction.
Key Takeaways
- On an 8x H100 node in NVIDIA Protected PCIe mode, all eight GPUs attest from inside the TDX guest. The NVSwitch fabric between them still does not, and the reason changed on 19 September: not an NSCQ session that refuses to open, but a certificate check that cannot reach its revocation responder.
- This is the exact reason, with logs, not a vague “it failed”. The original failure was
NSCQ_RC_WARNING: RDT init failure (Code 1), with the four switches present on the bus and in/dev. That failure came from a mismatched library and is gone. - We asked NVIDIA in public, on the developer forum and as issue 153 on nvtrust, whether switch attestation is host-side only in this mode. NVIDIA answered part of it on nvtrust on 21 September: the operator must bind the switches to vfio-pci and set Protected PCIe mode, a step a tenant cannot apply. The forum post still has no reply, and our product page still says the fabric is not verified.
- A second failure in the same session was an egress problem, not a platform limit, and we say which is which so nobody reproducing the run confuses them.
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.
We said two things would change our wording: NVIDIA confirming that switch attestation is host-side only, or a guest-side prerequisite we had missed. The second one happened. The prerequisite was the library itself, so we reran and the logs are below. On 21 September, Dan Middleton from NVIDIA answered part of the remaining question on issue 153 on nvtrust : switch fabric evidence needs the switches bound to the vfio-pci driver and set to Protected PCIe mode by the host operator, the same as the GPUs, and using Confidential Containers does not remove that dependency for a tenant. That answers the architecture question. What it does not answer is why nvattest fails a TLS connect to ocsp.ndis.nvidia.com with error 35 while a plain curl reaches the same host in about 115ms from the same guest, same second, endpoints passed explicitly or not. We asked that on the same issue and will run strace and ldd against the binary on the next rented node to find out whether it is the tool’s own TLS stack. The NVIDIA developer forum post of 17 September still has no reply. This page will be updated with the answer, whichever way it goes.
Reproduce it
Everything from both sessions is in github.com/VoltageGPU/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. Every public thread about this question, dated, is on our press and mentions page.