A Survey of Techniques for Improving Security of GPUs <s> Leakage through processor components <s> In the past decade Graphics Processing Units (GPUs) have advanced from simple fixedfunction graphics accelerators to fully-programmable multi-core architectures capable of supporting thousand of concurrent threads. Their use has spread from the specialized field of graphics into more general processing domains ranging from biomedical imaging to stock market prediction. Despite their increased computational power and range of applications, the security implications of GPUs have not been carefully studied. It has been assumed that the use of a GPU as a coprocessor with physically separate memory space, minimal support for multi-user programming, and limited I/O capability inherently guarantees security. This research challenges this assumption by demonstrating multiple security vulnerabilities in the current GPU computing infrastructure. Specifically, it focuses on the following three areas: 1. Denial-of-Service by overwhelming the capabilities of the GPU so it is unable to provide responsiveness to the host operating system. 2. Information leakage due to the way that modern GPUs fail to randomize pointers and zero out memory. 3. The use of GPUs to assist CPU-resident malware through obfuscation and unpacking or acceleration of computational intensive tasks such as password cracking or encryption. Through the use of WebGL and CUDA, we successfully developed a proof of concept attack for the first two vulnerabilities listed above. For the third, we considered several different types of attacks and their implications. In all cases we also suggest possible security measures to fix these vulnerabilities. While the impact of each of these particular exploits is currently hardware and OS specific, current trends in GPU architecture indicate that these problems are only going to rise in importance going forward. <s> BIB001 </s> A Survey of Techniques for Improving Security of GPUs <s> Leakage through processor components <s> This paper investigates the practicality of memory attacks on commercial Graphics Processing Units (GPUs). With recent advances in the performance and viability of using GPUs for various highly-parallelised data processing tasks, a number of security challenges are raised. Unscrupulous software running subsequently on the same GPU, either by the same user, or another user, in a multi-user system, may be able to gain access to the contents of the GPU memory. This contains data from previous program executions. In certain use-cases, where the GPU is used to offload intensive parallel processing such as pattern matching for an intrusion detection system, financial systems, or cryptographic algorithms, it may be possible for the GPU memory to contain privileged data, which would ordinarily be inaccessible to an unprivileged application running on the host computer. With GPUs potentially yielding access to confidential information, existing research in the field is built upon, to investigate the practicality of extracting data from global, shared and texture memory, and retrieving this data for further analysis. These techniques are also implemented on various GPUs using three different Nvidia CUDA versions. A novel methodology for digital forensic examination of GPU memory for remanent data is then proposed, along with some suggestions and considerations towards countermeasures and anti-forensic techniques. <s> BIB002 </s> A Survey of Techniques for Improving Security of GPUs <s> Leakage through processor components <s> Graphics processing units (GPUs) are increasingly common on desktops, servers, and embedded platforms. In this article, we report on new security issues related to CUDA, which is the most widespread platform for GPU computing. In particular, details and proofs-of-concept are provided about novel vulnerabilities to which CUDA architectures are subject. We show how such vulnerabilities can be exploited to cause severe information leakage. As a case study, we experimentally show how to exploit one of these vulnerabilities on a GPU implementation of the AES encryption algorithm. Finally, we also suggest software patches and alternative approaches to tackle the presented vulnerabilities. <s> BIB003
Pietro et al. BIB003 show information leakage in ShM, GlM and registers by using CUDA memory (de)allocation commands. Let P b and P m refer to a benign and a malicious process, respectively. For attacking the ShM, assume that P b runs a kernel which copies a vector from GlM to ShM. This kernel is run Q times. The size of the vector is equal to that of ShM. P m runs a kernel which reads ShM and this kernel is also run for Q times. Specifically, P m allocates a vector in ShM which is of the same size as ShM. Then, it copies data from this vector to a vector in GlM. Using this, P m can read the entire data written by P b in ShM. The only requirement is that P m should be scheduled before P b terminates. The attack sequence is summarized in Figure 2 (a). They also observe that, before the host executes exit() function, the ShM is zeroed. For attacking global memory, assume that the P b allocates 4 vectors (V1 to V4) of equal size using cudaMalloc. Then, it initializes V1 and V2 and copies them to V3 and V4, respectively. Then P b terminates and P m is scheduled. Using Unix sockets, correct synchronization is maintained between them. P m also allocates four vectors of the same size as done by P b . However, instead of initializing, P m executes the same kernel code as executed by P b and copies V3 and V4 to host memory. They observe that P m finds the same data as written by P b . Thus, the entire data written on global memory can be leaked in a deterministic manner, as long as P m allocates the same amount of memory as released by P b . Figure 2 (b) summarizes the sequence for causing leakage in GlM. For leaking data through the register, they exploit "register spilling" mechanism . A process can reserve more registers than those available on the GPU. Variables which cannot be placed in the register are placed in GlM and this is termed as register spilling. An attacker can exploit this to access GlM reserved for other CUDA contexts, even when the benign process owns them and has not freed them using cudaFree. This makes this attack very dangerous. As for the attack procedure, P b writes to GlM multiple times and P m attempts to read the memory allocated to P b . P m reserves a fixed number of registers and copies their content to host memory. They executed P b and P m simultaneously and observed that P m could read the memory reserved by P b before it is released. Thus, the attacker can bypass runtime access primitives. However, this attack does not allow interfering with the computations performed by the benign process. Also, this attack was successful on Kepler GPU but not on Fermi GPU. The event sequence for causing leakage in registers is summarized in Figure 2 (c). Table 3 summarizes the three attacks proposed by them. As for mitigation of attacks on GlM and ShM, they propose the use of data-shredding (i.e., zeroing). For thwarting register-attacks, the GPU driver should (1) forbid spilling to memory locations in GlM which are already reserved by other processes and (2) reset the locations of spilled registers after releasing them. Bellekens et al. BIB002 discuss ways in which remanent sensitive data may be leaked from the global, shared and texture memory of a GPU. For GlM, a benign user transfers data from the host to the GPU using cudaMalloc and cudaMemcpy. Then, the adversary executes a program which allocates same or larger amount of memory using cudaMalloc. Then, it dumps the left-over data in GPU memory to the CPU. By allocating the memory, the adversary can partially or fully recover the data in GPU memory. For leaking data from ShM, they send the data to GlM and then store it in ShM. Then, the adversary runs a program which requires a maximum size uninitialized array in ShM. Using standard I/O, the adversary can get the data of ShM or dump it to global memory. For leaking data from the texture memory, they first transfer the data from CPU and bind it into texture memory using cudaBindTextureToArray. Then, the adversary can use the same approach as that used for ShM to leak the data. They note that different grades of GPUs, viz., server, consumer and mobile grades are vulnerable to such leaks. Further, data remanence can be avoided only by using "hard reboot" since the "GPU reset" mechanism does not prevent such leaks. As for software schemes for mitigating data leaks, they propose writing zero or misleading data during initialization. This can be performed using a separate thread. Also, along with the benign process, a secondary process may be run on the GPU. In case of abrupt termination of the benign process, the secondary process can immediately erase the data to avoid data-leak. Patterson BIB001 notes that unlike CPUs, GPUs do not implement ASLR ("address space layout randomization") or virtual memory. Hence, on GPUs, pointer allocations repeatedly return the same addresses and thus, the data-address can be determined. In the absence of virtual memory, logical addresses of different processes access the same physical memory  . Since GPUs do not erase the memory, the data persists in memory even after program termination. This attack can be extended to find specific data types. They also note that this attack succeeded even across different users and login sessions.