A Survey of Techniques for Improving Security of GPUs <s> Protecting sensitive data using system management mode <s> Protecting the confidentiality of cryptographic keys in the event of partial or full system compromise is crucial for containing the impact of attacks. The Heartbleed vulnerability of April 2014, which allowed the remote leakage of secret keys from HTTPS web servers, is an indicative example. In this paper we present PixelVault, a system for keeping cryptographic keys and carrying out cryptographic operations exclusively on the GPU, which allows it to protect secret keys from leakage even in the event of full system compromise. This is possible by exposing secret keys only in GPU registers, keeping PixelVault's critical code in the GPU instruction cache, and preventing any access to both of them from the host. Due to the non-preemptive execution mode of the GPU, an adversary that has full control of the host cannot tamper with PixelVault's GPU code, but only terminate it, in which case all sensitive data is lost. We have implemented a PixelVault-enabled version of the OpenSSL library that allows the protection of existing applications with minimal modifications. Based on the results of our evaluation, PixelVault not only provides secure key storage using commodity hardware, but also significantly speeds up the processing throughput of cryptographic operations for server applications. <s> BIB001 </s> A Survey of Techniques for Improving Security of GPUs <s> Protecting sensitive data using system management mode <s> Abstract General-Purpose computing on a Graphics Processing Unit (GPGPU) involves leveraging commodity GPUs as massively parallel processing units. GPGPU is an emerging computing paradigm for high-performance and data-intensive computations such as cryptographic operations. Although GPGPU is an attractive solution for accelerating modern cryptographic operations, the security challenges that stem from utilizing commodity GPUs remain an unresolved problem. In this paper, we present an On-demand Bootstrapping Mechanism for Isolated cryptographic operations (OBMI). OBMI transforms commodity GPUs into a securely isolated processing core for various cryptographic operations while maintaining cost-effective computations. By leveraging System Management Mode (SMM), a privileged execution mode provided by x86 architectures, OBMI implements a program and a secret key into the GPU such that they are securely isolated during the acceleration of cryptographic operations, even in the presence of compromised kernels. Our approach does not require an additional hardware-abstraction layer such as a hypervisor or micro-kernel, and it does not entail modifying the GPU driver. An evaluation of the proposed OBMI demonstrated that even adversaries with kernel privileges cannot gain access to the secret key, and it also showed that the proposed mechanism incurs negligible performance degradation for both the CPU and GPU. <s> BIB002
Kim et al. BIB002 present a booting scheme which uses SMM for isolating the GPU kernel and key of cryptographic algorithms. Some works store the key in GPU registers BIB001 . However, since registers are not shared between threads, every thread needs to reserve multiple (32b) registers to store the key, which degrades performance by limiting the maximum number of kernels that can run concurrently. By comparison, storing the key in GPU cache is better since it cannot be accessed by any CPU application and its contents cannot be accessed after completion of GPU kernel. However, since the cache is hardware-managed, it is important to ensure that the key does not get evicted from the cache. To avoid this issue, they store the key in the constant cache before booting. However, by compromising the OS kernel, the adversary can launch code-injection attack to tamper GPU kernel code. To subvert this, they use SMM for isolating authenticated GPU kernel in instruction-cache. Thus, only SMI and trusted GPU kernel can access the key. Before the end of SMM, copies of kernel and key in GPU memory are cleared. After program completion, the results can be copied from GPU memory, but kernel-code and key are invalidated. The sensitive data is handled only in SMM, and thus, security is ensured. They note that the keys are always stored at a fixed address in GPU memory and based on this, the exact address for storing the keys in constant memory can be obtained. The size of L1/L2/L3 constant caches are 1KB/8KB/32KB, respectively and the L2/L3 caches are shared with instruction memory. Hence, if the total key size exceeds L1 constant cache capacity, it may get evicted. However, they note that keys are evicted only when total key size exceeds 47,520 bytes and thus up to 270 AES keys of 176 bytes each can be accommodated easily. During booting, security-unrelated and security-related tasks are performed in regular CPU mode and SMM, respectively. This reduces the overhead of SMI program and also allows leveraging the functionality of GPU driver and OS kernel which are suspended in SMM. Their technique protects the key even when the kernel is compromised and its performance penalty is negligible. The limitation of their technique is that an adversary with physical access to the processor can subvert secure memory using a cold-boot attack.