Looking beyond the side channels of microarchitecture

This blog post summarizes my recent keynote address to 2022 IEEE International Symposium on Secure and Private Execution Environment Design (SEED). The talk shares some of my humble views on the current microarchitecture security research landscape, and points to some research directions worth exploring. These opinions are not intended to be exhaustive.

Even though microarchitecture security, as a research topic, has been around since the 1970s, it was until 2018 when Specter and Meltdown were discovered that this research topic had tremendous media coverage. Since then, there has been a growing body of work focusing on reverse engineering microarchitecture details in core processors and revealing unknown hardware security vulnerabilities embedded in black-box silicon.

The community has witnessed the rapid evolution of microarchitecture side-channel attacks. Since 2005, much of the attack work has focused on caches, from private L1 and L2 caches to last level caches (LLCs). Soon, researchers discovered that many cache-like structures, such as DRAM row buffers, directories, and branch predictors, can be attacked in much the same way as caches. In recent years, attention has shifted to studying hard-to-exploit channels, such as port contention within SMT cores, on-chip interconnects and cache banks, and the discovery of non-public channels in commodity processors, such as structures within the CPU frontend and transient buffers within cache hierarchies. More recently, researchers are not even satisfied with finding side channel vulnerabilities due to microarchitecture structural contention. Attackers, such as HertzBleed, have taken it a step further by exploiting the loss of timing introduced by varying circuit power and frequency.

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 aforementioned research trend of discovering new microarchitectural vulnerabilities (displayed in Figure 1 at left). Basically, we’ve only seen the tip of the iceberg of microarchitecture side-channel vulnerabilities. There is a large list of microarchitecture 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 microarchitectural side-channel vulnerabilities.

Figure 1: The microarchitecture security research landscape

This article seeks to examine a different aspect of the current research landscape. He gives a caveat by providing some examples to highlight the limits of observing the side channels of microarchitecture only. The key point is that microarchitecture side channels are not the only iceberg among the vast security topics to which computer architects can make contributions (displayed in Figure 1 at right). In addition to deepening and vertically expanding the research landscape, it would be equally important to look beyond the side channels of microarchitecture alone and horizontally expand the research landscape.

Limitation 1: Undetected threats that result from compound threat models

The first concern of narrowly considering microarchitecture-only side channels is the potential risk of missing threats resulting from compound threat models. Modern systems are becoming increasingly complex, exposing a large attack surface with vulnerabilities in both software and hardware. In the past, security researchers explored software and hardware vulnerabilities separately, looking at the two vulnerabilities in two separate threat models. These research methods rely heavily on the assumption that the instruction set architecture (ISA) can serve as an adequate software/hardware interface for safe reasoning. However, as indicated by various microarchitecture attacks, including Specter and Meltdown, this assumption is no longer valid. Therefore, before re-establishing a proper software/hardware summary, it is essential to consider software and hardware security issues in compound threat models, rather than separately.

There have been some attempts to study compound threat models. For example, multiple side-channel attacks have used side-channels to bypass Address Space Layout Randomization (ASLR), a security feature widely used to mitigate memory corruption vulnerabilities. THE Blind attack shows that fine-grained ASLR can be circumvented using speculative execution attacks. Also, the recent PACMAN Stem (ISCA’22, Micro Top Picks’23) it also 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 a low collision probability are potentially vulnerable to speculative execution attacks, because speculation can serve as a primitive to suppress crashes.

There are several intriguing research directions in studying compound threat models. For example, it would be interesting to further explore how to use blended attack vectors to bypass important security mechanisms in an innovative way. In addition to finding new attack variants, we can also try to conduct a comprehensive security analysis to systematically formulate and classify compound security threats. This is in line with how the Pandora’s Box chart summarizes the loss model of a broad range of microarchitecture optimizations. Furthermore, the fundamental reason we are forced to consider compound threat models is the lack of a proper software/hardware abstraction to reason about the tight interactions between security primitives that traverse the software and hardware layers.

Limitation 2: Misunderstand the root causes of side-channel attacks

The second concern with looking at microarchitecture-only side channels lies in the potential for misinterpretation of the root causes of some types of side channel attacks. When exploiting a side channel, an attacker must extract a secret from observing the side effects generated by executing a victim’s program. This covert mining process usually involves the use of signal processing techniques or sometimes machine learning techniques. The use of advanced data processing techniques in designing and deploying side-channel attacks has sparked a worrying trend, as these techniques are very good at finding correlations but offer very limited interpretation.

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 has been widely misunderstood. In particular, the attack’s use of 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 indeed powered by system outages. System interrupts, as a software-hardware coordination mechanism, can easily be ignored if we consider only the side channels of the microarchitecture.

Let’s step back and consider a scenario where two processes are running 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 understand all sources of side channel signals in a real world setup. Bigger Fish offers only one case study to show how to pinpoint the root causes of lateral canal, and much more analysis is needed to fully understand the various lateral canals being discovered today. It is interesting to think, for any given side channel, whether there is a « bigger and bigger » fish. Furthermore, it could be a promising research direction to build infrastructure to assist such analysis.

Biography: Mengjia Yan is Assistant Professor in the EECS Department of MIT and a member of the Computer Science and Artificial Intelligence Laboratory (CSAIL). His research interest is in the areas of information architecture and hardware security. Further 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.