What Is a GPU -- and Why It Is Architecturally Different from a CPU
For executives
Security teams understand CPUs. The entire modern security stack — EDR, SIEM, endpoint monitoring, kernel audit, eBPF-based observability — was built around how CPUs work. GPUs work differently. They are not simply faster CPUs. They have a fundamentally different architecture, a different execution model, and a different relationship to the security tools that organisations already run. Understanding those differences is the prerequisite for understanding why GPU security is its own discipline.
A CPU is designed to execute a single stream of complex instructions as fast as possible. A modern server CPU might have 64 cores. Each core handles complex control flow, branch prediction, deep cache hierarchies, and the rich instruction set that general-purpose computation requires. All of the OS abstractions — processes, threads, virtual memory, syscalls, privilege levels — are built around the CPU's architecture.
A GPU is designed to execute many thousands of simple operations simultaneously. An NVIDIA H100 has 16,896 CUDA cores, each far simpler than a CPU core. The GPU achieves performance not through individual core speed but through parallelism: when an operation can be broken into thousands of identical sub-operations, the GPU runs them all at once.
This architectural difference has direct security consequences.
The security tooling gap
Security monitoring tools instrument the CPU's execution: eBPF probes intercept Linux kernel calls, EDR agents trace process behaviour, network monitors observe TCP/IP traffic. These mechanisms are part of the CPU's operating environment. Every process is known to the OS.
GPU execution is not managed by the OS in the same way. The GPU has its own execution context, its own memory, and its own instruction dispatch. Code executing on the GPU does not make Linux syscalls. It does not appear in the process table. The OS has no visibility into what the GPU is computing.
When an AI training workload runs, the actual model computation happens on the GPU — in a space that the OS cannot observe. This is an architectural consequence of how GPUs achieve their performance: by bypassing the OS for compute operations.
The memory isolation gap
CPU memory isolation is enforced by the kernel through page tables. Each process has its own virtual address space. The kernel ensures that one process cannot access another process's memory.
GPU memory isolation is not enforced by the OS. VRAM is managed by the GPU driver, not by the OS kernel's virtual memory system. The driver allocates VRAM regions to processes, but the isolation enforcement is the driver's responsibility. If the driver has a vulnerability, or if the isolation is not configured correctly, one process's GPU memory may be accessible to another.
The privilege model difference
On a CPU, privilege levels are well-defined: user space (ring 3), kernel space (ring 0), SMM below that. Security tools monitor the boundary between user space and kernel space.
On a GPU, there is no analogous defined privilege hierarchy that security tools can monitor. The GPU driver runs in kernel space on the CPU side and processes commands from user-space CUDA programs. Vulnerabilities in the driver — the class of CVEs that make up a significant portion of this library — allow user-space code to influence kernel-space driver behaviour. But monitoring this boundary requires instrumentation inside the driver, not at the generic kernel syscall boundary that eBPF and EDR tools monitor.
The scale of the attack surface
The NVIDIA GPU driver (nvidia.ko) is one of the largest kernel modules in regular use — hundreds of thousands of lines of proprietary C code, updated with every driver release. The Container Toolkit, GPU Operator, and CUDA runtime add further layers of complex code above it.
The rate of vulnerability disclosure — 12 NVIDIA CVEs in all of 2024, 57 in 2025 — reflects the research community catching up with infrastructure that was deployed at massive scale before its security properties were well understood.