Beyond Over-Protection: A Targeted Approach to Spectre Mitigation and Performance Optimization

Side channels are unintended information flow paths that are potentially exploitable by a malicious process to exfiltrate secrets from the memory of other processes. A prime example of side-channel vulnerabilities is Spectre attacks. These attacks are characterized by a speculation primitive (Miller, 2018), which enables an instruction that accesses a secret to supply it to a transient transmitter (Yu et al., 2019) that leaks it. Speculation primitive is some hardware mechanism that initiates speculative execution. Examples include control-flow instructions (e.g., conditional or indirect branches (Kocher et al., 2019), return instructions (Koruyeh et al., 2018)), which predict the intended value of the program counter and loads which predict the effective addresses of prior unresolved stores (Horn, 2018).

Spectre attacks usually leak data via data caches, which can be measured by an attacker using techniques such Flush+Reload (Yarom and Falkner, 2014). In Flush+Reload, the attacker flushes cache entries, allowing the victim to (normally or speculatively) execute a secret-dependent load, after which the attacker measures the reload time. This reloads time enables the attacker to determine if the victim has accessed any cache entries during its execution and subsequently enables the attacker to extract the secret.

Running example. We introduce the example of Fig. 2 to show the main concepts of our approach. The example is a simplified version of Case #10 from the benchmarks used in (Kocher, 2018; Guarnieri et al., 2020; Cauligi et al., 2020). The program consists of two nested conditional statements, where the first one checks the bound of an accessed index within the public array $A$. The load of the first element from the array $B$ is then decided by the inner if statement by checking whether or not the accessed value in $A$ based on the provided index is equal to $k$.

When the processor encounters the first if statement, based on its internal state and the pipeline load, it may decide to speculatively execute the read from the array $A$ even when $idx$ is greater or equal to $A\_size$. This potentially enables an attacker who controls the value of $idx$ and $k$ to get access to sensitive information inferred from the comparison in the inner condition. Specifically, the attacker can infer the value of data loaded in speculation by executing $A[idx]$ when the $B[0]$ shows up in the cache, indicating the condition in the inner if statement holds.

When analyzing the security of a program, it is essential to consider the security level of variables to get a precise understanding of the program leakage potential and decide the specific mitigation which must be applied. For instance, depending on whether $idx$ is deemed private or public, our running example leaks differently. While in the latter case, the leakage happens when the execution reaches $B[0]$, i.e., the inner conditional expression holds, the former case shows different leakage at the point $A[idx]$ is executed.

Spectre attacks can be mitigated through a combination of hardware and software measures. Using fence instructions or speculative load hardening are examples of such measures.

In the following, we use $s\in S$ to range over ISA states and we say that two states $s_{1}$ and $s_{2}$ are low-equivalent (i.e., $s_{1}=_{L}s_{2}$) iff they agree on every public register and memory location. We also say that two states $s_{1}$ and $s_{2}$ are indistinguishable iff an attacker cannot distinguish executions on real hardware that start from the same microarchitectural state and any states corresponding to $s_{1}$ and $s_{2}$. Intuitively, a system is free of side channels if low-equivalent states are also indistinguishable. That is, the attacker cannot learn anything from the channel that is not already public.

Since verification requires models, verifying the absence of leakage due to side channels requires a model capturing the channels. However, due to the complexity of modern processors, it is infeasible to explicitly model all the complex and intertwined microarchitectural features like cache hierarchies, cache replacement policies, as well as memory and buses. Abstract observational models, hereafter denoted by $\mathit{M}_{i}$, tackle this problem by overapproximating attacker capabilities. To this end, the abstract model of the system is extended with a set of possible observations $\mathit{o}\in\mathit{O}{}$, e.g., cache tag or set index, and a transition relation $\rightarrow\subseteq S\times\mathit{O}\times S$. For each such model, the observations represent the part of the processor state that may affect the channel at each transition.

For instance, in order to overapproximate the information leakage that may occur in Fig. 2 due to the presence of caches, the processor model may be extended with the observations that are shown in the right column: e.g., the execution of the first instruction of the non-optimised binary may leak the value of stack pointer plus 8. Intuitively, this model, say $\mathit{M}$, captures that the program execution time depends on the addresses of loads and instructions that are executed based on conditional branches. We say that two states $s,s^{\prime}\in S$ are observationally equivalent (i.e., $s\sim_{M}s^{\prime}$), iff for every possible trace $s\xrightarrow{\mathit{o}_{1}}s_{1}\dots\xrightarrow{\mathit{o}_{n}}s_{n}$ of $M$ there is a trace $s^{\prime}\xrightarrow{\mathit{o}_{1}^{\prime}}s^{\prime}_{1}\dots\xrightarrow{\mathit{o}_{n}^{\prime}}s^{\prime}_{n}$ such that $[\mathit{o}_{1},\dots,\mathit{o}_{n}]=[\mathit{o}_{1}^{\prime},\dots,\mathit{o}_{n}^{\prime}]$.

