Fractal: MIT’s Custom OS Is an Electron Microscope for Chips

MIT CSAIL has built a custom operating system from scratch, called Fractal, that boots directly on hardware and lets researchers study microprocessors without the noise that macOS or Linux add to every experiment. Its first major use, an audit of the branch predictors inside Apple’s M1, has overturned one earlier finding and turned up the first evidence that a class of speculative attack called Phantom affects Apple Silicon.

What Fractal Does Differently

Fractal is the work of MIT PhD student Joseph Ravichandran and Mengjia Yan, an MIT associate professor of electrical engineering and computer science and a CSAIL principal investigator. They built it as research infrastructure, with the goal of removing every variable a conventional operating system injects into a microarchitecture experiment. The codebase grew over months of work, then months of testing, before any experiment ran on it.

The headline technique is what the team calls multi-privilege concurrency. It rests on a new construct called the outer kernel thread, which lives inside a user process’s memory but executes with kernel privileges. The arrangement lets a single experiment run the same instructions in the same address space at multiple privilege levels, switching between them at runtime. Background noise from interrupts, scheduler activity, or address-space management is essentially absent. Where macOS or Linux blur every measurement, Fractal produces flat baselines and clean signals.

It’s like a microscope. If you’ve got a hand magnifying glass, you can see a little bit. But if you had an electron microscope, now we’re really talking. That’s what Fractal is. The electron microscope of operating systems.

Ravichandran, the MIT PhD student who led the project, framed the work that way in a write-up that coincided with the team’s presentation at the IEEE Symposium on Security and Privacy in San Francisco. The full Fractal project description and M1 findings is on the MIT CSAIL site.

Why General-Purpose Operating Systems Get in the Way

The problem Fractal solves is one chip security researchers have worked around for years. Modern processors keep state in many internal structures, including branch predictors, caches, and translation lookaside buffers, and the operating system itself adds to that state by managing privilege levels, address spaces, and scheduling. To study how those structures behave across the boundary between user code and kernel code, two domains the chip is supposed to keep isolated, researchers have had to run nearly identical experiments on each side of the line and reconcile the results.

On a general-purpose operating system, the comparison is very difficult. The system injects its own activity into every measurement, and on Apple’s platforms macOS is slated for deprecation of the kinds of kernel patches the field relies on. Instead of working around that, researchers typically open macOS or Linux, patch the kernel by hand, and hope the modifications hold. The approach is unstable, hard to reproduce, and the patched measurements carry noise the researchers themselves did not put there. Fractal inverts the model: it boots directly on bare metal, with no other software running, and exposes primitives that let a single experiment switch privilege levels at runtime.

Three Findings From the M1

Apple’s M1 implements an ARM specification called CSV2, which is supposed to prevent code running in one privilege level from steering speculation in another. The team used Fractal to test that protection, then ran a wider set of branch-predictor experiments on the same chip.

The Fractal run on the M1 turned up three results:

• A CSV2 side channel at the fetch stage.
• The first evidence of Phantom speculation on Apple Silicon.
• A reversal on the conditional branch predictor.

Practical limits on the Phantom finding on the M1 are clear from the data. The team reported that while Phantom fetches can occur, the instructions are never executed, which is why the disclosure to Apple did not come with a working exploit. The same source notes that Phantom speculation has previously been demonstrated only on AMD and Intel hardware, making the M1 result the first evidence that Apple Silicon is affected. Ravichandran framed Fractal’s value in terms of clarity: ‘My hope is that our results as a community get significantly more reliable, significantly more accurate.’

The CSV2 side channel finding is the most technical of the three. Fractal showed that the M1’s CSV2 protection works for the execute stage of indirect branch prediction, but the target is still fetched into the instruction cache before the protection kicks in. User code can still influence what the kernel pulls into its caches across the privilege boundary, and the same pattern appears between processes with different address space identifiers. The conditional branch predictor finding takes the technique further, with Fractal showing the predictor has no privilege isolation at all on either the M1’s performance cores or its efficiency cores. That result overturns earlier work that had reported partial isolation on the efficiency cores, a finding the MIT team attributes to macOS quietly migrating threads between cores during system calls.

For us, it is a true independent variable. You change the privilege level, nothing else changes. The only thing that could explain whether the attack succeeds or not is the privilege level.

Ravichandran, the MIT PhD student who led the project, said that in the same CSAIL write-up that introduced Fractal. The quote captures the experimental property the kernel was designed to deliver, with no other variables in play. In its own discussion of why Fractal’s findings differ from earlier work, the MIT write-up also describes the older conditional predictor result as ‘an artifact of macOS.’

An Operating System Built for the Lab, Not the Living Room

Fractal is a command-line research kernel. It boots into a shell and ships with ports of standard developer tools, including vim, GCC, and the dash shell, plus a C library and familiar POSIX system calls, so researchers can move existing experiment code over with minimal friction. The team coded it from scratch in assembly, C, and C++ over the second half of 2024, then put it through months of testing on multiple architectures. Ravichandran has said the first run on Apple Silicon left him with almost no feedback at all.

