Are Apple’s Chips Vulnerable? Investigating a New Side Channel Attack

May 05, 2022 by Jake Hertz

As chip security becomes a growing concern, researchers found a potential security vulnerability in Apple’s new M1 and A14 chips in the form of microarchitectural side channel attacks.

In today's highly digital age, security is one of the most important aspects of any electronic system's design. From an electrical engineer's perspective, the goal is to develop hardware that is as secure as possible on the silicon, board, and system level.

Despite these intentions, it's unavoidable that no system can ever be 100% secure. Growing security threats such as side channel attacks seem to permeate every field and impact systems on both the hardware and the software level. 


An example of a side channel attack. Image used courtesy of R. Vanathi and SP. Chokkalingam


This week, a group of researchers announced that they’ve discovered a new microarchitectural side channel vulnerability that affects Apple’s latest M1 and A14 chips.

In this article, we’ll provide background on the vulnerability, how it works, and what it could mean for Apple silicon.


What are Prefetchers?

One of the traditional bottlenecks in the field of computing is the memory bottleneck—the amount of time it takes to fetch data from memory is significantly more significant than the time it takes to perform the actual computation on that data.

For this reason, computer architects came up with the concepts of the cache and prefetcher.

A cache is a smaller sub-memory located spatially near the processor for quicker memory access and retrieval. Within the cache, the system stores data that is highly likely to be used again by the program based on spatial and temporal locality principles. 


A high-level architecture of a cache with prefetching.

A high-level architecture of a cache with prefetching. Image used courtesy Vicarte et al


Prefetchers take caching a step further by proactively predicting what a program will access memory before it is even needed. 

Generally speaking, classical prefetchers work on a three-step process:

  1. Training: The prefetcher records if the address sequence coming from the core matches a specific pattern.
  2. Prefetching: If a pattern is recognized with confidence, the prefetcher autonomously fills the cache with anticipated data.
  3. Validation: The prefetcher checks whether its predictions are right by comparing cached data to core requests.


Brief Data Memory-dependent Prefetcher Overview

Beyond classical prefetchers, there is significant interest in the field of computer architecture in what is known as data memory-dependent prefetchers (DMP)


A high-level architecture of a cache with DMP.

A high-level architecture of a cache with DMP. Image used courtesy of Vicarte et al


A DMP is similar to a classical prefetcher but is designed to prefetch irregular address patterns such as pointer chases. These pointer chases cannot be predicted without understanding the dependencies between the address pattern and the physical memory contents. 

DMPs follow a similar three-step process; however, unlike classical prefetchers, the DMP prefetch phase requires the DMP to directly read the contents of memory that follow the predicted pattern.

For example, if a DMP were searching for a pointer, the prefetcher would have to access a cache line that it believes holds it and then dereference that pointer. 


A New Side Channel Attack—Augury

Keeping those two general concepts in mind, researchers published a new paper that describes a microarchitectural side channel attack that claims to impact Apple's A14 and M1 chips.


Memory layout of the DMP AoP and buffer.

Memory layout of the DMP AoP and buffer. Image used courtesy of Vicarte et al


The new attack, called Augury, exploits the fact that these Apple chips use a DMP that prefetches an array of pointers (AoP). In an AoP, the system addresses, reads, and caches memory that has not even been accessed yet, and may never be accessed. 

For example, in the code snippet shown below, the DMP would proactively and speculatively load and dereference *arr[3] onward when the code was only accessing *arr[0].


Example code segment. 


The vulnerability of this approach is that the system is now excessively reading and exposing data, rendering it vulnerable to attackers. This vulnerability can expose the system to data at rest attacks, where the targeted data is never read into the core speculatively or non-speculatively and yet is still leaked.


Should You Be Concerned?

Thankfully, the researchers found this vulnerability before any adversary could and have promptly reported Apple of their findings. According to the researchers, the extent of the attack is currently very minimal, with only pointers being leaked. 

However, there is always a threat of more mature attacks developing based on this exploit. Hopefully, Apple will be able to patch up this vulnerability before this can become a legitimate threat.