Clearly, we would like models to be sound, which means that observationally equivalent states should lead to executions that cannot be distinguished by an attacker on real hardware.

Sound observational models can be regarded as reliable foundations for side-channel analysis, since they allow to demonstrate the absence of side channels by statically proving that low-equivalent states are observationally equivalent. The problem with speculative execution is that observational models that do not take into account transient observations are unsound, and there is no general model of transient observations that covers all possible microarchitectures.

Scam-V (Nemati et al., 2020b, a; Buiras et al., 2021) combines techniques from program verification and fuzzing to perform relational testing and examine the soundness of observation models. At a high level (see Fig. 1), (1) it generates well-formed binary programs and (2) synthesizes a relation that, for a generated program, identifies states that are observationally equivalent according to the model under the validation. Then, (3) an instance of this relation in terms of two input states is generated. Finally, (4) Scam-V runs the generated binary with different input pairs on real hardware and compares the measurements on the side channel of the real processor. Since the generated inputs satisfy the synthesized relation, the soundness of the model would imply that the side-channel data on hardware cannot be distinguished either. Thus, a test case where we can distinguish the two runs on the hardware amounts to a counterexample (a potential side channel) that invalidates the observational model.

Scam-V uses the symbolic execution of programs that are annotated with observations to synthesize the equivalence relation. Symbolic execution is a technique to explore all program execution paths by using symbolic values instead of concrete ones for the inputs. Starting from an initial symbolic state, the execution explores all possible paths and collects the execution effects in a final symbolic state $\sigma\in\Sigma$ for each path. Each symbolic state $\sigma$ consists of a map from variables to symbolic expressions (i.e., where symbols represent initial state variables) and a path condition $p_{\sigma}$ (i.e., a symbolic expression identifying the condition that leads to the execution of that path). Scam-V also maintains a list of symbolic expressions $l_{\sigma}$, which collects the effects of observable statements that have been encountered. E.g., starting from an initial state which maps each register $x_{i}$ to a symbol $\alpha_{i}$ and the memory to $\alpha_{M}$, an empty list of observations, and a $true$ path condition, the symbolic execution of the -O2 program of Fig. 2 produces three final states:

• •

  one for $idx\geq A\_size$, where path condition $\alpha_{0}\geq\alpha_{M}[\alpha_{8}]$, state mapping $x_{8}\mapsto\alpha_{M}[\alpha_{8}]$, and observation list $[\alpha_{8};false]$,

