LAK: A Low-Overhead Lock-and-Key Based Schema for GPU Memory Safety

Abstract

Graphic processing units (GPUs) are becoming an essential computational resource in a widely range of domains. At the same time, the security of GPUs has emerged as a primary concern in security-sensitive applications. Memory corruption attacks are the major threat in computer security. With contemporary discrete GPUs supporting unified address space, which allows GPU kernel functions to access the same address space with CPU host applications, memory bugs (e.g., buffer overflow and use-after-free) in GPUs can be exploited by attackers to maliciously tamping CPU data or even hijacking control flow. However, modern GPUs lack memory protection support against memory corruption attacks concurrently available in CPUs, and as a result suffer from security threats, as we demonstrate.In this paper, we migrate the conventional CPU memory protection mechanisms to GPUs and point out that directly adopting the CPU memory protection design to GPUs incurs significant performance overhead. The key reason is that: (1) fine-grained multithreading property of GPUs leads to high memory traffic for security metadata accessing, which leads to significant memory bandwidth contention between regular application data and security metadata and degrades the GPU performance; (2) shared L2 data cache suffers significant interference when regular data shared cache with metadata, which leads to increased cache miss rate and worsens the bandwidth contention problem.Based on our observation, we propose LAK, a low-overhead runtime memory safety solution for GPUs to provide comprehensive protection against memory corruption attacks. First, to provide a strong security guarantee, LAK employs a lock-and-key mechanism to enforce memory operations to only access allowed memory regions. Second, to mitigate bandwidth contention, which degrades GPU performance, LAK introduces two components: (a) a post-coalescing memory protection unit to reduce memory traffic of security metadata and (b) a highly-threaded dedicated L2 metadata cache to reduce the interference between metadata requests and data requests. Our evaluations show that LAK incurs a 19% performance degradation.