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
• f 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. NOT to OS data NOT to sensitive data from other processes Which permissions are allowed for an accelerator ?

Current Solutions

CPU $$ $$

Memory or Shared LLC

MMU TLB

Accel. Trusted data path Untrusted data path Address translation path Translation update path Accel.

Direct Physical Address

Current Solutions

CPU $$ $$

Memory or Shared LLC

MMU TLB

Accel. Trusted data path Untrusted data path Address translation path Translation update path Accel.

Full IOMMU

Full IOMMU

Current Solutions

Trusted data path Untrusted data path Address translation path Translation update path

Bypassable IOMMU

CPU $$

Memory or Shared LLC

$$

TLB

Accel. $$

TLB

Accel. $$

IOMMU

x x

Border Control

Trusted data path Untrusted data path Address translation path Translation update path CPU $$

Memory or Shared LLC

$$

TLB

Accel. $$

TLB

Accel. $$

IOMMU

!!!

Notify OS (terminate process/disable accelerator)

Comparison to other approaches

*From paper

Protection table

• 2 bits (R/W) per 4kB page vs 64 bits in process table

CPU $$

Memory or Shared LLC

$$

TLB

Accel. $$

TLB

Accel. $$

IOMMU

R W

PPN N 1 .. 1MB for 16GB memory

Border Control Cache

• 8kB cache (64 entries, caches 32k 4kB page permissions)

CPU $$

Memory or Shared LLC

$$

TLB

Accel. $$

TLB

Accel. $$

IOMMU

IOMMU+ BCC

Evaluation

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

Border Control Overheads

Takeaway: Average 0.48% performance overhead

Moderately-Threaded GPU

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 ?