GPU Confidential Computing

• GPU Confidential Computing is a secure framework that extends trusted execution to GPUs, protecting sensitive data and workloads.
• It employs multi-stage trusted boot, hardware isolation, and cryptographic protocols to safeguard GPU memory, registers, and communications.
• GPU-CC enables secure AI and data-parallel processing in cloud environments while mitigating threats from untrusted software and physical attacks.

GPU Confidential Computing (GPU-CC) refers to the extension of confidential computing principles—long established for CPUs and system memory—to GPUs, enabling secure, isolated, and attested execution of sensitive workloads on GPU hardware. GPU-CC is motivated by the increasing adoption of AI and data-parallel workloads in cloud and multi-tenant settings, where GPUs process sensitive data and models at scale. With the emergence of commercial hardware-supported GPU-CC—most notably on the NVIDIA Hopper architecture—confidential computing now encompasses both CPU and GPU execution domains, establishing a unified trusted boundary and addressing the pervasive threat models arising from untrusted operating systems, hypervisors, interconnects, and physical attacks on system components.

1. Foundational Principles, Threat Models, and Design Objectives

GPU-CC builds upon the well-understood threat models and layered protections of CPU-based TEEs, augmenting them to cover new attack vectors arising from both the GPU’s complex hardware/software stack and the unique interface between CPU and GPU. The foundational security goals are:

• Confidentiality: Ensuring that sensitive data, model parameters, and kernel code remain invisible to any entity outside the TEE boundary, including privileged cloud operators and potentially untrusted hypervisors.
• Integrity: Guaranteeing that computation and data cannot be tampered with undetectably during transit (e.g., across PCIe/NVLink) or while resident in GPU memory, protecting against both logical and physical attacks.
• Attestation: Providing a mechanism for remote parties to verify the integrity of the GPU’s firmware, kernel stack, and TEE configuration, yielding a cryptographically sound “measurement” of the execution environment.

The GPU-CC threat model expands to include attacks from compromised host software, DMA-based snooping, unauthorized register access (e.g., via BAR0 on PCIe), and firmware-level manipulation. The trust boundary in GPU-CC—especially in the Hopper architecture—explicitly encompasses the GPU core, its on-package high-bandwidth memory (HBM), and supporting microcontrollers (e.g., the GSP and FSP), but excludes untrusted host RAM, staging buffers, and external buses (2507.02770).

2. Architecture, Hardware Enablers, and Secure Boot Chains

Modern GPU-CC architectures deploy a layered design that integrates multiple hardware engines, microcontrollers, and cryptographic operations:

• Trusted Boot and Firmware Chain of Trust: GPU-CC bootstraps from an external root of trust (e.g., CEC EROT), which authenticates the FSP (a RISC‑V microcontroller), then the GSP, and finally the SEC2 engine. Each stage of initialization is cryptographically signed, ensuring that only genuine, attested firmware is loaded (2507.02770).
• Secure Protected Region (CPR) in GPU Memory: The GPU memory is partitioned into protected regions accessible only to authenticated GPU-CC contexts, defended by both hardware access controls and cryptographic isolation enforced by on-chip engines.
• Microcontrollers and Secure Engines:
  • GSP (General System Processor): Offloads GPU initialization and mediates secure communication with the CPU, handling encrypted DMA and RPC channels using keys negotiated via SPDM (Security Protocol and Data Model).
  • SEC2: Manages the transition to confidential computing mode, device attestation, and secure memory scrubbing.
  • Copy Engine (CE): Governs data transfers between trusted GPU memory and unsecured host/staging regions, enforcing cryptographic protection of all data leaving the CPR (2507.02770).
• BAR0 Decoupler: A hardware firewall that restricts host PCIe register access in GPU-CC mode, nullifying potential attack vectors through configuration register manipulation.

3. Secure Communication, Remote Attestation, and Work Submission

Security protocols in GPU-CC ensure that all data entering or leaving the GPU’s trust boundary is authenticated and, where necessary, encrypted:

• SPDM-based Key Negotiation: During initialization, the Linux kernel GPU driver (acting as SPDM requester) establishes a session with the GSP (as SPDM responder), deriving a master secret. This root is then expanded into separate keys for RPC, DMA, and work submission channels (2507.02770).
• Data Transfer Protection:
  • Bounce Buffers: All data transferred via PCIe is staged in encrypted buffers, ensuring confidentiality and integrity as it traverses untrusted memory and buses (2409.03992).
  • Cryptographic Algorithms: Protocols such as AES-GCM provide both encryption and integrity via message authentication codes (MACs), securing data in-flight between host and device (2501.11771).
• Remote Attestation and Secure Boot: The attestation protocols encompass hardware and firmware identities, configuration measurements, and runtime states. Downstream components (e.g., containers/VMs) validate attestation reports before provisioning secrets or submitting work.

A central design tenet is that non-modified user workloads can continue operating; all data moves, kernel launches, and management operations are transparently mediated by the GPU-CC microcontrollers and their associated secure channels.

4. Performance Characteristics and Overheads

The move to confidential computing incurs nontrivial performance implications, primarily arising from data movement overhead and cryptographic operations at system boundaries:

