Overview

CuSafe's evaluation separates security coverage from operating cost. In a constructed 33-program suite—15 spatial and 18 temporal cases—it detected all reported cases, while Compute Sanitizer detected 3 of 15 spatial and 10 of 18 temporal cases in the authors' comparison. Across 44 programs including Rodinia, PolyBench-GPU, Tango, LLaMA2-7B, and LLaMA3-8B, CuSafe averaged 13% execution-time overhead and an 11% LLM-throughput reduction, with an 83% worst execution-time overhead and an 18% worst LLaMA3 reduction. The chapter treats these as setup-specific evidence and turns compiler reach, unsupported allocation forms, object-level bounds, and identity limits into a conditional adoption decision.

Learning outcomes

CuSafe detected all 33 programs in the constructed suite, while Compute Sanitizer detected 3 of 15 spatial and 10 of 18 temporal cases.
Across 44 evaluated programs, CuSafe averaged 13% execution-time overhead and 11% lower LLM throughput, with higher worst cases.
Adoption depends on compiler and allocation reach and workload fit; reported averages do not transfer to unsupported paths or every CUDA program.

Keywords

CuSafeCoveragePerformanceDeploymentWorkloadsCompute Sanitizer

The Practical Test: What CuSafe's Results Prove—and What They Do Not

CuSafe's evaluation asks two different practical questions. The security suite asks whether its metadata and identity mechanisms detect the spatial and temporal failures they were designed to target. The performance study asks whether the checks remain affordable across ordinary GPU programs and large language models. This chapter interprets both results with their denominators attached, compares CuSafe with NVIDIA's documented Compute Sanitizer without declaring a universal winner, and turns the prototype's compatibility limits into a conditional adoption judgment.

The central discipline is scope. A complete result on a constructed test suite is strong evidence about those cases, not every CUDA program. An average slowdown is useful for planning, not a fixed tax for every workload. Memory overhead, occupancy, instruction cost, and compiler reach are related but not interchangeable. CuSafe's practical case is strongest when these measurements and boundaries are read together.

What the 33-program security suite shows

The authors evaluate 33 GPU programs: 15 contain spatial memory corruption and 18 contain temporal memory corruption. The spatial cases include both linear and non-linear overflows, as well as local-memory overflows that stay within a frame or cross between frames. The temporal cases include immediate and delayed access. This composition is important because it tests more than the easiest buffer-overflow pattern. It asks whether a sanitizer can recognize different shapes of range failure and different delays between an object's end and a stale use.

CuSafe detects all 15 spatial cases and all 18 temporal cases in the reported table. That is the source of the paper's 100% coverage result. The result is meaningful because the cases exercise the two mechanisms developed in the preceding chapters: exact buffer bounds and pointer-integrity checks for spatial errors, plus invalidation and identity information for temporal errors. It is not merely a count of tests passed by a generic wrapper.

The denominator changes the meaning of every percentage in this table. “All” means all 33 programs in the authors' constructed and extended suite, with its particular distribution of linear, non-linear, immediate, and delayed cases. If the suite contained only linear overflows, it would say little about the exact-bound and tag-integrity choices. If it contained only one kind of use-after-free, it would say little about stack and virtual-address reuse. The composition makes the result more informative, but it does not turn a finite suite into an exhaustive model of CUDA behavior.

Compute Sanitizer detects 3 of the 15 spatial cases and 10 of the 18 temporal cases in the authors' comparison. The paper attributes the spatial misses to the tested non-linear and other overflow patterns, and the temporal misses include delayed use-after-free cases and an immediate local use-after-free. These results help explain why CuSafe's design emphasizes precise in-band bounds and allocation identity rather than relying on a single guard or a basic address-range observation.

The numbers should still be read as an experiment, not a universal product ranking. The authors constructed and extended the suite because the competing projects did not provide the same public benchmarks. For GPUShield, cuCatch, and LMI, some coverage values were estimated from the descriptions in their papers because public implementations were unavailable. The strongest comparison is therefore between the CuSafe and Compute Sanitizer runs actually performed in the study; conclusions about unavailable systems carry a weaker evidentiary basis.

Published by DeepMox

FAQ

How many cases did CuSafe detect in its security evaluation?

CuSafe detected all 33 programs in the authors' constructed suite: 15 with spatial corruption and 18 with temporal corruption.

What performance overhead did CuSafe report?

Across 44 evaluated programs, the paper reports 13% average execution-time overhead and an 11% average reduction in LLM throughput, with higher workload-specific peaks.

Which CUDA paths are outside CuSafe's current prototype?

The current prototype does not support JIT compilation, dynamic shared memory, or in-kernel malloc, and it cannot directly instrument closed-source modules.

Previous10 minCuSafe Temporal Safety: Reuse, Epochs, and Identity

Next10 minCuSafe and the Future of Architecture-Aware GPU Safety

CuSafe Results: Coverage, Cost, and Deployment

The Practical Test: What CuSafe's Results Prove—and What They Do Not

What the 33-program security suite shows

FAQ