CPU-GPU Confidential Channel Establishment with AMD SEV-SNP

AMD SEV-SNP closes the hypervisor's read and write access to a guest VM's memory and register state, but that protection ends at the edge of the CPU package, and GPU workloads have to cross that edge to do any useful work. A model's parameters, its training data, and the intermediate activations produced mid-inference all live in VRAM for the full duration of compute, and VRAM sits on the far side of a boundary SEV-SNP was never built to reach. Getting data from a confidential VM to a GPU means crossing the PCIe bus, passing through a host kernel driver, and landing in GPU memory, three legs of a journey that have historically sat entirely outside any cryptographic perimeter. The GPU-CC security analysis states that CPU-GPU data transfers traverse an untrusted PCIe interface, open to observation or manipulation by anyone who controls the host. A correctly configured SEV-SNP guest can still hand its entire GPU working set to an attacker unless something else extends the trust boundary across the bus and into the device itself, and that something else is the subject of the rest of this piece.

What SEV-SNP guarantees at the hardware level, and where its authority stops

SEV-SNP's guarantees break into three pieces: confidentiality, integrity, and remote attestation, and all three are enforced entirely within the CPU package. Confidentiality means guest memory is encrypted with a per-VM key the hypervisor never holds, and register state gets encrypted the moment a VM exits; guests can go further and require ciphertext hiding, which denies the hypervisor visibility even into the pattern of the ciphertext itself. Integrity rests on the Reverse Map Table, which stops the hypervisor from remapping or aliasing guest pages and catches tampering through hardware checks run on every relevant memory access. Remote attestation works because the AMD Secure Processor signs a measurement of the guest's initial state and binds it to AMD's certificate chain, so a remote verifier can confirm independently what code is actually running, a pipeline the SEV-SNP primer develops in full.

Below these three guarantees sits a layer of machinery that makes a confidential guest practical rather than merely theoretical. VM Privilege Levels allow operations like virtual interrupt handling to be delegated with precision, without exposing guest memory to the hypervisor in the process. The encrypted VM Save Area and the GHCB protocol let the guest cooperate with a hypervisor it does not trust for services it still needs, things like CPUID calls, hypercalls, and I/O. All of this machinery matters for what comes later: the same logic of narrow, verified delegation under an untrusted intermediary reappears, in a different form, once GPU communication enters the picture. But every one of these mechanisms stops at the package edge. The AMD Secure Processor's authority ends there, and once data is queued for a PCIe device, none of SEV-SNP's protections apply to it any longer.

Extending the Hardware Trust Boundary to the GPU Side of the PCIe Bus

NVIDIA GPU Confidential Computing mode answers the gap from the first section by building a second trust anchor on the GPU itself: a hardware-level TEE with its own security engines and encrypted VRAM. The GPU-CC security analysis identifies three specialized on-chip processors as the architectural foundation of this design, the Foundation Security Processor (FSP), the GPU System Processor (GSP), the Secure Processor (SEC2), and the Copy Engine (CE). NVIDIA does not publish the precise specification of how these components interact, so the paper's account of their roles comes from instrumentation and direct observation rather than vendor documentation, a reconstruction effort rather than a confirmed architecture diagram.

With CC mode active, VRAM is encrypted and the GPU enforces a hardware perimeter that functions much like the CPU package's own boundary: data sitting in VRAM becomes inaccessible to the host driver and to the hypervisor. GPU-CC arrived with the Hopper architecture and has been getting folded gradually into CUDA and the GPU kernel drivers since, which places it as a starting point in this design lineage rather than a fixed, final specification. The paper traces how a GPU gets from power-on to a trustworthy state through secure boot, key generation, and firewall establishment, the sequence the next section unpacks directly.

AMD's own Instinct GPUs do not follow this same path, instead bringing the GPU inside the host VM's SEV-SNP envelope rather than pairing with a dedicated GPU-level TEE. That distinction seems minor at the architecture level, but it produces a real consequence for attestation granularity, covered later in this piece.

The bootstrap sequence: secure boot, key generation, and firewall establishment inside the GPU

