Vulnerable GPU Memory Management: Towards Recovering Raw Data from GPU

Zhou, Zhe; Diao, Wenrui; Liu, Xiangyu; Li, Zhou; Zhang, Kehuan; Li, Rui

doi:10.1515/popets-2017-0016

Cited by 26 publications

(7 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In CURE, peripherals can either be assigned exclusively to a single enclave, by the SM, at enclave setup or shared between different enclaves and/or the OS. The peripheral's internal memory is flushed by the SM when (re-)assigned to a new entity to prevent information leakage [49,72,107]. Protecting virtual machines.…”

Section: Kernel-space Enclavesmentioning

confidence: 99%

CURE: A Security Architecture with CUstomizable and Resilient Enclaves

Bahmani¹,

Brasser²,

Dessouky³

et al. 2020

Preprint

View full text Add to dashboard Cite

Security architectures providing Trusted Execution Environments (TEEs) have been an appealing research subject for a wide range of computer systems, from low-end embedded devices to powerful cloud servers. The goal of these architectures is to protect sensitive services in isolated execution contexts, called enclaves. Unfortunately, existing TEE solutions suffer from significant design shortcomings. First, they follow a one-size-fits-all approach offering only a single enclave type, however, different services need flexible enclaves that can adjust to their demands. Second, they cannot efficiently support emerging applications (e.g., Machine Learning as a Service), which require secure channels to peripherals (e.g., accelerators), or the computational power of multiple cores. Third, their protection against cache side-channel attacks is either an afterthought or impractical, i.e., no fine-grained mapping between cache resources and individual enclaves is provided.In this work, we propose CURE, the first security architecture, which tackles these design challenges by providing different types of enclaves: (i) sub-space enclaves provide vertical isolation at all execution privilege levels, (ii) userspace enclaves provide isolated execution to unprivileged applications, and (iii) self-contained enclaves allow isolated execution environments that span multiple privilege levels. Moreover, CURE enables the exclusive assignment of system resources, e.g., peripherals, CPU cores, or cache resources to single enclaves. CURE requires minimal hardware changes while significantly improving the state of the art of hardwareassisted security architectures. We implemented CURE on a RISC-V-based SoC and thoroughly evaluated our prototype in terms of hardware and performance overhead. CURE imposes a geometric mean performance overhead of 15.33% on standard benchmarks. This paper will be published in the proceedings of the 30th USENIX Security Symposium (USENIX Security '21 ).1 TEE architectures for resource-constrained embedded systems (e.g., Sancus [66], TyTAN [8], TrustLite [47] or TIMBER-V [98]) are not the subject of this paper.

show abstract

Section: Kernel-space Enclavesmentioning

confidence: 99%

CURE: A Security Architecture with CUstomizable and Resilient Enclaves

Bahmani¹,

Brasser²,

Dessouky³

et al. 2020

Preprint

View full text Add to dashboard Cite

show abstract

“…Pix-elVault [64] exploits physical isolation between CPUs and GPUs to implement secure key storage for keys, although it was shown to be insecure [79]. Attacks leveraging GPU memory reuse without re-initialization [17,35,78] are a common theme. Techniques to isolate malicious device drivers [8], protect the system from malicious accelerators [48], or provide trusted I/O paths for accelerators [29,71,77] are applicable to securing GPUs as well.…”

Section: Background and Related Workmentioning

confidence: 99%

Isolation and Beyond

Hunt

Jia

Miller

et al. 2019

Proceedings of the Workshop on Hot Topics in Operating Systems

View full text Add to dashboard Cite

System security has historically relied on hardware-provided isolation primitives. However, Meltdown [36] and Spectre [30] demonstrate that basic user/kernel isolation could be bypassed in every widely deployed ISA for decades; they are a caution to system designers who accept hardware isolation guarantees as an article of faith. Hardware isolation is fallible and should be considered fallible by software systems. We argue that future systems should broaden their view to adopt techniques that compensate for weaknesses in hardware isolation and should secure and optimize the communication among isolated components. Changing algorithms to be data oblivious, so that their externally observable behavior is independent of their (secret) input data is one such technique. Securing communication requires that the timing and size of messages be independent of secret data, but how best to achieve that independence so as to limit performance and energy overheads will vary from application to application. * CCS Concepts• Security and privacy → Systems security; Operating systems security;

show abstract

“…Similarly, in mission-critical applications where GPUs store and process sensitive data, an attack on them can have huge financial and social consequences. For example, Zhou et al [19] demonstrate extraction of credit card numbers and email contents from remanent data in GPU memory. Also, in companies, a malicious insider may access classified documents which were opened on a shared GPU by an authorized user.…”

Section: Lack Of Documentation and Open-source Toolsmentioning

confidence: 99%

“…Zhou et al [19] discuss an attack on GPU where a nonprivileged adversary can leak sensitive information from the remanent raw data in GPU memory. They first detect data partitions which have a high likelihood of being parts of images.…”

Section: End Of Contextmentioning

confidence: 99%

A Survey of Techniques for Improving Security of GPUs

et al. 2018

View full text Add to dashboard Cite

Graphics processing unit (GPU), although a powerful performance-booster, also has many security vulnerabilities. Due to these, the GPU can act as a safe-haven for stealthy malware and the weakest 'link' in the security 'chain'. In this paper, we present a survey of techniques for analyzing and improving GPU security. We classify the works on key attributes to highlight their similarities and differences. More than informing users and researchers about GPU security techniques, this survey aims to increase their awareness about GPU security vulnerabilities and potential countermeasures.

show abstract

Vulnerable GPU Memory Management: Towards Recovering Raw Data from GPU

Cited by 26 publications

References 15 publications

CURE: A Security Architecture with CUstomizable and Resilient Enclaves

CURE: A Security Architecture with CUstomizable and Resilient Enclaves

Isolation and Beyond

A Survey of Techniques for Improving Security of GPUs

Contact Info

Product

Resources

About