InSpectre: Breaking and Fixing Microarchitectural Vulnerabilities by Formal Analysis Roberto Guanciale Musard Balliu Mads Dam [email protected] [email protected] [email protected] KTH Royal Institute of Technology KTH Royal Institute of Technology KTH Royal Institute of Technology Stockholm SE-100 44, Sweden Stockholm SE-100 44, Sweden Stockholm SE-100 44, Sweden ABSTRACT security and effectiveness of the currently proposed countermea- e recent Spectre aacks have demonstrated the fundamental in- sures is unknown, and there are continuously new vulnerabilities security of current computer microarchitecture. e aacks use appearing that exploit specific microarchitecture features. features like pipelining, out-of-order and speculation to extract ar- It is important to note that side channels and functional correct- bitrary information about the memory contents of a process. A ness are to a large extent orthogonal. e laer is usually proved comprehensive formal microarchitectural model capable of repre- by reducing pipelined behaviour to sequential behaviour through senting the forms of out-of-order and speculative behavior that can some form of refinement-based argument. e past decades have meaningfully be implemented in a high performance pipelined ar- seen a significant body of work in this area, cf. [1, 8, 38, 47], ad- chitecture has not yet emerged. Such a model would be very useful, dressing rich sets of features of concrete pipeline designs such as as it would allow the existence and non-existence of vulnerabilities, OoO, speculation, and self-modifying code. Functional correctness, and soundness of countermeasures to be formally established. however, focuses on programs’ input-output behaviour and fails is paper presents such a model targeting single core proces- to adequately capture the differential aspects of speculation and sors. e model is intentionally very general and provides an in- instruction reordering that are at the root of Spectre-like vulner- frastructure to define models of real CPUs. It incorporates microar- abilities. For a systematic study of the laer we argue that new chitectural features that underpin all known Spectre vulnerabili- tools that are not necessarily tied to any specific pipeline architec- ties. We use the model to elucidate the security of existing and ture are needed. new vulnerabilities, as well as to formally analyze the effective- Along this line, several recent works [12, 14, 22, 40] have started ness of proposed countermeasures. Specifically, we discover three to propose formal microarchitectural models using information flow new (potential) vulnerabilities, including a new variant of Spectre analysis to identify information leaks arising from speculative exe- v4, a vulnerability on speculative fetching, and a vulnerability on cution in a principled manner. ese models capture specific spec- out-of-order execution, and analyze the effectiveness of existing ulation features, e.g, branch prediction, and variants of Spectre, countermeasures including constant time and serializing instruc- in particular variant 1, and design analyses that detect known at- tions. tacks [12, 22, 53]. While these approaches illustrate the usefulness of formal models in analyzing microarchitecture leaks, features ly- ing at the heart of modern CPUs such as OoO execution and many forms of speculation remain largely unexplored, implying that new 1 INTRODUCTION vulnerabilities may still exist. e wealth of vulnerabilities that have followed on from Spectre and Meltdown [31, 35] have provided ample evidence of the fun- Contributions. is work presents InSpectre, the first compre- damental insecurity of current computer microarchitecture. e hensive model capable of capturing OoO execution and all forms extensive use of instruction level parallelism in the form of out-of- of speculation that can be meaningfully implemented in the con- arXiv:1911.00868v2 [cs.CR] 17 Aug 2020 order (OoO) and speculative execution has produced designs with text of a high performance pipeline. e model is intentionally side channels that can be exploited by aackers to learn sensitive very general and provides an infrastructure to define models of information about the memory contents of a process. One witness real CPUs (Section 3), which can be used to analyze effectiveness of the subtlety of the issues is the more than 50 years passed since of countermeasures for a given processor. pipelining, caching, and OoO execution, cf. IBM S/360, was first Our first contribution is a novel semantics supporting microar- introduced. chitectural features such as OoO execution, non-atomicity of in- Another witness is the fact that two years aer the discovery structions, and various forms of speculation, including branch pre- of Spectre, a comprehensive understanding of the security impli- diction, jump target prediction, return address prediction, and de- cations of pipeline related microarchitecture features has yet to pendency prediction. Additionally, the semantics supports features emerge. One result is the ongoing arms race between researchers such as address aliasing, dynamic references, store forward, and discovering new Spectre-related vulnerabilities [9], and CPU ven- OoO memory commits, which are necessary to model all known dors providing patches followed by informal arguments [5]. e variants of Spectre. e semantics implements the stages of an abstract pipeline supporting OoO (Section 4) and speculative exe- cution (Section 5). In line with existing work [12, 22], our security Conference’17, Washington, DC, USA 2020. 978-x-xxxx-xxxx-x/YY/MM...$15.00 condition formalizes the intuition that optimizations should not in- DOI: 10.1145/nnnnnnn.nnnnnnn troduce additional information leaks (conditional noninterference, 1 Section 2). We use this condition to show that InSpectre can repro- e security condition defines the security of a program on the duce all four variants of Spectre. target execution model (e.g., the speculation model) −→t condition- As a second contribution, we use InSpectre to discover three ally on the security of the same program on the reference, i.e. se- new potential vulnerabilities. e first vulnerability shows that quential, model −→r , by requiring that the target model does not CPUs supporting only OoO may leak sensitive information. We leak more information than the reference model for a policy ∼. discovered the second vulnerability while aempting to validate Definition 2.1 (Conditional Noninterference). Let ∼ be a security a CPU vendor’s claim that microarchitectures like Cortex A53 are policy and −→ and −→ be transition relations for the target and immune to Spectre vulnerabilities because they support only spec- t r reference models of a system. e system is conditionally non- ulative fetching [5]. Our model reveals that this may not be the interferent if for all σ , σ ∈ States such that σ ∼ σ , if for ev- case. e third vulnerability is a variant of Spectre v4 showing 1 2 1 2 ery π = σ −→ ··· there exists π = σ −→ ··· such that that speculation of a dependency, rather than speculation of a non- 1 1 r 2 2 r trace(π ) = trace(π ) then for every ρ = σ −→ ··· there exists dependency as in Spectre v4, between a load and a store operation 1 2 1 1 t ρ = σ −→ ··· such that trace(ρ ) = trace(ρ ). may also leak sensitive information. 2 2 t 1 2 Finally, as a third contribution, we leverage InSpectre to analyze Conditional noninterference captures only the new information the effectiveness of some existing countermeasures. We found that leaks that may be introduced by model −→t , and ignores any leaks constant-time [7] analysis is unsound for processors supporting already present in model −→r . e target model is constructed only OoO, and propose a provably secure fix that enables constant- in two steps. First, we present an OoO model that extends the se- time analysis to ensure security for such processors. quential model, which is deterministic, by allowing evaluation to proceed out-of-order. en the OoO model is further extended by adding speculation. At each step the traces of the abstract model are included in the extended model, and a memory consistency re- sult demonstrates that the per location sequence of memory stores is the same for both models. is establishes functional correct- ness. Conditional noninterference then establishes security of each 2 SECURITY MODEL extension. Each such step strictly increases the set of possible Our security model has the following ingredients: (i) an execution traces by adding nondeterminism. Since refinement is oen viewed model which is given by the execution semantics of a program; as essentially elimination of nondeterminism, one can think of the (ii) an aacker model specifying the observations of an aacker; extensions as “inverse refinements”. Since conditional noninter- (iii) a security policy specifying the parts of the program state that ference considers a possibilistic seing, it does not account for contain sensitive/high information, and the parts that contain pub- information leaks through the number of initial indistinguishable lic/low information; (iv) a security condition capturing a program’s states. security with respect to an execution model, an aacker model, We now elucidate the advantages of conditional noninterfer- and a security policy. ence as compared to standard notions of noninterference and de- First, we consider a general model of aacker that observes the classification. Suppose we define the security condition directly on interaction between the CPU and the memory subsystem. is the target model, in the style of standard noninterference. model has been used (e.g., [3]) to capture information leaks via Definition 2.2 (Noninterference). Let P be a program with tran- cache-based side channels transparently without an explicit cache sition relation −→ and ∼ a security policy. P satisfies noninter- model. It can capture trace-driven aackers that can interleave P ference up to ∼ if for all σ , σ ∈ States such that σ ∼ σ and with the victim’s execution and indirectly observe, for instance us- P 1 2 1 P 2 executions π = σ −→· · · , there exists an execution π = σ −→· · · ing Flush+Reload [20], the victim’s cache footprint via latency jit- 1 1 2 2 such that trace(π ) = trace(π ).