Share this post:
Ever since the discovery of Spectre and Meltdown at the beginning of 2018, my team at IBM Research – Zurich and I have been focusing very closely on the study of transient execution attacks. Beginning that journey, we quickly realized that in order to study transient execution attacks, we first needed to observe and understand what transient execution actually is: what is the central processing unit (CPU) doing exactly?
It turns out, however, that observing the behavior of the CPU with respect to transient execution is no simple feat. Transient execution takes place whenever the CPU is unable to proceed and would have to stop and wait.
Coffee and CPUs
Let me use an analogy to explain. Imagine being in coffee shop where several regular customers (the user) keep coming back and ordering the same style of coffee (the program). As soon as the barista (our CPU) sees them coming, to save time, he starts preparing their usual order even before they place the order. This would generally save time for the customers, assuming the predictions are correct. Though, it may happen that a customer decides to try something else one day, and in that case, the coffee prepared by the barista has to be discarded. How does this relate to CPUs? The idea is that the customer does not see when something is discarded, but only receives the correct new order because the preparation happens behind the counter (our micro-architecture). Essentially, the customer can only see the top counter exchange (our architecture).
On a computer, the CPU basically “takes a guess” about what it does not yet know. If the guess is correct, we have safely improved performance. If not, the CPU has to backtrack, undo all operations that took place and start over. Clearly the undoing has to be thorough and complete, otherwise the application would produce the wrong result. It so happens that while this undoing preserves the correctness of all our applications, it still leaves traces that a skilled attacker can exploit to their advantage. What’s more, a skilled attacker may lead the CPU to make wrong guesses, thus forcing the CPU to leave traces that are even more useful to an attacker. This is what Spectre and Meltdown taught us.
A Microscopic View
Unfortunately, it is very hard to precisely describe and quantify what these traces really are and under which conditions they are left. There is no manual that describes the details of transient execution, as the information is proprietary to the various CPU manufacturers. Due to all the cyber attacks, we now know a bit more, although we are far from seeing the full picture. What makes it difficult is that there is not even a tool, or a methodology to perform this type of investigation. It is like trying to study microbiology without a microscope.
It turns out, we just needed to build a microscope. To build it, we started looking at all the information the CPU itself provides to developers. We immediately concentrated on the Performance Monitor Counters interface that all modern CPUs offer. In fact, this interface was designed for a different purpose altogether, namely to study various characteristics of software performance. Our first main contribution was that we were able to identify how to reliably use performance counter to understand speculative execution. In particular, we were able to identify which of these counters can be used as markers within a speculative executed snippet of code. A marker refers to any instruction or series of instructions that is detectable by these performance counters, even if the instruction ends up being executed as part of a wrong “guess” by the CPU, and thus later undone.
The architecture of the Speculator tool.
The Speculator Tool
DoubleBTI attacks are difficult to detect and have a high success rate.
To be able to perform our analyses using the markers we designed and implemented Speculator. Speculator is a tool – our microscope – based on performance counters. With Speculator, we are able to write tests program where a series of instructions are speculatively executed. Then using the markers, we can verify their behaviors within. Speculator is also able to study attacks where an attacker process leaks through speculative execution secret information from a victim. This tool has allowed us to verify and study different micro-architectural behaviors like nested speculative execution, various speculation window sizes and more.
Armed with our microscope, we have discovered new classes of attacks [2,3], including two new variants of Spectre v2 attacks: one that uses the instruction cache (Icache) and the another that uses a branch predictor, which is known as doubleBTI.
Hidden Secrets Revealed
Let’s go back to our coffee shop in order to understand how these new kinds of attack work. During an attack, a malicious customer (the attacker) guesses what is about to happen simply by peeking behind the counter (a side channel) to see what ingredients the barman uses to prepare a speculative coffee order in comparison to an order another customer just picked up. Some ingredients might have only been used for this specific order and nothing else, which differentiates the order from previous ones.
But if the attacker can identify the traces of ingredients left behind on the counter, a particular series of instructions is also traceable. By inference, the attacker can imagine the steps needed to prepare the order (e.g. boil water, grind the coffee beans, add a shot of cream etc., or for a sandwich, cut ham, salad and tomatoes, spread mayo etc.). In a CPU, where instructions are executed speculatively, it is the instructions that leave traces in the caches. Attackers privy to such traces can reveal the secret those particular instructions compute. Essentially, they unveil not just what’s in the secret sauce, but also how it’s made, where the ingredients come from and how it’s best used.
The Speculator research paper will be published at the Annual Computer Security Applications Conference 2019 (ACSAC)  and the tool has received the ACM Reusable Badge for the reproducibility of the results and its extensibility. We made the tool available for free on an open source community to enable other research teams to discover new attacks and develop counter defense technologies.
At our Zurich lab, we have formed a new team with strong emphasis on system security research, so stay tuned for updates from us in the future.
 – Andrea Mambretti, Matthias Neugschwandtner, Alessandro Sorniotti, Engin Kirda, William Robertson, Anil Kurmus. “Speculator: A Tool to Analyze Speculative Execution Attacks and Mitigations”. To appear in ACSAC’19, https://andreamambretti.com/files/papers/acsac2019_speculator.pdf
 – Atri Bhattacharyya, Alexandra Sandulescu, Matthias Neugschwandtner, Alessandro Sorniotti, Babak Falsafi, Mathias Payer, and Anil Kurmus. “SMoTherSpectre: exploiting speculative execution through port contention.” To appear in ACM CCS’19, https://arxiv.org/abs/1903.01843
 – Andrea Mambretti, Alexandra Sandulescu, Matthias Neugschwandtner, Alessandro Sorniotti, Anil Kurmus. “Two methods for exploiting speculative control flow hijacks”. WOOT @ USENIX Security Symposium 2019