MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols

The recent Meltdown and Spectre attacks highlight the importance of automated verification techniques for identifying hardware security vulnerabilities. We have developed a tool for synthesizing microarchitecture-specific programs capable of producing any user-specified hardware execution pattern of interest. Our tool takes two inputs: a formal description of (i) a microarchitecture in a domain-specific language, and (ii) a microarchitectural execution pattern of interest, e.g. a threat pattern. All programs synthesized by our tool are capable of producing the specified execution pattern on the supplied microarchitecture. We used our tool to specify a hardware execution pattern common to Flush+Reload attacks and automatically synthesized security litmus tests representative of those that have been publicly disclosed for conducting Meltdown and Spectre attacks. We also formulated a Prime+Probe threat pattern, enabling our tool to synthesize a new variant of each---MeltdownPrime and SpectrePrime. Both of these new exploits use Prime+Probe approaches to conduct the timing attack. They are both also novel in that they are 2-core attacks which leverage the cache line invalidation mechanism in modern cache coherence protocols. These are the first proposed Prime+Probe variants of Meltdown and Spectre. But more importantly, both Prime attacks exploit invalidation-based coherence protocols to achieve the same level of precision as a Flush+Reload attack. While mitigation techniques in software (e.g., barriers that prevent speculation) will likely be the same for our Prime variants as for original Spectre and Meltdown, we believe that hardware protection against them will be distinct. As a proof of concept, we implemented SpectrePrime as a C program and ran it on an Intel x86 processor, averaging about the same accuracy as Spectre over 100 runs---97.9% for Spectre and 99.95% for SpectrePrime.

[1]  Margaret Martonosi,et al.  CCICheck: Using μhb graphs to verify the coherence-consistency interface , 2015, 2015 48th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO).

[2]  Emina Torlak,et al.  Synthesizing memory models from framework sketches and Litmus tests , 2017, PLDI 2017.

[3]  Gernot Heiser,et al.  A survey of microarchitectural timing attacks and countermeasures on contemporary hardware , 2016, Journal of Cryptographic Engineering.

[4]  Margaret Martonosi,et al.  RTLCheck: Verifying the Memory Consistency of RTL Designs , 2017, 2017 50th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO).

[5]  Emina Torlak,et al.  Kodkod: A Relational Model Finder , 2007, TACAS.

[6]  Margaret Martonosi,et al.  PipeCheck: Specifying and Verifying Microarchitectural Enforcement of Memory Consistency Models , 2014, 2014 47th Annual IEEE/ACM International Symposium on Microarchitecture.

[7]  Jade Alglave,et al.  Fences in Weak Memory Models , 2010, CAV.

[8]  Sridhar Narayanan,et al.  TSOtool: a program for verifying memory systems using the memory consistency model , 2004, Proceedings. 31st Annual International Symposium on Computer Architecture, 2004..

[9]  David A. Wood,et al.  A Primer on Memory Consistency and Cache Coherence , 2012, Synthesis Lectures on Computer Architecture.

[10]  Daniel Lustig,et al.  Automated Synthesis of Comprehensive Memory Model Litmus Test Suites , 2017, ASPLOS.

[11]  Jade Alglave,et al.  Litmus: Running Tests against Hardware , 2011, TACAS.

[12]  Margaret Martonosi,et al.  COATCheck: Verifying Memory Ordering at the Hardware-OS Interface , 2016, ASPLOS.

[13]  Margaret Martonosi,et al.  TriCheck: Memory Model Verification at the Trisection of Software, Hardware, and ISA , 2016, ASPLOS.