What Kernel Hash Verification Means: Detecting Unauthorised GPU Code
For executives
GPU kernel hash verification is the technique of computing a cryptographic hash of the compiled GPU kernel code being loaded into a CUDA context and comparing it against a known-good baseline. If the hash matches the expected value for the declared workload, the kernel is legitimate. If it does not, something unexpected is being executed on the GPU. This is the GPU equivalent of process signature verification on the CPU — and it fills a gap that no other GPU monitoring technique covers.
What a GPU kernel is (for hash purposes)
A GPU kernel is a compiled program that executes on the GPU's streaming multiprocessors. The compilation process takes CUDA C/C++ source code through NVCC, producing PTX (Parallel Thread Execution) intermediate code, which is then compiled to SASS (Shader ASSembly) for a specific GPU architecture.
The compiled binary — the PTX or SASS code — is deterministic for a given source and compiler version. The same PyTorch matrix multiplication kernel source, compiled with the same NVCC version for the same GPU architecture, produces byte-for-byte identical output every time. That output has a deterministic cryptographic hash.
How kernels are loaded at runtime
When a CUDA program initialises, it loads one or more CUDA modules. A module is a container for compiled GPU kernel functions — roughly analogous to a shared library on the CPU side. AI frameworks pre-compile their CUDA kernels and include them in their Python packages. When PyTorch is imported, it loads its CUDA modules into the current CUDA context.
JIT (Just-In-Time) compilation also occurs at runtime for custom operations. When a user writes a custom CUDA extension, it may be compiled at first use and loaded into the CUDA context. JIT-compiled kernels have variable hashes because the source may vary.
Building a baseline
For a known workload type — PyTorch training on a specific GPU architecture, using a specific framework version — the set of CUDA modules that will be loaded is predictable. Running the workload in a controlled environment and recording all module hashes at load time produces a baseline.
For production workloads that use standard frameworks without custom CUDA extensions, the baseline is relatively stable: it changes only when the framework version changes. For workloads with JIT compilation, the baseline requires more careful management.
Detection logic
At runtime, when a CUDA module is loaded into a container's CUDA context:
- Compute the hash of the module binary being loaded.
- Check the hash against the baseline for this container's declared workload type.
- If the hash matches: legitimate kernel, expected workload.
- If the hash does not match: unexpected GPU code.
Unexpected GPU code may be legitimate (a framework update, a new custom extension, a dependency update) or may be malicious (a cryptomining kernel, a memory-scanning kernel, an injected payload). The detection is a flag for investigation, not automatic attribution.
What hash verification catches
Cryptomining kernels: a mining kernel's binary has a hash that is not in any legitimate AI framework's module set. Any container loading a mining kernel will trigger a hash mismatch.
Injected malicious CUDA code: code injected via supply chain compromise, malicious base image, or runtime injection has a hash that does not match the expected workload.
Tampered framework kernels: if a framework's compiled CUDA kernels are modified (a supply chain attack at the framework level), the modified kernels have different hashes from the legitimate framework's modules.
What hash verification does not catch
Malicious code that is identical to a legitimate kernel: if an attacker has access to the exact same compiled kernel binary as the legitimate framework, they can run malicious logic through the same kernel by manipulating the input data rather than the kernel code. This is a training data poisoning or input manipulation attack, not a kernel injection attack — a different threat model.
JIT-compiled malicious code that was designed to match a known hash: computationally infeasible but theoretically possible if an attacker has pre-image attack capabilities against the hash function.