Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Chasing Elusive Memory Bugs in GPU Programs

Anubhab Ghosh, Ajay Nayak, Dhananjay Rao Thallikar Shyam, Arkaprava Basu

TL;DR

This paper tackles memory safety bugs in GPU programs, focusing on elusive input-dependent OOBs and intra-allocation OOBs that evade runtime detectors. It presents SCuBA, a static compile-time framework that analyzes host and kernel code to capture semantic relations between allocation sizes and per-thread offsets, then uses a SAT solver to determine if any input could trigger an OOB. It additionally analyzes IR to detect logical partitioning of allocations, enabling intra-allocation OOB detection, and includes use-after-free detection via live-allocation tracking. Empirically, SCuBA detects 45 OOBs across 20 workloads, including 30 previously unreported input-dependent bugs, while incurring no false alarms or runtime overhead, outperforming NVIDIA’s Compute Sanitizer. The work demonstrates that a static-analysis+SAT approach can proactively uncover memory-safety bugs in GPU programs, with practical impact for improving reliability and security without machine-hardware modifications.

Abstract

Memory safety bugs, such as out-of-bound accesses (OOB) in GPU programs, can compromise the security and reliability of GPU-accelerated software. We report the existence of input-dependent OOBs in the wild that manifest only under specific inputs. All existing tools to detect OOBs in GPU programs rely on runtime techniques that require an OOB to manifest for detection. Thus, input-dependent OOBs elude them. We also discover intra-allocation OOBs that arise in the presence of logical partitioning of a memory allocation into multiple data structures. Existing techniques are oblivious to the possibility of such OOBs. We make a key observation that the presence (or absence) of semantic relations among program variables, which determines the size of allocations (CPU code) and those calculating offsets into memory allocations (GPU code), helps identify the absence (or presence) of OOBs. We build SCuBA, a first-of-its-kind compile-time technique that analyzes CPU and GPU code to capture such semantic relations (if present). It uses a SAT solver to check if an OOB access is possible under any input, given the captured relations expressed as constraints. It further analyzes GPU code to track logical partitioning of memory allocations for detecting intra-allocation OOB. Compared to NVIDIA's Compute Sanitizer that misses 45 elusive memory bugs across 20 programs, SCuBA misses none with no false alarms.

Chasing Elusive Memory Bugs in GPU Programs

TL;DR

This paper tackles memory safety bugs in GPU programs, focusing on elusive input-dependent OOBs and intra-allocation OOBs that evade runtime detectors. It presents SCuBA, a static compile-time framework that analyzes host and kernel code to capture semantic relations between allocation sizes and per-thread offsets, then uses a SAT solver to determine if any input could trigger an OOB. It additionally analyzes IR to detect logical partitioning of allocations, enabling intra-allocation OOB detection, and includes use-after-free detection via live-allocation tracking. Empirically, SCuBA detects 45 OOBs across 20 workloads, including 30 previously unreported input-dependent bugs, while incurring no false alarms or runtime overhead, outperforming NVIDIA’s Compute Sanitizer. The work demonstrates that a static-analysis+SAT approach can proactively uncover memory-safety bugs in GPU programs, with practical impact for improving reliability and security without machine-hardware modifications.

Abstract

Memory safety bugs, such as out-of-bound accesses (OOB) in GPU programs, can compromise the security and reliability of GPU-accelerated software. We report the existence of input-dependent OOBs in the wild that manifest only under specific inputs. All existing tools to detect OOBs in GPU programs rely on runtime techniques that require an OOB to manifest for detection. Thus, input-dependent OOBs elude them. We also discover intra-allocation OOBs that arise in the presence of logical partitioning of a memory allocation into multiple data structures. Existing techniques are oblivious to the possibility of such OOBs. We make a key observation that the presence (or absence) of semantic relations among program variables, which determines the size of allocations (CPU code) and those calculating offsets into memory allocations (GPU code), helps identify the absence (or presence) of OOBs. We build SCuBA, a first-of-its-kind compile-time technique that analyzes CPU and GPU code to capture such semantic relations (if present). It uses a SAT solver to check if an OOB access is possible under any input, given the captured relations expressed as constraints. It further analyzes GPU code to track logical partitioning of memory allocations for detecting intra-allocation OOB. Compared to NVIDIA's Compute Sanitizer that misses 45 elusive memory bugs across 20 programs, SCuBA misses none with no false alarms.
Paper Structure (20 sections, 11 figures, 2 tables)

This paper contains 20 sections, 11 figures, 2 tables.

Table of Contents

  1. Introduction
  2. Background
  3. Limitations of prior works & New bug type
  4. Ineffective against input-dependent OOBs
  5. Agnostic to logical partitioning of allocations
  6. Runtime overheads & hardware modifications
  7. Summary: Comparison with prior works
  8. Goals and Design Principles
  9. Semantic relations for detecting input-dependent OOBs
  10. Inferring logical partitions to find intra-allocation OOBs
  11. Detecting use-after-free errors
  12. Implementing SCuBA
  13. Extracting semantic relation among program variables
  14. Detecting OOBs using a SAT solver
  15. Detecting use-after-free bugs
  16. ...and 5 more sections

Figures (11)

  • Figure 1: Input-dependent OOB in fluid simulation kernel.
  • Figure 2: Input-dependent OOB in graph processing kernel.
  • Figure 3: Logical partitioning of shared memory (lines $4$-$7$).
  • Figure 4: Presence of multiple buffers in local memory (line $4$).
  • Figure 5: Semantic relation among variables determining allocation size and thread grid dimensions (lines $9$-$12$).
  • ...and 6 more figures