Border Control: Sandboxing Accelerators L. E. Olson, Jason Power, - PowerPoint PPT Presentation

Border Control: Sandboxing Accelerators L. E. Olson, Jason Power, Mark. D. Hill and David A.Wood University of Wisconsin-Madison Presented by : Yash Bhalgat, Arun Subramaniyan

Key Id Ideas and goals • Sharing memory between host and accelerators • Trade-off between security and performance • Performance and programmability v/s Bugs and malicious design • How to protect host memory from stray reads/writes of accelerators without compromising on the performance? • Propose Border Control: • Build upon the existing abstraction • Guarantees full host memory safety at trusted-untrusted interface • Low performance overhead (0.48%), low area overhead (0.006%)

Accelerators are pervasive .. ... Cryptographic accelerators, GPGPUs, accelerators for image processing, neural and approximate computing, database accelerators, user reconfigurable hardware, etc.

Accelerators are (b (becoming) programmable .. ... • Heterogeneous System Architecture (“HSA”) ( AMD and others ) • Unified virtual and physical memory • Pointer-is-a-pointer semantics • Avoids data copying • Increased performance of fine-grained sharing • Behavioural familiarity to programmers

But many accelerators are untrusted .. ... • Obtained from 3rd party vendors • May have bugs in design - e.g.: could cause a system crash by erroneously corrupting the OS data structures • May be malicious - unintentional hardware bugs can be exploited by an attacker (e.g.: MIPS R4000)

GPU leaks Guess which website left this data in the GPU texture memory? “Stealing Webpages Rendered on Your Browser by Exploiting GPU Vulnerabilities”, Lee et al. (Oakland ’14)

Threat Model • Identify, document and prioritize potential threats from a hypothetical attacker’s perspective • Answers questions like: • What are the most relevant threats ? • Is there an attack vector that might go unnoticed ? • Which are the most vulnerable components for attack?

Threat Model Threat Vector: Protect host from incorrect or malicious accelerators that could perform Addressed Threats: • stray reads, violating confidentiality • stray writes, violating integrity of host processes that do and do NOT run on the accelerator • Border Control treats accelerator as a black box

Principle of Least Privilege (f (for hardware) “Every hardware component of the system should operate using the least set of privileges necessary to complete the job.” This principle limits the damage that can result from an accident or error. Which permissions are allowed for an accelerator ? NOT to OS data NOT to sensitive data from other processes

Current Solutions Accel. Accel. CPU TLB $$ Direct Physical Address MMU $$ Memory or Shared LLC Address translation path Trusted data path Translation update path Untrusted data path

Current Solutions Accel. Accel. CPU TLB $$ Full IOMMU MMU $$ Full IOMMU Memory or Shared LLC Address translation path Trusted data path Translation update path Untrusted data path

Current Solutions Accel. Accel. CPU TLB TLB $$ $$ $$ Bypassable IOMMU x x $$ IOMMU Memory or Shared LLC Address translation path Trusted data path Translation update path Untrusted data path

Border Control Accel. Accel. CPU TLB TLB $$ $$ $$ Notify OS (terminate !!! $$ IOMMU process/disable accelerator) Memory or Shared LLC Address translation path Trusted data path Translation update path Untrusted data path

Comparison to other approaches *From paper

Protection table • 2 bits (R/W) per 4kB page vs 64 bits in process table Accel. Accel. CPU TLB TLB $$ $$ 1MB for 16GB memory $$ PPN $$ R W IOMMU 0 1 .. Memory or Shared LLC N

Border Control Cache • 8kB cache (64 entries, caches 32k 4kB page permissions) Accel. Accel. CPU TLB TLB $$ $$ $$ IOMMU+ $$ IOMMU BCC Memory or Shared LLC

Evaluation • Simulator: gem5-gpu • Moderately-threaded: single core • Highly-threaded: eight cores • Rodinia Benchmarks • Baseline: fast but unsafe bypassable IOMMU

Border Control Overheads Moderately-Threaded GPU Takeaway: Average 0.48% performance overhead

Border Control Overheads Highly-Threaded GPU Takeaway: Average 0.15% performance overhead

Conclusion • Third party accelerators can become a threat to security • Border control sandboxes accelerators and provides safe memory accesses at low performance and area overheads (0.006% extra memory)

Discussion • How does the proposed approach scale to a large number of accelerators ? (> 100 IP blocks). The paper proposes 1 protection table per accelerator. • Can the proposed approach be extended for tracking at much finer granularity (word, block..)? What are the challenges? • With cache coherent shared memory how can the host be protected from malicious/buggy coherence messages ?