TDT09 Topic 13


Side channel effects: the cost of Spectre

The Meltdown [1] and Spectre [2] security vulnerabilities uncovered in late 2017 are caused by an architectural design flaw in superscalar microprocessors performing branch prediction since the original Intel Pentium. In addition to current x86 CPUs, other architectures, such as ARM Cortex A57/72/73 and some IBM Power processors, are also affected. A Spectre-based attack can extract data from protected memory addresses (of different processes as well as the kernel) due to a side-channel attack which exposes observable data (e.g. the information if the contents of a memory address are still cached, which can be determined by a timing analysis) to the attacker.

Spectre is not a single attack, but rather encompasses a class of attacks which use the same basic vulnerability. Accordingly, there is no single effective mitigation for Spectre. While ultimately, a hardware fix to constrain speculation would be the optimal option, this would limit speculation and, accordingly, reduce the achievable speedup by speculation. Software mitigations have the advantage that they work with existing hardware and that they can be selectively enabled on critical systems [3] (e.g. systems not connected to the Internet might disable the mitigations).

However, software mitigations also have significant impact on the performance of a computer system [7]. The first mitigation, proposed by Google, was retpoline" [4]. Mitigations can not only be performed in the OS, but also in compilers [6]. There are more recent mitigations, such as DAWG (Dynamically Allocated Way Guard) [8] and Context-Sensitive Fencing [9], which promise to provide improved protection against Spectre without compromising performance.

In general, Spectre mitigations in software face a trade-off between effectiveness (how well do they protect against Spectre-based attacks) and efficiency (which performance costs does a method incur). Thus, an overview of the differenct compile- and runtime software-based approaches is useful to have and might also give an insight into possible hardware-/software co-designed approaches for side-channel effect mitigations.

References

  1. Moritz Lipp et al., Meltdown: Reading Kernel Memory from User Space, 27th USENIX Security Symposium 2018 pdf
  2. Paul Kocher et al., Spectre Attacks: Exploiting Speculative Execution, 2019 IEEE Symposium on Security and Privacy (SP), pdf
  3. Linus Torvalds, Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation. linux-kernel (Mailing list)link
  4. Intel, Intel Analysis of Speculative Execution Side Channels" (PDF) (White Paper). Revision 1.0 (336983–001), January 2018 pdf
  5. Esmaeil Koruyeh et al., Spectre Returns! Speculation Attacks using the Return Stack Buffer, USENIX WOOT 2018pdf
  6. Guanhua Wang et al., oo7: Low-overhead Defense against Spectre Attacks via Binary Analysis, arXiv preprint pdf
  7. A. Prout et al., Measuring the Impact of Spectre and Meltdown, 2018 IEEE High Performance extreme Computing Conference (HPEC) link
  8. Vladimir Kiriansky et al., DAWG: A Defense Against Cache Timing Attacksin Speculative Execution Processors, IEEE MICRO 2018 link
  9. Mohammadkazem Taram, Context-Sensitive Fencing: Securing SpeculativeExecution via Microcode Customization, ASPLOS 2019 pdf