Digital Log

    Spectre-Review

    Name: Samuel Tay
    UW Net ID: tays
    Paper: Spectre Attacks: Exploiting Speculative Execution
    Authors: Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Mortiz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, Yuval Yarom

    Paper Review

    • Problem: The problem presented in this paper is that speculative execution, a performance technique used by a large array of AMD and ARM processors, can be exploited to extract otherwise-unavailable secret information. More specifically, speculative execution is a technique wherein a CPU core will "speculate" on future program branches, and execute instructions that may or may not actually be what the program ends up instructing the CPU to execute. If the speculation is correct, there can be huge performance gains. Otherwise, the computation is "discarded"; however, it's not really discarded as such speculatively executed instructions may leave behind data in caches.
    • Approach: The so-called Spectre attacks presented in this paper involve a victim program with sensitive data in-memory, an attacker program which pathologically mistrains a processor to favor a particular branch outcome, manipulates cache state to induce speculative execution, and the processor then speculatively executes instructions that transfer confidential information from the victim address space into a cache. Note that this execution can be, e.g., an illegal memory access; it is speculative, so no exception will be reaised. Finally, a known technique such as Flush/Evict+Reload extracts this information from the cache. They also detail a second variant which is very similar, except the speculative execution is actually of code shared among processes (e.g. such as dynamically linked libs). The approach is analogous to return-oriented programming, causing different bits of executable code to execute via speculative execution; but in the end, the attacker must exfiltrate data via a side channel (like the cache). Also, each of the malicious executions has very little time / number of instructions that can actually execute, before the processor realizes that it speculated incorrectly.
    • Conclusions: The conclusion of the paper is, in some sense, a finger-pointing accusation at the hardware community. Software security depends on a shared understanding between software and hardware as to what information CPUs can and cannot expose when computing. Speculative execution violates the previously accepted notion that processors faithfully execute program instructions, and that software developers can trust their safety checks: if (false) {send_nukes();}. The authors point out that this is part of a longer on-going trend to maximize performance at the cost of security, and that these design choices may need to be revisited as the cost of security failures rises.
    • New ideas: This is the first paper detailing specific exploits against speculative execution, so it contains many new ideas. Specifically the outline of the attacks, priming of the mis-speculated executions, and the priming of the cache so that the speculatively executed code leaves data behind. Also the many different variants, e.g. in Javascript/Chrome, eBPF. It was great to read this paper now though, because we also got to see ideas that aren't new. This work builds on other things we've discussed in class, like return-oriented programming, and pre-existing side-channel attacks on low level caches.
    • Improvements: This paper gets an A+ from me. Finally, authors that include source code! It was great to see a full end-to-end example in the appendix. I also appreciated the level of detail in the Background section, which made it much easier to understand the rest of the paper.
    • New directions: One new direction on the software side would be to have further research on mitigation. For hardware, assuming that we are unlikely to have wholesale removal of speculative execution at the cost of performance, perhaps some performance could be sacrificed by having a safer version of speculative execution. This could be either a) fully speculative branch execution, but with more guarantees on side effects, or b) a restricted set of speculative execution, wherein only branches that are "safe" to speculatively execute get speculated. Option (a) should be accompanied by some formal verification. Option (b) seems unlikely to generalize without more primitives built-in to languages, compilers, and their resulting instructions.