Efficient invisible speculative execution through selective delay and value prediction

Abstract

Speculative execution, the base on which modern high-performance general-purpose CPUs are built on, has recently been shown to enable a slew of security attacks. All these attacks are centered around a common set of behaviors: During speculative execution, the architectural state of the system is kept unmodified, until the speculation can be verified. In the event that a misspeculation occurs, then anything that can affect the architectural state is reverted (squashed) and re-executed correctly. However, the same is not true for the microarchitectural state. Normally invisible to the user, changes to the microarchitectural state can be observed through various sidechannels, with timing differences caused by the memory hierarchy being one of the most common and easy to exploit. The speculative side-channels can then be exploited to perform attacks that can bypass software and hardware checks in order to leak information. These attacks, out of which the most infamous are perhaps Spectre and Meltdown, have led to a frantic search for solutions.In this work, we present our own solution for reducing the microarchitectural state-changes caused by speculative execution in the memory hierarchy. It is based on the observation that if we only allow accesses that hit in the L1 data cache to proceed, then we can easily hide any microarchitectural changes until after the speculation has been verified. At the same time, we propose to prevent stalls by value predicting the loads that miss in the L1. Value prediction, though speculative, constitutes an invisible form of speculation, not seen outside the core. We evaluate our solution and show that we can prevent observable microarchitectural changes in the memory hierarchy while keeping the performance and energy costs at 11% and 7%, respectively. In comparison, the current state of the art solution, InvisiSpec, incurs a 46% performance loss and a 51% energy increase.

Clearing the Shadows

“…Completely disabling speculative execution would solve all speculative side-channel attacks, but it would come at an unacceptable performance cost. Instead, the selective delay solution proposed by Sakalis et al [30] reduces the observable micro-architectural statechanges in the memory hierarchy while trying to delay speculative instructions only when it is necessary. Specifically, only loads are delayed, as other instructions (such as stores) are not allowed to cause any changes in the memory hierarchy while speculative.…”

“…The authors introduce the concept of speculative shadows [29,30] to understand when a load is considered to be speculative. Traditionally, any instruction that has not reached the head of the reorder buffer might be considered speculative, but speculative shadows offer a more fine-grained approach.…”

“…Each benchmark is represented by a number of hot regions that were identified through profiling (for more information on the selection of regions for evaluation see Section 4). On average the delay of loads incurs a 23% performance degradation compared to Table 1: Examples for shadow types identified by Sakalis et al [30]. In each example, the load instruction in y = ... is under a shadow cast by the previous instruction.…”

“…In our example, the speculative access to array [10000] would therefore not return a value that can be used to leak the secret. While secure, such mechanisms suffer from reduced performance [30,36,39]. Being able to execute (speculative) loads in parallel and out-of-order is crucial for performance.…”

“…(b) An instruction reordering technique that exposes more MLP through (i) prioritizing instructions that contribute to unresolved memory operations and unresolved branches, and through (ii) scheduling independent instructions in groups. (2) The evaluation of our extension on top of the state-of-theart Delay-on-Miss security mechanism [30], which delays speculative loads that miss in the L1 cache.…”