Data Oblivious ISA Extensions for Side Channel-Resistant and High Performance Computing

Abstract

Blocking microarchitectural (digital) side channels is one of the most pressing challenges in hardware security today. Recently, there has been a surge of effort that attempts to block these leakages by writing programs data obliviously. In this model, programs are written to avoid placing sensitive data-dependent pressure on shared resources. Despite recent efforts, however, running data oblivious programs on modern machines today is insecure and low performance. First, writing programs obliviously assumes certain instructions in today's ISAs will not leak privacy, whereas today's ISAs and hardware provide no such guarantees. Second, writing programs to avoid data-dependent behavior is inherently high performance overhead. This paper tackles both the security and performance aspects of this problem by proposing a Data Oblivious ISA extension (OISA). On the security side, we present ISA design principles to block microarchitectural side channels, and embody these ideas in a concrete ISA capable of safely executing existing data oblivious programs. On the performance side, we design the OISA with support for efficient memory oblivious computation, and with safety features that allow modern hardware optimizations, e.g., out-of-order speculative execution, to remain enabled in the common case. We provide a complete hardware prototype of our ideas, built on top of the RISC-V out-of-order, speculative BOOM processor, and prove that the OISA can provide the advertised security through a formal analysis of an abstract BOOM-style machine. We evaluate area overhead of hardware mechanisms needed to support our prototype, and provide performance experiments showing how the OISA speeds up a variety of existing data oblivious codes (including "constant time" cryptography and memory oblivious data structures), in addition to improving their security and portability.

ConTExT: A Generic Approach for Mitigating Spectre

“…Taram et al [85] defined all userspace memory and user input as secret. However, this can be very expensive, and consequently, Yu et al [101] proposed a less expensive annotation-based protection mechanism. While this is an important discussion, it is orthogonal to this work.…”

“…Besides annotation of secrets, it would also be possible to architecturally define groups of secrets, e.g., based on the data type as suggested by Carr and Payer [15], or by defining all userspace memory and user input as secret as proposed by Taram et al [85]. However, this can be very expensive, and consequently, related work is also investigating annotationbased protection mechanisms [101]. When the operating system loads the binary, memory regions containing the annotated secrets are marked nontransient.…”

Custos: Practical Tamper-Evident Auditing of Operating Systems Using Trusted Execution

“…G4 Log Availability. In addition to detecting violations of log integrity, the system should provide assurance of 2 CUSTOS' security in the context of micro-architectural side channels reduces to software in the TEE being able to protect secret keys during cryptographic routines (e.g., when calculating digital signatures), which is a well-studied and orthogonal problem [122], [103], [18], [12], [129], [125]. log availability.…”

Safecracker: Leaking Secrets through Compressed Caches

“…6). One option is to let software control compression (e.g., [91]), but this implies ISA changes, storage overheads to track which data should not be compressed, and requires programmers to correctly identify secrets. A different option is cache partitioning, which is non-trivial because compressed caches have decoupled tag and data arrays with different geometries (and both must be partitioned), and partitioning reduces compression ratio.…”

“…Prior work on Data Oblivious ISA extensions [91] briefly mentions the use of cache compression to defeat constant time/data oblivious programming, but does not go into details or allude to active cache compression attacks (Sec. 4).…”