Confidential VMs & Tenant Attestation

Generate a TDX Quote

sudo mkdir /sys/kernel/config/tsm/report/r1

head -c 32 /dev/urandom > nonce.bin
openssl dgst -sha512 -binary nonce.bin | \
  sudo tee /sys/kernel/config/tsm/report/r1/inblob > /dev/null

sudo cat /sys/kernel/config/tsm/report/r1/outblob > quote.bin
ls -l quote.bin   # 5247 bytes

$ xxd -l 6 quote.bin
00000000: 0400 0200 8100                           ......

Generate a GPU Attestation Report

The TDX quote above never covers the GPU. On a single-GPU H200, H100 or RTX PRO 6000 Blackwell Confidential VM, the GPU produces its own attestation report, signed by NVIDIA rather than by Intel, and bound to a nonce you choose. That gives you two independent proofs from one session, with two separate roots of trust and VoltageGPU in neither. On the 8x H100 node the same proof exists for all eight GPUs, in NVIDIA's multi-GPU Protected PCIe mode: see the note at the end of this section, the reading differs and the SDK needs one option.

Read the state before anything else. If CC State is not ON, or DevTools Mode is not OFF, stop: a DevTools part produces a report whose measurements will not match NVIDIA reference values.

$ nvidia-smi conf-compute -q

    CC State                   : ON
    Multi-GPU Mode             : None
    CPU CC Capabilities        : INTEL TDX
    GPU CC Capabilities        : CC Capable
    CC GPUs Ready State        : Ready

$ nvidia-smi conf-compute -d
DevTools Mode: OFF

sudo apt-get install -y python3-pip python3-venv
python3 -m venv ~/att && . ~/att/bin/activate     # a venv, not --break-system-packages
pip install nvidia-ml-py nv-attestation-sdk cryptography==43.0.1

python3 - <<'PY'
import os, pynvml as n
n.nvmlInit()
h = n.nvmlDeviceGetHandleByIndex(0)
nonce = os.urandom(32)                       # yours, generated here, now
rep = n.nvmlDeviceGetConfComputeGpuAttestationReport(h, nonce)
open("gpu_report.bin","wb").write(bytes(rep.attestationReport[:rep.attestationReportSize]))
print("report", rep.attestationReportSize, "bytes, nonce", nonce.hex())
PY

python3 - <<'PY'
import secrets, json, base64
from nv_attestation_sdk import attestation
nonce = secrets.token_hex(32)
c = attestation.Attestation()
c.set_name("my-vm"); c.set_nonce(nonce); c.set_claims_version("2.0")
c.add_verifier(attestation.Devices.GPU, attestation.Environment.REMOTE,
    "https://nras.attestation.nvidia.com/v3/attest/gpu", "")
ev = c.get_evidence()          # attest() without evidence raises in 2.7.3
print("attest ->", c.attest(ev))
open("nras_token.json","w").write(c.get_token())
PY

A passing run prints Attestation Successful and writes a signed EAT token. The claims that matter are measres: success, meaning the runtime driver and VBIOS measurements matched NVIDIA's published golden values, and x-nvidia-gpu-attestation-report-nonce-match: true, which is what makes the report impossible to replay from an earlier session. Verified on this SKU on 4 September 2026: driver 595.71.05, VBIOS 96.00.CF.00.02, hwmodel GH100, secboot true, dbgstat disabled.

The deprecated local verifier (python3 -m verifier.cc_admin) currently fails its OCSP request from inside the guest and reaches end of support on 15 September 2026. Use the remote service above, or NVIDIA's C++ SDK.

Multi-GPU nodes read differently. On an 8-GPU node in NVIDIA's Protected PCIe mode, nvidia-smi conf-compute -q reports CC State OFF together with Multi-GPU Mode Protected PCIe: the second line is the one that matters. If CC GPUs Ready State reads Not Ready, run sudo nvidia-smi conf-compute -srs 1. The attestation SDK then needs get_evidence(options={"ppcie_mode": False}) (the option means "standalone mode"; with the default it refuses to run on a PPCIe system). Verified on 10 September 2026 on an 8x H100 VM: NVIDIA's remote service returned Attestation Successful for all eight GPUs, token published at /blog/two-proofs/evidence/ppcie-8x-h100/. NVSwitch attestation is not verified yet. The 8x H200 node reads the same mode (Ready State Not Ready on 4 and 9 September) and its attestation has not been run.

Where this does not work: the container tier gives the tenant no attestation, so the Intel TDX quote is the only hardware evidence available there. RTX PRO 6000 Blackwell VMs were attested on 17 September 2026 (CC State ON, NVIDIA remote attestation successful on a caller nonce, evidence at /blog/two-proofs/evidence/rtx6000b-2026-09-17/). Always run conf-compute -qyourself at first login rather than trusting any page, including this one.

Two Reports Are Never Byte-Identical

If you hash a report today and compare that hash against a fresh report tomorrow, the comparison will fail even on an untouched machine. The report is 4,129 bytes and three regions of it change between calls. Only 3,969 bytes are stable. This catches people on their first day, because the natural way to pin an approved state is to fingerprint the whole blob.

The first and the third surprise nobody. The middle one does: it changes even when you send the same nonce twice, so you only find it by fetching twice with an identical nonce and diffing the results. The report is a DMTF SPDM 1.1 MEASUREMENTS response, and SPDM has the responder contribute 32 random bytes of its own alongside yours. The signature covers both, which is why the signature moves with it. Neither field is a defect, and neither weakens the proof: the nonce you chose is still in there, still signed, still yours to check.

