NVIDIA GPU TEEs

Why a GPU TEE matters

CPU TEEs (SGX, TDX, SEV-SNP) solved "data in use" for CPU workloads. Modern inference and training are GPU-bound, though, so if the prompt leaves the CPU enclave in plaintext across the PCIe bus to a non-confidential GPU, the whole chain breaks. A malicious hypervisor, a PCIe-snooping cloud operator, or a rogue firmware blob on the GPU can read every token.

NVIDIA Confidential Computing first shipped on H100 / Hopper in 2023, expanded on H200 in 2024, and on Blackwell B100/B200/GB200 in 2024-2025. It extends the TEE boundary across the PCIe link and into the GPU itself.

Architecture

┌─────────────────────────────────────────────┐
│           Confidential VM (TDX / SEV-SNP)   │
│  ┌───────────────────────────────────────┐  │
│  │  Guest OS + CUDA app (measured)       │  │
│  └───────────────────────────────────────┘  │
│             │  encrypted PCIe (SPDM/AES-GCM)│
│             ▼                               │
│  ┌───────────────────────────────────────┐  │
│  │   NVIDIA GPU in CC-On mode            │  │
│  │  ┌──────────────────────────────┐     │  │
│  │  │  GPU Secure Processor (GSP)  │     │  │
│  │  │  - Hardware root of trust    │     │  │
│  │  │  - Firmware measurement      │     │  │
│  │  │  - Attestation signing key   │     │  │
│  │  └──────────────────────────────┘     │  │
│  │  ┌──────────────────────────────┐     │  │
│  │  │  Protected GPU memory      │     │  │
│  │  │  Hopper HBM: unencrypted   │     │  │
│  │  └──────────────────────────────┘     │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

Components

Modes

1. CC-Off: regular, non-confidential. Any mode switch wipes HBM.
2. CC-On: GPU confidential-computing protections and attestation are enabled. CPU–GPU transfers use encryption; Hopper HBM remains unencrypted.
3. CC-On (DevTools): looser mode for debugging. Do not ship production with this.
4. Multi-GPU: Hopper protected-PCIe (PPCIe) mode encrypts CPU–GPU traffic, while GPU–GPU traffic over NVLink remains unencrypted. Blackwell multi-GPU CC mode also encrypts NVLink traffic. Assess the supported hardware, firmware and driver configuration for each mode.

The attestation flow (end to end)

1. The client opens TLS to the relying service and requests attestation evidence before sending the prompt.
2. The CPU TEE (TDX/SEV-SNP) generates its quote with a nonce supplied by the client, including the hash of the GPU attestation token it just received.
3. The GPU produces its own quote (via GSP) over the same nonce plus the current firmware version and CC mode status, signed by the device-unique attestation key.
4. The client (or a verifier the client trusts) checks: - The CPU quote against Intel PCS / AMD KDS collateral. - The GPU quote against NVIDIA's device-certificate chain plus the NRAS revocation list. - Firmware version is at least the policy-defined minimum. - The measurement (MRTD for TDX; measurement of OVMF + kernel + initrd + rootfs) matches the expected value for the published image.
5. The client derives a session key bound to both quotes. From this point the prompt is encrypted to the dual-attested TEE and no component in the cloud can decrypt it.

Replay is prevented by the client nonce. Operator substitution is prevented because the GPU cert chain is rooted in NVIDIA's factory-provisioned keys; the cloud operator cannot forge a quote without a CVE-class break.

Performance cost

Rough numbers (H100 CC, 70B-class dense LLM inference, published and independently measured in 2024-2025):

Rule of thumb: for steady-state LLM serving, assume around 10% cost. For training or workloads that thrash PCIe, the cost is higher and may be prohibitive until Blackwell's encrypted NVLink is the norm.

Blackwell multi-GPU CC adds NVLink encryption. That protects a specific interconnect; it is not evidence that every GPU memory region or system link is encrypted.

What NVIDIA CC does not protect against

• Side channels you bring yourself. Timing leaks in your CUDA code, cache-based attacks across SMs for co-tenanted GPUs (not a concern if you own the whole GPU; MIG partitioning in CC mode is restricted).
• Model extraction via the API. The TEE prevents raw weight theft; it does not prevent slow distillation via queries.
• Driver compromise on the host. The host NVIDIA driver is untrusted by design; that is the point. But a buggy guest driver inside your CVM can still leak. Keep the guest-side nvidia-open driver pinned and audited.
• GSP firmware bugs. CVEs in GSP firmware have dropped before (see 2023 advisories). Treat the GSP as part of your TCB and monitor NVIDIA security advisories the same way you track Intel/AMD microcode.
• Covert channels via power or thermal. Co-located TEE workloads can sometimes be distinguished by power draw observable to the cloud operator. Not a confidentiality break for plaintext, but a weak fingerprint channel.

Clouds that offer it

Practical deployment checklist

1. Enable CC mode on the GPU (nvidia-smi conf-compute -srs 1; sticky across reboots; wipes HBM on transition).
2. Pin GSP firmware at or above the minimum version that patches the latest advisory (track nvidia.com/en-us/security/).
3. Use the NVIDIA Confidential Computing SDK / NVTrust for attestation collection. Do not roll your own quote parser.
4. Verify both quotes, not just the CPU one. Many early deployments verified the TDX quote and assumed the GPU was fine. It wasn't.
5. Bind the attestation to your session. The client nonce must appear in both quotes and in the TLS key-export.
6. Reject CC-Off GPUs explicitly. Default-closed: if the GPU quote says CC mode = off, drop the connection.
7. Rotate on CVE. When a GSP-firmware CVE drops, push a new minimum-firmware policy to your verifier. Old quotes become invalid automatically.
8. Don't leak via logs. The confidential guarantee is worthless if the app logs prompts to stdout and a sidecar ships them to the cloud's logging service. Build with nvidia-container-toolkit in no-persistence mode.

Primary sources

• NVIDIA H100 confidential computing: bounce buffers and unencrypted HBM
• NVIDIA confidential VM threat model and interconnect limits
• NVIDIA Hopper and Blackwell confidential-computing whitepaper
• NVIDIA Blackwell architecture technical brief
• NVIDIA NVTrust
• NVIDIA attestation documentation
• DMTF SPDM 1.2 specification