Lena E. Olson

Border control: sandboxing accelerators

As hardware accelerators proliferate, there is a desire to logically integrate them more tightly with CPUs through interfaces such as shared virtual memory. Although this integration has programmability and performance benefits, it may also have serious security and fault isolation implications, especially when accelerators are designed by third parties. Unchecked, accelerators could make incorrect memory accesses, causing information leaks, data corruption, or crashes not only for processes running on the accelerator, but for the rest of the system as well. Unfortunately, current security solutions are insufficient for providing memory protection from tightly integrated untrusted accelerators. We propose Border Control, a sandboxing mechanism which guarantees that the memory access permissions in the page table are respected by accelerators, regardless of design errors or malicious intent. Our hardware implementation of Border Control provides safety against improper memory accesses with a space overhead of only 0.006% of system physical memory per accelerator. We show that when used with a current highly demanding accelerator, this initial Border Control implementation has on average a 0.15% runtime overhead relative to the unsafe baseline.

Security Implications of Third-Party Accelerators

Third-party accelerators offer system designers high performance and low energy without the market delay of in-house development. However, complex third-party accelerators may include vulnerabilities due to design flaws or malicious intent that are hard to expose during verification. Rather than react to each new vulnerability, it is better to proactively build defenses for classes of attacks. To inspire future work on defenses, this paper develops a taxonomy of accelerator vulnerabilities. We consider the cross product of threat types (confidentiality, integrity, and availability) with risk categories (configuration, computation, termination, accelerator memory accesses, system memory accesses, microarchitecture/coherence, exceptions/interrupts, and power), as well as whether processes can be vulnerable only if they use the offending accelerator (accelerator-scope threat) or even when running in the same system (system-scope threat). Our taxonomy draws attention to a grave problem that needs immediate attention from computer architects.

Crossing Guard: Mediating Host-Accelerator Coherence Interactions

Specialized hardware accelerators have performance and energy-efficiency advantages over general-purpose processors. To fully realize these benefits and aid programmability, accelerators may share a physical and virtual address space and full cache coherence with the host system. However, allowing accelerators -- particularly those designed by third parties -- to directly communicate with host coherence protocols poses several problems. Host coherence protocols are complex, vary between companies, and may be proprietary, increasing burden on accelerator designers. Bugs in the accelerator implementation may cause crashes and other serious consequences to the host system. We propose Crossing Guard, a coherence interface between the host coherence system and accelerators. The Crossing Guard interface provides the accelerator designer with a standardized set of coherence messages that are simple enough to aid in design of bug-free coherent caches. At the same time, they are sufficiently complex to allow customized and optimized accelerator caches with performance comparable to using the host protocol. The Crossing Guard hardware is implemented as part of the trusted host, and provides complete safety to the host coherence system, even in the presence of a pathologically buggy accelerator cache.

Probabilistic Directed Writebacks for Exclusive Caches

Energy is an increasingly important consideration in memory system design. Caches improve energy efficiency by decreasing execution time and reducing the number of main memory accesses, but they suffer from known inefficiencies: the last-level cache (LLC) tends to have a high miss ratio while simultaneously storing many blocks that are never referenced. Because these blocks are not referenced before eviction, we can write them directly to memory rather than to the LLC. To do so, we must predict which blocks will not be referenced. Previous approaches rely on additional state at the LLC and/or extra communication. We show that by predicting working set size per program counter (PC), we can decide which blocks have low probability of being referenced. Our approach relies on the insight that it is possible to makes this prediction based solely on the address stream as seen by the level-one data cache (L1D), eliminating the need to store or communicate PC values between levels of the cache hierarchy. We require no modifications to the LLC. Our approach uses Flajolet andMartins probabilistic counting to keep the state small: two additional bits per L1D block, with an additional 6KB prediction table. This approach yields a large reduction in number of LLC writebacks: 25% fewer for SPEC on average, 80% fewer for graph500, and 67% fewer for an in-memory hash table.