This blog post summarizes my recent keynote talk at the 2022 IEEE International Symposium on Secure and Private Execution Environment Design (SEED). The talk shares some of my humble opinions about the current microarchitecture security research landscape and points out a few research directions worth exploring. These opinions are not intended to be comprehensive.
The Age of Pervasive Microarchitectural Attacks
Even though microarchitecture security, as a research topic, has existed since the 1970s, it was until 2018, when Spectre and Meltdown were discovered, this research topic got huge media coverage. Ever since then, there has been an increasing number of work focusing on reverse engineering microarchitecture details in commodity processors and revealing unknown hardware security vulnerabilities embedded in black-box silicon.
The community has witnessed the fast evolution of microarchitectural side-channel attacks. Since 2005, a lot of attack work has been focusing on caches, from the private L1 and L2 caches to the last-level caches (LLC). Soon, researchers found many cache-alike structures, such as DRAM row buffers, directories, and branch predictors, can be attacked in a very similar way as caches. In the past several years, the focus has been shifted to studying channels that are difficult to exploit, such as port contention inside SMT cores, on-chip interconnects, and cache banks, and discovering unpublic channels in commodity processors, such as structures inside the frontend of CPUs and transient buffers inside cache hierarchies. More recently, researchers are not even satisfied with finding side-channel vulnerabilities due to microarchitecture structural contention. Attacks, such as HertzBleed, took another step further by exploiting timing leakage introduced by the circuit power and frequency variation.
The paper “Opening Pandora’s Box: A Systematic Study of New Ways Microarchitecture Can Leak Private Data” (ISCA’21) made a nice analogy that can be used to vividly describe the above research trend of discovering new microarchitectural vulnerabilities (visualized in Figure 1 Left). Basically, we have only seen the tip of the iceberg of microarchitecture side-channel vulnerabilities. There is an extensive list of microarchitectural optimizations waiting for us to explore. It is an exciting research direction to dig deeper into the water and advance the community’s understanding of microarchitecture side-channel vulnerabilities.
Figure 1: The Microarchitecture Security Research Landscape
The Limitations of Looking at Microarchitecture-Only Side Channels
This article tries to look at a different aspect of the current research landscape. It tells a cautionary tale by providing a few examples to highlight the limitations of looking at microarchitecture-only side channels. The key point is, microarchitectural side channels are not the only iceberg among the vast security topics to which computer architects can make contributions (visualized in Figure 1 Right). In addition to going deeper and expanding the research landscape vertically, it would be equally important to look beyond microarchitecture-only side channels and expand the research landscape horizontally.
Limitation 1: Miss threats that arise from compound threat models
The first concern of narrowly considering microarchitecture-only side channels is the potential risk of missing threats arising from compound threat models. Modern systems are becoming increasingly complex, exposing a large attack surface with vulnerabilities in both software and hardware. It used to be the case that security researchers explore software and hardware vulnerabilities separately, considering the two vulnerabilities in two disjoint threat models. These research methods heavily rely on the assumption that the instruction set architecture (ISA) can serve as a proper software/hardware interface for reasoning security. However, as indicated by various microarchitecture attacks, including Spectre and Meltdown, this assumption no longer holds. Therefore, before we re-settle on a proper software/hardware abstract, it is essential to consider software and hardware security problems in compound threat models, rather than in separation.
There have been a few attempts to study compound threat models. For example, multiple side-channel attacks have used side channels to bypass Address Space Layout Randomization (ASLR), a widely deployed security feature to mitigate memory corruption vulnerabilities. The Blindside attack shows that fine-grained ASLR can be bypassed using speculative execution attacks. Furthermore, the recent PACMAN attack (ISCA’22, Micro Top Picks’23) further shows that ARM Pointer Authentication, an important software security primitive, can be bypassed on Apple M1 processors. Both the PACMAN attack and the BlindSide attack highlight that software security mechanisms that employ a security-by-crash design principle and rely on low collision probability are potentially vulnerable to speculative execution attacks, since speculation can serve as a primitive to suppress crashes.
There exist several intriguing research directions in studying compound threat models. For example, it would be interesting to explore further how to use combined attack vectors to bypass important security mechanisms in an innovative way. In addition to finding new attack variations, we can also try to conduct a comprehensive security analysis to systematically formulate and categorize compound security threats. This aligns with how the Pandora’s box paper synthesizes the leakage model of a broad range of microarchitecture optimizations. Furthermore, the fundamental reason that we are forced to consider compound threat models is the lack of proper software/hardware abstraction for reasoning about the close interactions between security primitives spanning across the software and hardware layers.
Limitation 2: Misunderstand the root causes of side-channel attacks
The second concern of looking at microarchitecture-only side channels lies in the potential misinterpretation of the root causes of certain types of side-channel attacks. When exploiting a side channel, an attacker needs to extract a secret from the observation of side effects generated by a victim program’s execution. This secret extraction process usually involves using signal processing techniques or sometimes machine learning techniques. The usage of advanced data processing techniques in designing and deploying side-channel attacks has incited a worrying trend, as these techniques are very good at finding correlations but offer very limited interpretability.
For example, in our recent work “There’s Always a Bigger Fish: A Clarifying Analysis of a Machine-Learning-Assisted Side-Channel Attack” (ISCA’22, Micro Top Picks’23), we show that the working mechanism of a state-of-the-art website-fingerprinting attack was widely misunderstood. Specifically, the attack’s usage of the cache led to a consensus that the attack exploited a cache-based side channel. However, our detailed analysis contradicts this assumption and reveals the fact that the attack is actually powered by system interrupts. System interrupts, as a software-hardware coordinating mechanism, can be easily missed if we only consider microarchitecture side channels.
Take a step back and let’s consider a scenario when two processes execute on the same machine. The two processes share a huge number of software and hardware resources. Indeed, it is a non-trivial research problem to fully figure out all the sources of side-channel signals in a real-world setup. Bigger Fish only offers a case study to showcase how to locate side-channel root causes, and far more analysis needs to be done to fully understand various side channels being discovered nowadays. It is intriguing to think about, for any given side channel, whether there exists a “bigger bigger” fish. Besides, it might be a promising research direction to build infrastructures to assist such analysis.
Bio: Mengjia Yan is an Assistant Professor at MIT’s EECS Department and a member of the Computer Science and Artificial Intelligence Laboratory (CSAIL). Her research interest lies in the areas of computer architecture and hardware security. More information can be found here.
Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.