• Inference Workloads: For standard LLM inference tasks, GPU-CC mode on NVIDIA Hopper GPUs yields a performance overhead of less than 7% compared to baseline mode. This overhead is predominantly attributable to data transfer encryption/decryption over PCIe, rather than the core compute phase (2409.03992).
• Model Swapping and Batching: In situations requiring frequent model swaps (e.g., multi-tenancy with relaxed batch inferences), CC-induced overhead rises to 20–30% for latency and 45–70% for throughput. GPU utilization may be halved in CC mode due to longer waits on encrypted load operations (2505.16501).
• Distributed Training: In data-parallel ML training using DDP (Distributed Data Parallel), each ring all-reduce step across n GPUs mandates 4 × (n – 1) encryption and authentication operations (covering both scatter-reduce and all-gather). With four GPUs, per-iteration runtime may increase by an average of 8×, and for larger models or higher GPU counts, slowdowns exceeding 40× can result (2501.11771).
• Scheduling Strategies: Adaptive batch scheduling (e.g., “Select Batch + Timer”) partly mitigates SLA miss rates under CC, but trade-offs with throughput are significant—meeting strict SLA constraints in CC often requires incomplete batching, further impacting throughput (2505.16501).
• Resource-Constrained Environments: When GPU execution is not available within the enclave (as in current CPU-based TEEs like Intel TDX), inference throughput drops drastically; reported GPU/CPU performance ratios average 12× for LLM inference (2502.11347).

5. Security Evaluation, Attack Surfaces, and Experimental Findings

Multiple research projects probe the robustness and potential weaknesses of GPU-CC deployments:

• BAR0 and Register Isolation: Instrumentation of the GPU kernel driver confirms that, in GPU-CC mode, over 99% of BAR0 space is zeroed out via the decoupler, but a residual fraction of nonzero fields raises residual risk; the exposure and proper control over these fields remain critical (2507.02770).
• Metadata Leakage: Even where payloads on the CPU–GPU RPC channel are encrypted, metadata such as physical address tables and queue headers may remain unprotected, representing potential information leakage vectors (2507.02770).
• Timing Channels: Memory copy operations present a bimodal latency distribution in GPU-CC mode, suggesting that the execution time may leak information about transfer sizes or system state. Ensuring constant-time behavior in all secure paths is a recognized challenge (2507.02770).
• Scrubbing and Fault Reporting: Secure scrubbing commands are verified and signed via the SEC2 engine, and fault packets use shadow buffers to avoid exposing sensitive content, but the end-to-end coverage and verification chain’s exact interactions remain incompletely open to scrutiny.
• Transparent User Experience vs. Complexity: For end users, activating GPU-CC requires no application adjustments; the complexity is hidden under the driver and firmware interfaces, but the lack of full documentation and code transparency complicates independent verification and security research (2507.02770).

6. Challenges, Limitations, and Future Directions

Several fundamental and operational challenges remain:

• Opacity of Proprietary Systems: The closed design and sparse documentation of GPU-CC internals—especially for the FSP, GSP, SEC2, and hardware data paths—obstruct third-party validation. Security researchers must reconstruct system behavior by indirect observation and reverse engineering (2507.02770).
• Granularity of Access Controls: The correctness and atomicity of access control mechanisms—across microcontroller-managed engines, memory regions, and register maps—are difficult to ascertain in a closed ecosystem.
• Covert and Side-Channel Risks: Experiments highlight the possibility of timing channels and residual unencrypted metadata (e.g., in queue headers), which may serve as attack vectors if not rigorously addressed.
• Multi-GPU Coordination and Trusted I/O: Scaling GPU-CC to multi-GPU and Trusted I/O device scenarios (e.g., for large distributed workloads) is an active area with open questions regarding synchronization, distributed attestation, and minimization of trust in unprotected interconnects.
• Continuous Disclosure and Responsible Reporting: The investigative findings, including potential weaknesses and attack surfaces, have been responsibly reported to relevant vendors (such as the NVIDIA PSIRT Team) (2507.02770).

7. Summary Table of Core System Components and Security Functions

Component	Function	Security Role
FSP	Initial microcontroller, secured at boot	Root of trust, firmware measurement
GSP	Handles GPU initialization and CPU-GPU secure channels	Key manager, encrypted DMA/RPC, attestation
SEC2	Activates CC mode, manages CPR, handles attestation and scrubs	Authenticator, memory sanitizer, access enforcer
CE (Copy Eng.)	Controls memory transfer between secure and unprotected regions	Access control, data movement encryption
BAR0 Decoupler	Restricts register access from host to GPU in CC mode	Attack surface reduction, firewall
SPDM Protocol	Key negotiation between CPU driver and GSP during boot	Session key root, secures work submission

In conclusion, NVIDIA’s GPU-CC as implemented in Hopper architecture exemplifies the integration of a complex, multi-stage trusted boot, memory and register isolation, secure channel enforcement, and attestation-based workload verification, all built to extend the confidential computing boundary to GPU-accelerated AI workloads. While for users this provides a seamless path to securing model and data confidentiality, for researchers and security architects, a layered set of proprietary systems, empirical findings, and residual attack surfaces signal a continuing need for scrutiny, transparency, and technical innovation (2507.02770).