Before a GPU can take part in any cross-domain channel, it has to bootstrap its own root of trust internally, and that process is what later attestation will measure and vouch for. The GPU-CC analysis treats the bootstrap as a coordination problem across hardware and software: secure boot checks firmware integrity, key generation produces the cryptographic material that will later anchor an SPDM session, and firewall establishment puts the GPU's memory access controls in place. Each step depends on the one before it. A key generated before firmware integrity is confirmed would anchor a session to a device that might already be compromised.

The FSP, GSP, and SEC2 processors introduced in the previous section each play some role in this sequence, but because NVIDIA has not published a precise specification of their division of labor, the paper's reconstruction from experimental observation stands as the main available account of how the three actually coordinate. GPU-CC is built to require no modification to application-level code, so the entire bootstrap sits below the application layer. That is convenient for whoever is running a workload, who never has to reason about secure boot or firewall configuration directly. But the convenience shifts the burden rather than removing it: a verifier checking the GPU's trustworthiness still has to reason about that sequence, even if the application author does not.

A successful bootstrap leaves the GPU in a specific state: VRAM encryption active, the security processors attested, and a private key held on-device that will be used in the SPDM handshake described next. If something goes wrong during this sequence, firmware tampering or a CC mode misconfiguration, the failure does not vanish quietly. It surfaces later, in the attestation report the GPU produces, and a verifier that checks that report before trusting any workload results has a chance to catch it there.

How SPDM bridges the two trust domains across the untrusted PCIe bus

With a CPU-side TEE established by SEV-SNP and a GPU-side TEE established by the bootstrap sequence, the two still need a way to talk to each other across a bus that remains, by design, untrusted. That is the job of an SPDM session: a protocol that establishes a mutually authenticated, encrypted channel between the GPU and the driver running inside the confidential VM. SPDM, short for Security Protocol and Data Model, is a standards-track protocol for authenticating and securing communication between system components, and its specific role here is to perform a key exchange that neither TEE could manage alone. Neither side can simply assert trust in the other; both have to prove it cryptographically, across a wire that any host-level adversary can observe.

The GPU-CC analysis places the NVIDIA driver running inside the CVM as the CPU-side participant that initiates this session with the GPU's hardware TEE. Once the session is live, unique encryption keys get derived for each guest driver component, so RPC traffic, DMA transfers, and work submission each travel over a distinct channel, each with its own key, all derived from a single shared master secret negotiated during the SPDM handshake. That per-component key structure is what keeps a compromise of one channel from automatically exposing the others. Through this established session, the driver transfers data to the GPU, kicks off computation, and retrieves results, the entire compute lifecycle running inside the protected channel rather than stepping outside it at any point.

None of this changes the physical reality of the PCIe bus. It is still an untrusted wire. What SPDM changes is what travels across it: anything an adversary on that bus can observe or inject is encrypted ciphertext, with the session keys held only by the two attested endpoints. The paper backs this up experimentally, testing whether data moving along different paths across the bridge stays protected under the threat model the authors define, rather than asserting it holds by design alone.

The GPU Attestation Report

An SPDM session proves the two ends of the channel can talk securely, but it does not by itself tell a remote verifier whether the GPU on the other end is the genuine article, properly configured. That job falls to the GPU's attestation report, which cryptographically binds the device's hardware identity, its firmware state, and its CC mode status to one specific session. The report carries a hash of the GPU's current firmware, a flag indicating CC mode status, a device certificate signed by NVIDIA's certificate authority as proof of hardware identity, and a nonce supplied by the verifier.

That nonce is not a minor detail. It ties the report to one specific verification session, which closes off an obvious attack: taking a valid report from a properly configured GPU and replaying it against a different, compromised device. Without the nonce, a single good attestation could be recorded once and reused indefinitely against hardware that no longer deserves the trust it implies.

The CPU side of the channel has a parallel mechanism already described: the AMD Secure Processor signs a measurement of the guest's initial state against AMD's certificate chain, giving a verifier an independent check on the CVM itself. Putting the two together is what a complete end-to-end attestation actually requires, composing the SEV-SNP report for the CVM with the GPU's own attestation report for the device, and verifying both before any computation result gets trusted. Neither report alone covers the whole channel; the CVM attestation says nothing about GPU firmware, and the GPU attestation says nothing about what's running on the CPU side.

