GPUs, which were originally used for a narrow range of graphics applications, are now spreading their wings to a broad spectrum of compute-intensive and mission-critical applications, most notably, cryptography, finance, health, space and defense. After passing the initial ‘rounds’ of scrutiny on the metrics of performance and energy, it is time that GPUs face and pass the test on the metric of security, which is especially crucial in mission-critical applications.
The ESEA company incident
Recently, a malicious person hid a bitcoin miner in ESEA (a video game service) software. This miner used the GPUs in users’ machines to earn cryptocurrency without their knowledge. The miner overheated and harmed the machines by overloading the GPUs.
Security threats are real and far-reaching!
While overloading others’ GPUs is certainly a threat, there are other, even more severe, threats which have been recently brought to light. For example, in GPU memories, such as global, shared and local memory, deallocated data are not erased. This can allow a malicious agent to launch an information leakage attack and leak sensitive data such as credit card numbers and email contents from remnant data in GPU memory. Similarly, an attacker can guess the opened tabs from Google chrome, figure-portions from recently-opened Adobe Reader documents and portions of images from MATLAB.
To allow sharing GPUs among multiple users, major cloud services provide GPU computing platforms. However, different users in the cloud computing scenario may not trust other. For example, an adversary can rent a GPU-based virtual machine (VM) and leak information of users using other VMs on the same system via GPU memory. Clearly, with GPU virtualization approach, the risks of information-leakage are even higher than that with native execution.
Further, in the absence of rigorous memory-access protection mechanisms, an adversary can launch buffer overflow attack (e.g., stack overflow and heap overflow) for corrupting sensitive data or changing the execution flow. Also, since WebGL allows browsers to utilize GPUs for accelerating webpage rendering, an attacker can launch denial-of-service attack by enticing a user to open a malicious website which overloads user’s GPUs. Furthermore, GPUs may host malware such as keyboard loggers that stealthily log keyboard activity for stealing sensitive data.
In fact, due to their computational capabilities, GPUs are used for accelerating encryption algorithms such as AES (advanced encryption standard). However, while GPU is performing encryption, an attacker can leak the key by launching a side-channel attack. For example, he can leverage the correlation between execution time and shared-memory conflicts or the number of coalesced accesses sent to global memory. Our recent survey paper reviews all these attacks, along with their countermeasures in more detail.
Security through obscurity: a mixed blessing
GPU vendors take “security-through-obscurity approach” for securing GPUs. While lack of knowledge about GPU microarchitecture makes it difficult for malicious agents to launch an attack, it also makes it difficult for researchers to propose security solutions. Evidently, security-through-obscurity approach, per se, is not sufficient for ensuring GPU security.
CPU based solutions: not enough
The decades of research on CPU security may be useful, but not sufficient, for designing GPU security solutions. After launching the program on the GPU, the CPU remains isolated and thus, it cannot monitor the execution of GPU. Hence, security mechanisms proposed on CPUs, such as a CPU taint-tracking scheme may not work for GPUs. For example, they may not detect a GPU-resident malware and thus, an attacker can load a compressed/encrypted code on GPU and then call a GPU kernel to quickly unpack/decrypt the code which starts working as a malware. Similarly, since a sharp increase in GPU load is likely to go undetected more easily compared to that in CPU load, a GPU malware is stealthier. Clearly, we need novel, GPU-specific solutions for ensuring its security.
The silver lining
Although these threats exist, there are also reasons which make it difficult to attack a GPU. With its huge number of threads, GPU can simultaneously perform multiple encryptions and hence, the timing of individual encryptions cannot be measured. This makes it more difficult to form accurate timing side-channel. Also, in a cloud environment, both the cloud and GPU architectures offer layers of obscurity which makes it difficult to launch an attack on GPUs. Further, some of the vulnerabilities in earlier GPU hardware/drivers have been addressed in their recent versions.
Nonetheless, the task of securing GPUs is a never-ending one since, while some researchers design a secure GPU or propose a security technique, others point out its vulnerabilities. Since even one loophole in security can be exploited to take full-control of the system, the goal of security requires the architects to be always on vigil!
Implications on the future processing units (PUs)
With the era of AI ushering in, nearly every leading vendor is designing their own custom PUs for accelerating AI applications, such as the tensor processing unit (TPU) from Google. Just as GPUs rose to prominence in the last decade, these PUs are also expected to break previous performance records in very near future. But before we get too far optimizing these PUs for performance, it is imperative that we design them with security as the first-class design constraint, instead of retrofitting for it. The experiences of and failures in securing GPUs can teach us a lot in this regard. Let us learn from the history, instead of repeating it!
About the Author
Sparsh Mittal received the B.Tech. degree in electronics and communications engineering from IIT, Roorkee, India and the Ph.D. degree in computer engineering from Iowa State University (ISU), USA. He worked as a Post-Doctoral Research Associate at Oak Ridge National Lab (ORNL), USA for 3 years. He is currently working as an assistant professor at IIT Hyderabad, India. He was the graduating topper of his batch in B.Tech and has received fellowship from ISU and performance award from ORNL. Sparsh has published more than 70 papers in top conferences and journals. His research interests include accelerators for machine learning, non-volatile memory, and GPU architectures. His webpage is http://www.iith.ac.in/~sparsh/