python3 - <<'PY'
import pynvml as n
n.nvmlInit()
h = n.nvmlDeviceGetHandleByIndex(0)
nonce = bytes(range(32))                     # deliberately fixed, not random
def pull():
    r = n.nvmlDeviceGetConfComputeGpuAttestationReport(h, nonce)
    return bytes(r.attestationReport[:r.attestationReportSize])
a, b = pull(), pull()
runs, start = [], None
for i, (x, y) in enumerate(zip(a, b)):
    if x != y and start is None: start = i
    if x == y and start is not None: runs.append((start, i)); start = None
if start is not None: runs.append((start, len(a)))
print("size", len(a), "differing ranges", runs)
print("stable bytes", len(a) - sum(e - s for s, e in runs))
PY

Found and reported by Mohammed Zoheb Shaik, who paid for the machine that produced it, ran the diff nobody else had run, and sent us the result. Published with his permission.

Artifacts You Can Verify Without a VM

The raw files from the 4 September 2026 run on a single-GPU H200 VM are published, unchanged since capture, with SHA-256 checksums. They let an auditor check NVIDIA's signature and Intel's quote format before spending anything on a machine. They do not replace a run on your own VM: only your own nonce proves your own session.

Concurrent Quotes: Retry on EINVAL, and Only on EINVAL

One quote at a time works every time. Several at once do not. Mohammed Zoheb Shaik, who is building Custodian, a key broker for model weights, reported on 9 September 2026 that with six quote requests in flight, roughly one in six came back with [Errno 22] Invalid argument from the kernel's configfs TSM interface (Ubuntu 24.04, kernel 6.8). The failure is in the kernel's TSM object as one entry is torn down while the next is created, not in the hardware and not in the quote itself. It fails closed: you get an error, never a quote bound to someone else's report_data.

import errno, time
def get_quote(report_data, attempts=5):
    for i in range(attempts):
        try:
            return tsm_quote(report_data)        # your configfs TSM call
        except OSError as e:
            if e.errno != errno.EINVAL or i == attempts - 1:
                raise                            # EACCES, ENOENT and the rest: stop here
            time.sleep(0.05 * (i + 1))

The Guest Clock: What It Proves, and Where It Stops

If your workload makes a security decision based on elapsed time, a lease that expires, a token that must be refreshed, a window that must close, then the clock is part of your threat model. Inside a confidential VM it is worth knowing exactly how far the guarantee goes, because the answer differs by platform and it is not absolute on either.

On Intel TDX, which is what this tier runs. The TDX module, not the host, owns TSC virtualisation for a Trust Domain. The virtual TSC frequency is a property of the TD fixed when the TD is built, and an attempt to change it afterwards is rejected. That is why the Linux guest forces X86_FEATURE_TSC_RELIABLE: it also stops a fall back to a tick source whose rate the host could bend. A paused TD that resumes cannot be made to believe no time passed, so a lease driven by rdtsc sees the jump.

On AMD SEV-SNP, unless Secure TSC is enabled. The counter stays malleable by the host at runtime, through scaling and offset, so rdtsc alone is not a trusted time source there. AMD addresses this with Secure TSC, which is opt-in through a bit in the SEV_FEATURES field of the VM Save Area; Intel's equivalent feature is called Virtual TSC. This matters when comparing tiers: the confidential GPU VM sold by Azure is built on AMD SEV-SNP, not on Intel TDX.

Measured, not assumed. On a genuine GCP N2D SEV-SNP guest, with /dev/sev-guest present and sev_guest as the TSM provider, there is no Secure TSC at all and tsc_reliable is set on no CPU. So on the SEV-SNP you can actually rent today, the malleable case is the default and the protected one is the exception. The TDX guest was the only one of the three to clear the bar, with tsc_reliable on all four CPUs.

The available clocksources say the same thing more plainly. On TDX they are tsc and acpi_pm. On both AMD guests they are tsc, kvm-clock and acpi_pm. kvm-clock is the host telling the guest what time it is, and TDX does not leave it on the shelf. All three guests also report tsc_known_freq, meaning the kernel was handed its rate rather than measuring it: 2449.998 MHz on both AMD boxes, 2700.000 MHz on the Intel one. You can watch the handover in dmesg and you cannot check it against anything.

These measurements were run and shared by Mohammed Zoheb Shaik on 15 September 2026, on three GCP guests that were deleted afterwards. He also enumerated the TD report body field by field, 584 bytes with every one accounted for by a documented field, which is what turns the claim below from a reading of a specification into a property of a real capture.

What to do about it. Treat the guest counter as a source of monotonicity, which it genuinely is, and not as a source of wall-clock truth. If a deadline has to hold against the operator, let a signed timestamp from the party on the other side of the exchange decide whether the window has closed, and use the guest counter only to order events between those checks. Put another way, and this is the framing we owe to the reporter below: the clock becomes trustworthy at the platform level rather than in your code, so what the bound is worth is reported per deployment rather than assumed.

Credit. The TDX-versus-SEV distinction here was sent to us on 13 September 2026 by Mohammed Zoheb Shaik, who is building Custodian, a key broker for model weights, after he checked the TDX behaviour on real hardware rather than taking our reading on trust. The launch-time frequency caveat is ours, found while verifying his report against the specifications. The published weakness of Secure TSC itself, its use as a co-location detection channel between confidential VMs, was reported to AMD in March 2024 by researchers at TU Graz and placed by AMD outside the current threat model for the feature.