One concrete approach to strengthening the CPU side of that composition comes from IBM Research and the University of Utah, whose work on e-vTPMs runs a virtual TPM as a protected service inside the CVM, isolated from the host rather than trusting whatever vTPM implementation the cloud provider supplies. The motivation is not abstract: the same paper counts 111 vulnerabilities affecting KVM over the last decade, a number that makes the case for not trusting a provider's hypervisor-side vTPM implementation by default. An e-vTPM built this way lets the full software stack get attested from boot, strengthening exactly the CVM side of the two-report composition this section has been building toward.

The attestation granularity gap when using AMD Instinct GPUs instead of NVIDIA GPU-CC

The two-report composition described above depends on the GPU producing its own independent attestation report, and that assumption does not hold universally across GPU vendors. AMD's Instinct GPUs take a different architectural path: rather than pairing with a dedicated GPU-level TEE, they are integrated directly under the host VM's SEV-SNP envelope. The GPU sits inside the trusted execution environment in this design, but there is no separate AMD Instinct GPU-level attestation report covering firmware hash and CC mode status on its own.

That difference has a concrete consequence for what a relying party can actually verify. On the NVIDIA GPU-CC path, a relying party can cryptographically confirm the GPU's security configuration independently of the VM image sitting around it. On the AMD Instinct path, that independent check is not available: the GPU's state gets attested only as part of the whole VM's measurement, folded into one report rather than standing as a separate, device-level claim.

This gap is not a defect in SEV-SNP itself. It follows from where the GPU sits relative to the trust boundary, inside the envelope as opposed to standing alongside it as an independently attested peer, and both arrangements are legitimate engineering choices with different tradeoffs. But for regulated workloads that need auditable proof of GPU-level configuration, encrypted VRAM confirmed, a specific firmware version confirmed, CC mode confirmed enabled, that granularity gap becomes a genuine constraint on what can be proven to an auditor or regulator. Whether independent, fine-grained GPU-firmware attestation can eventually be composed alongside a SEV-SNP VM attestation report remains an open question for the AMD Instinct path, one that has not been resolved in the current architecture.

Known attacks on the CPU-side trust anchor and their effect on the channel's integrity

Everything built across the previous sections, GPU CC mode, the bootstrap sequence, the SPDM bridge, the two-report attestation composition, depends on the SEV-SNP environment underneath it holding. A correctly constructed channel inherits whatever fragility exists in that foundation, and demonstrated attacks against SEV-SNP show the CPU-side trust anchor is not beyond compromise.

The WESEE attack demonstrates one such weakness directly. A hypervisor can inject malicious #VC exceptions into a SEV-SNP guest at any point it chooses, and the guest's #VC handler executes without verifying where that exception actually came from. Researchers used this gap to leak sensitive information, pulling kTLS keys out of a running NGINX instance, to corrupt kernel data by altering firewall rules, and to inject arbitrary code, going as far as spawning a root shell from kernel space. These are not independent, one-off tricks. The underlying primitives, arbitrary memory read and write, register leak and corruption, and instruction skipping, compose with each other, and the WESEE paper shows multiple injections chained together to cascade their effects further than any single injection could reach alone.

What does this mean for everything described earlier in the piece? A GPU attestation report can be perfectly valid, an SPDM session can be correctly negotiated, and encrypted VRAM can be doing what it is supposed to do, and the channel can still be undermined if the CVM at the other end has been compromised through its #VC handler first. The architecture traced through this piece, from SEV-SNP's package-level guarantees, through GPU CC mode's extension of that boundary, through the SPDM bridge, to the composed attestation that ties both ends together, is a genuine engineering achievement. But it is only as strong as its weakest attested component, and the CPU-side trust anchor it depends on has already shown it can be forced open. That fragility is part of why tools built to keep user data genuinely private, like Confidant AI, a privacy-preserving AI assistant designed so data stays with its owner rather than being collected or monetized, tend to treat architectural trust boundaries as a first-order concern rather than an afterthought.