MIT's Fractal OS Finds New M1 Chip Security Flaw

A new kernel called Fractal strips away the noise of general-purpose operating systems to study processors directly on bare metal, and its first target, Apple's M1, didn't pass clean.

Why Patching Linux and macOS Wasn't Good Enough

Hardware security researchers studying things like branch predictors, caches, and speculative execution have historically run their experiments on top of operating systems that were never designed for the job. They patch the Linux or macOS kernel by hand, hope the modifications hold, and accept the side effects: interrupts, scheduler activity, and address-space management all bleed into the measurement. On Apple's platforms, the kernel-patching workarounds researchers have relied on are also headed toward deprecation, narrowing an already difficult path.

A team at MIT's Computer Science and Artificial Intelligence Laboratory built something different. Fractal is an operating system kernel written from scratch, designed to treat the chip itself as the object of study rather than a platform to run other software on. It boots directly on bare metal with nothing else running, which removes the background activity that blurs measurements taken under a general-purpose OS. Lead researcher Joseph Ravichandran, an MIT PhD student in electrical engineering and computer science, described the difference to MIT CSAIL as the difference between a hand magnifying glass and an electron microscope.

How Fractal Lets One Experiment Run at Two Privilege Levels

The technical problem Fractal solves is specific: to study how a processor isolates user-level code from kernel-level code, researchers need to run nearly identical experiments on both sides of that boundary. Under a general-purpose OS, the system itself controls privilege levels, address spaces, and scheduling, which makes that kind of controlled comparison difficult to trust.

Fractal's answer is a technique the team calls multi-privilege concurrency, built around a new construct called the outer kernel thread. This thread lives inside a user process's memory space but executes with kernel privileges, letting a single experiment flip privilege levels at runtime while running the same instructions in the same address space. The result, according to the MIT team, is an experimental setup with close to no background noise — flat baselines instead of the blurred signals produced by interrupts and scheduler activity on a stock kernel.

Where Apple's M1 Protection Actually Breaks Down

Apple's M1 implements an ARM specification called CSV2, meant to stop code running at one privilege level from steering speculative execution at another. Using Fractal, the MIT team confirmed that this protection does what it's supposed to at the execute stage: a user-mode program cannot trick the kernel into speculatively executing a chosen target through the indirect branch predictor.

But the team also found something the chip's designers likely didn't intend. Before that execute-stage protection kicks in, the CPU still fetches the predicted target into the instruction cache. That fetch is observable through a side channel, meaning user-mode code can still influence what the kernel pulls into its caches across the privilege boundary, even though it can't control what the kernel executes. The same pattern showed up between processes assigned different address space identifiers. Separately, Fractal produced what the team describes as the first evidence that Apple Silicon is vulnerable to Phantom speculation, a misprediction class in which ordinary instructions, including no-ops, get misread by the CPU as branches and trigger speculative behavior nobody asked for. On the M1, Fractal showed Phantom fetches succeeding across both privilege levels and address spaces, even though, as with the indirect branch predictor, the execute phase stayed blocked.

Why an Earlier Conclusion About the M1 Turned Out to Be Wrong

A separate Fractal experiment overturned a finding from prior academic work on the M1's conditional branch predictor. That earlier research had concluded cross-privilege training succeeded on the M1's performance cores but not its efficiency cores, a result that suggested the two core types differed meaningfully in how they isolate privilege levels. Fractal's controlled comparison showed otherwise: the conditional branch predictor has no privilege isolation at all, on either core type. The prior result, the MIT team found, was likely an artifact of macOS quietly migrating threads between cores during system calls, which made an OS scheduling behavior look like a hardware property.

Ravichandran framed the value of Fractal's isolation this way in the MIT account: when privilege level is the only thing that changes between two runs of the same code, it becomes a true independent variable, and the only variable that can explain a difference in outcome.

The MIT team disclosed its M1 findings to Apple's product security team, and Apple's engineers in turn examined Fractal itself. Fractal spans more than 31,000 lines of code, supports x86_64, ARM64, and RISC-V architectures, and ships with POSIX system calls, a C library, and ports of standard tools including vim, GCC, and the dash shell — infrastructure choices aimed at letting other researchers move existing experiments onto it with minimal rework. Mengyuan Li, a University of Southern California assistant professor not involved in the work, told MIT CSAIL the project's value is in turning an often ad hoc microarchitectural reverse-engineering workflow into reusable research infrastructure. Ravichandran and MIT associate professor Mengjia Yan presented the work at the IEEE Symposium on Security and Privacy, with support from the National Science Foundation, the U.S. Air Force Office of Scientific Research, and DARPA's ACE program.