• •

  one for $idx<A\_size$ and $A[idx]\neq k$, where path condition $\alpha_{0}<\alpha_{M}[\alpha_{8}]\land\alpha_{M}[\alpha_{0}+\#A]\neq\alpha_{1}$, state mapping $x_{8}\mapsto\alpha_{M}[\alpha_{0}]$, and observation list $[\alpha_{8};true;\alpha_{0}+\#A;false$],

• •

  one for $idx<A\_size$ and $A[idx]=k$, where path condition $\alpha_{0}<\alpha_{M}[\alpha_{8}]\land\alpha_{M}[\alpha_{0}+\#A]\neq\alpha_{1}$, state mapping $x_{8}\mapsto\alpha_{M}[\alpha_{0}+\#A],x_{10}\mapsto\alpha_{M}[\#B]$, and observation list $[\alpha_{8};true;\alpha_{0}+\#A;true;\#B]$.

Scam-V uses self composition (Barthe et al., 2004) to compute the observational equivalence relation by imposing equivalence of the symbolic observation list of the final states of the symbolic execution. For the example above, the relation would be as follows:

In order to drive the generation of test cases, we leverage observation refinement (see Sec. 2.3.1). However, the previous implementation of the refinement technique in Scam-V could only handle a single conditional branch and was insufficient for our tests. Thus, we generalized the observation refinement in Scam-V by introducing a new program transformation that simulates the speculative execution of program instructions. This refinement enables us to observe memory operations that happen in speculation.

Our experiments focus on branch prediction, but the technique is general enough to cover other types of speculation. We achieve refinement by choosing a set of branches that can be misspeculated and composing them with the program. This is in line with the Spectector approach, which uses the always misprediction policy (Guarnieri et al., 2020).

Our program transformation inlines a shadow copy of the program fragment starting from the execution point before the first misspeculation. We statically fix the size of these fragments to cover the largest expected speculative window of the processor. This shadow code (marked with ${}^{\star}$ in Fig. 3) is a copy of the original program fragment, where all selected misspeculating branches have negated conditions—to simulate what can happen in misspeculation. The shadow code also operates over a shadow machine state in order to not affect the non-speculative behavior. All memory operations executed in the shadow code raise a refined observation, indicating that they are possible causes of leakage.

Fig. 3 shows how this transformation works for our running example. In this example, we inline a shadow copy (code snippet between Start and End) of the program fragment starting from the ‘if’ statement with the negated condition. During the execution, we save the current program state at Start, switch to a shadow copy of the state, execute the shadow fragment and collect observations, and restore the normal execution of the program when we reach the execution point marked with End.

While our new implementation of the refinement technique can deal with more complex cases, e.g., programs with nested branches, it has some limitations, as shown in the snippet below. Since we negate all conditions in the shadow copies, in the example, we end up synthesizing relations that are unsatisfiable for the path that accesses memory in the inner ‘if’ statement’s true branch.

Possible solutions to this problem are to either apply refinement to only the inner ‘if’ statement or implement a heuristics that chooses the right ‘if’ statement (i.e., the one that makes the relation satisfiable) that needs to be refined. For complex scenarios, e.g., with nested branches and functions, similar heuristics could be designed to automatically try different combinations of branches to find optimal refinement settings. We have tried the former solution in our experiments in Sec. 5; e.g., to refine observations of Case #5 when compiled with -O2 enabled.

The refinement involves two observational models: the base model $\mathit{M}$ and its refined counterpart $\mathit{M}^{\prime}$. We follow the technique of Buiras et al. (Buiras et al., 2021) to optimize the process of computing the observations w.r.t. the two models. Say $l^{\mathit{M}}$ and $l^{\mathit{M}^{\prime}}$ are, respectively, the observation lists obtained by symbolically executing the program under the base and the refined models. As Fig. 3 shows $l^{\mathit{M}}\subseteq l^{\mathit{M}^{\prime}}$. Thus, we can implement a projection function $\pi$ that enables obtaining the symbolic observation list of the base model from the observation list of the refined model, i.e., $\pi(l^{\mathit{M}^{\prime}})=l^{\mathit{M}}$, without the need of executing symbolic execution twice.

To ensure that misprediction will happen in the desired branch, we must train the branch predictor. The standard observation model to check a program’s vulnerability to transient execution observes both the program counter and the address of memory operations. Therefore, each pair of test input states, i.e., two observational equivalent states, follow the same execution path and satisfy the same path condition $\mathbf{p}$. Based on this insight, to generate a training state, it is sufficient to find satisfying assignments for a different path $\mathbf{p^{\prime}}$ in the symbolic execution tree, where $\mathbf{p\neq p^{\prime}}$.

The state of microarchitectural features can impact the success of side-channel attacks such as Spectre, as it may affect the speculative execution process. The presence or absence of certain data in the cache, or the prediction made by the branch predictor, can alter the speculative execution path, leading to successfully mounting that attack or missing potential information leakage. As an instance, in our running example, the speculation of the nested branch can be affected by the presence of $A[idx]$ in the cache before executing the program. Therefore, tests that only start with an empty cache may not reflect the actual leakage of the processor (see Sec. 5.1.4). Furthermore, we have primed the branch predictor state by training it according to different training inputs that we generated based on symbolic execution of the test programs.

Given a program fragment to analyze, the base and the one with shadow observations represents two observational models: the first one models leakage of a non-speculative processor, and the latter models leakage of a processor that can leak information by speculatively executing all shadow instructions. Assuming that the fragment is large enough to fill the processor’s speculative window, the second model represents the worst-case scenario from a defense point of view, where all potential speculative memory operations must be protected.

On a real processor, the worst-case scenario is not usually possible: the processor may not be able to execute all the speculative instructions. For example, peculiarities of the program may prevent some cache misses, and inter-instruction dependencies may limit the ability of the processor to proceed with speculative execution.

We can generate different observational models by removing some of the shadow observations. We say that model $M_{1}$ refines model $M_{2}$ if any pair of states that is $\sim_{M_{2}}$, is also $\sim_{M_{1}}$. For example, it is easy to show that if model $M_{2}$ is obtained by removing a shadow observation of model $M_{2}$, then $M_{1}$ refines $M_{2}$. This forms a lattice of models, where the bottom corresponds to the original program and the top corresponds to the program with all shadow observations. Navigating this lattice can be used to identify which shadow observation (i.e., speculative instruction) causes the leakage and must be protected. To guide our optimizing slh hardening, we adopt this lattice structure. Intuitively, for a given program and on a specific processor, there is a hardened copy that is produced conservatively and fully protects against transient leakages. On the opposite side, we have a program that is not hardened and is vulnerable to transient leakages. Between these two, we can find many other partially hardened programs. Our technique is to walk—from the fully hardened version to not protected one—on this lattice to find a version of a program which is hardened with a maximally permissive set of fences, i.e., removing any additional hardening would lead to leakage of secret data in some form.

We would also like to avoid the introduction of protections against leakage of variables that are already public. For example, without knowing the classification of variables for the running example, we should consider the load at line 24 of the -O0 compilation potentially insecure, since it may leak the value of $idx$. However, if $idx$ is public, we should avoid generating experiments where the index differs in $s_{1}$ and $s_{2}$, since this may lead to useless experiments where the potential different cache footprint depends on public information. Therefore, we must allow users to possibly configure variable classification and add the constraint $s_{1}=_{L}s_{2}$ to the relation generated by Scam-V. We achieve this by allowing the user to add arbitrary initial observations to the translated program into the BIR language. Since Scam-V generates only pairs of states that are observationally equivalent, adding an initial observation for each public variable results in restricting Scam-V to generate only a pair of states that are low-equivalent.

The internal symbolic execution engine of Scam-V does not scale even to mid-size (more than ten instructions) programs, and the infeasible paths are not pruned in its execution tree. These render Scam-V impractical to analyze real-world programs; e.g., Spectre-PHT gadget extracted from OpenSSL in Sec. 5.2 consists of a series of conditional statements that cannot be handled by Scam-V’s symbolic execution. In order to resolve these issues, we have integrated Scam-V to angr (Shoshitaishvili et al., 2016)—a state-of-the-art binary analysis framework. This required several changes ranging from developing a new interface for communication between Scam-V and angr to modifying Scam-V’s pipeline to work with the angr generated symbolic execution tree.

We have run our test cases, each consisting of a program and two inputs, under seven different cache configurations, starting with an empty cache in the first iteration to mimic a cold start. However, for the subsequent iterations, we replicate a more realistic execution environment to account for the effects of cache hits and misses by constructing a cache state based on its content after the first iteration and randomly evicting cache lines. This is to ensure that speculative execution does not get trapped in other loads in the mispredicted branch and, with a higher probability, can reach interesting loads that leak secret data.

To ensure the consistency of our results for each cache configuration, we executed each experiment ten times, and we used the same cache state for runs starting from the two inputs. Unless all these ten executions give the same result, the experiment is classified as inconclusive. In order to resolve such cases, we inspect the cache state after each iteration and we keep the count of valid cache lines, which are populated by the program. Based on the collected data, a counterexample happens when a cache line was present in 70% of ten iterations in the cache state of one run, and it never appeared in the cache for the other run. In case all valid cache lines were present in the cache state of both runs at least once, we mark the experiment as conclusive when the total number of cache lines that were present in the cache state of both runs is at least 80% of the total number of all valid cache lines in both runs. We have chosen this threshold based on our statistical analysis to exclude outliers.

We have successfully analyzed 17 variants of Spectre and detected leakage in those that are vulnerable to Spectre-PHT on our evaluation processors. The only exceptions are cases #9 and its variation #9v2, which we could not analyze due to the limitation of our approach (Sec. 5.1.6 elaborates on this). Please note that specification-based testing and the use of observation refinement in Scam-V helped us to reduce the number of required test cases in our experiments.

We used clang with compiler optimizations -O0 and -O2 to produce the binary of microbenchmarks. We repeated the same experiments on both RPi boards that we have to check their vulnerability on these platforms and to protect them optimally. We identified several cases where compilers unnecessarily hardened programs. This provides opportunities for optimization without sacrificing security. Table 1 summarizes the results of our experiments for the benchmark programs. Our evaluation is done under the assumption that the code is executed standalone and no other code or vector of attacks is allowed. Note that the microbenchmarks represent different versions of Spectre-PHT at the source code level. However, when compiling with optimization -O2 enabled, sometimes the same binaries are produced for different cases, e.g. Case #1 and Case #13.

To show Scam-V scales to real-world case studies, we used Spectre-PHT gadgets in OpenSSL v3.1.0 that had been discussed in (Mosier et al., 2022b). Among the three vulnerable gadgets, namely EVP_PKEY_asn1_get0, ts_check_status_info and SSL_get_shared_sigalgs, Scam-V identifies only SSL_get_shared_sigalgs (due to a leakage at line #44 in the snippet below) to be vulnerable on actual hardware (see Table 2). Others did not trigger speculation as the speculation primitive’s (i.e., branch condition) operands were already loaded into the cache by the code executed before the if statement. To protect against SSL_get_shared_sigalgs leakage, we initially applied the default LLVM slh countermeasure. However, employing slh solely on loaded values did not mitigate the leakage. Subsequently, by adopting slh on the memory load addresses, we could stop the leakage.