Within a span of just a few years, we have gone from completely trusting our hardware to realising that everything is broken and all our security guarantees are built on sand. Memory chips have fundamental (Rowhammer) flaws that allow attackers to modify data without accessing it and CPUs are full of side channels and transient execution problems that lead to information leakage across pretty much all security boundaries. Combined, these issues have led to a string of high-profile attacks. In this talk, I will discuss some of the developments in such attacks, mostly by means of the attacks in which our group was involved. Although the research was exciting, I will argue that the way we conduct security research on hardware is broken. The problem is that the interests of hardware manufacturers and academics do not align and this is bad for everyone.
The Spectre attacks have demonstrated the fundamental insecurity of current computer microarchitecture. The attacks use features like pipelining, out-of-order and speculation to extract arbitrary information about the memory contents of a process. A comprehensive formal microarchitectural model capable of representing the forms of out-of-order and speculative behavior that can meaningfully be implemented in a high performance pipelined architecture has not yet emerged. Such a model would be very useful, as it would allow the existence and non-existence of vulnerabilities, and soundness of countermeasures to be formally established. We present such a model targeting single core processors. The model is intentionally very general and provides an infrastructure to define models of real CPUs. It incorporates microarchitectural features that underpin all known Spectre vulnerabilities. We use the model to elucidate the security of existing and new vulnerabilities, as well as to formally analyze the effectiveness of proposed countermeasures. Specifically,we discover three new (potential) vulnerabilities, including a new variant of Spectre v4, a vulnerability on speculative fetching, and a vulnerability on out-of-order execution, and analyze the effectiveness of existing countermeasures including constant time and serializing instructions.