When Fractal finally ran on Apple Silicon, the team’s only debug output was the small white power light on the front of a Mac Mini, lit when the code was running and dark when the machine had crashed. The kernel is freely available as open source under the MIT license, per an IEEE Spectrum write-up of the project. The kernel is on GitHub, the full experimental setup is on Zenodo, and additional details are on the project’s website, the same write-up says.

Fractal at a glance:

• Codebase: more than 31,000 lines
• First version shipped: end of 2024
• Architectures: 3 (x86_64, ARM64, RISC-V)

Apple Engineers Tried the Microscope Too

The MIT team disclosed its M1 findings to Apple’s product security team, the standard channel for chip-level research. In an unusual reversal, Apple’s engineers also examined Fractal itself, the same CSAIL write-up reports.

Fractal is described in the IEEE Spectrum write-up as a research tool first, but the team built it with the practical aim of running on hardware that real systems use. The Mac Mini they tested on is a stock machine, and the same kernel also runs on the Mac Mini with Apple M4, on Raspberry Pis, and on many Intel and AMD PCs. The portability is by design, since the goal is to make microarchitecture experiments reproducible across labs and across chips. The kernel’s cooperative multitasking and a memory system the team calls gmap are both intended to give researchers tighter control over what runs and when, on top of the multi-privilege concurrency that is Fractal’s headline feature. Ravichandran wants Fractal to become to microarchitecture research what tools like QEMU and FFmpeg are to their fields.

Apple’s engineers were given the same tool the MIT team used, and the disclosure went the other way for once. The exchange, as described in the MIT write-up, signals that the underlying technique has uses beyond academic microarchitecture research. Mengyuan Li, an assistant professor at the University of Southern California who was not involved in the paper, called Fractal ‘a strong architecture contribution’ and said the project ‘makes difficult hardware experiments much easier to interpret.’

Toward a Shared Tool for the Whole Field

Ravichandran’s ambition for Fractal goes beyond the M1. He has said he wants the kernel to be picked up the way QEMU and FFmpeg are: shared infrastructure that other labs extend and rely on. The kernel, the experimental setup, and the documentation are all released publicly, and the team has built the system with ports of common developer tools so other researchers can move their own experiments onto it. The CSAIL write-up presents the project as a community resource, with Ravichandran’s stated goal of ‘getting this system out into the world so other researchers can benefit from it.’

The work, presented at the IEEE Symposium on Security and Privacy in San Francisco in May 2026, is a referendum on how microarchitecture research gets done. Where the field once patched macOS or Linux to get close to the silicon, the MIT team is now showing what the silicon looks like with the operating system stripped away. ‘My hope is that Fractal becomes a community project with contributions from other research labs who benefit from this approach,’ Ravichandran said.

Frequently Asked Questions

What is Fractal, MIT’s new operating system?

Fractal is a custom operating system kernel written from the ground up at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) by PhD student Joseph Ravichandran and associate professor Mengjia Yan. It boots directly on bare metal and lets researchers switch CPU privilege levels on the fly, stripping out the noise that general-purpose operating systems like macOS and Linux add to microarchitecture experiments.

What did Fractal find on the Apple M1?

Three results, all on the M1’s branch predictors. The MIT team turned up evidence of Phantom speculation on Apple Silicon, a class of misprediction previously shown on AMD and Intel processors. They also found a CSV2 side channel at the fetch stage, where the execute protection holds but the target is still fetched into the instruction cache first. And they reversed the prior finding on the conditional branch predictor, where Fractal showed the predictor has no privilege isolation at all, on either performance or efficiency cores.

Is the Phantom flaw on the Apple M1 dangerous?

The practical risk looks limited. Fractal found that while Phantom fetches can occur on Apple’s M1, the instructions are never executed. Ravichandran declined to speculate on how the vulnerability might be used in the wild and said the findings were disclosed to Apple’s product security team.

How is Fractal different from running experiments on Linux or macOS?

General-purpose operating systems manage privilege levels, address spaces, and scheduling themselves, and that background activity injects noise into every microarchitecture measurement. Fractal boots with no other software running and uses a new technique the team calls multi-privilege concurrency, built around a construct called the outer kernel thread, to let a single experiment run the same code at different privilege levels in the same address space.

Why did Fractal’s conditional branch predictor result on the M1 matter?

Earlier research had reported that cross-privilege training worked on the M1’s performance cores but not on its efficiency cores, a finding that suggested partial isolation. Fractal showed the predictor has no privilege isolation at all, on either core type, and the MIT team attributes the earlier result to macOS quietly migrating threads between cores during system calls. In the older experiment, the thread moved between core types during a system call, so the apparent isolation was a scheduling effect rather than a hardware property.