The full paper, slides from my S&P talk, and all our experiment data can be found at the Fractal project website here: https://fractal-os.com
We've been building Fractal internally for a very long time (first commit was almost exactly 2 years ago), so it's exciting to finally share it with the world. Let me know what you think!
I didn’t quite understand the scope of impact of the issues highlighted in the article.
> The CPU still fetches the target into the instruction cache before the protection kicks in.
> In Phantom, ordinary instructions, including a no-op, can be misinterpreted by the CPU as branches, triggering speculative behavior the program never asked for.
Is the idea you combine these two to execute a BTB style attack? Is there a world in which speculative cache fetching is still fine if it’s non exploitable or is it always a risk and the performance cost of fixing the hardware negligible?
> The Fractal team showed that the conditional branch predictor has no privilege isolation at all
This one seems more serious. Now that it’s confirmed, does it provide a map for how to exploit it in a real system or is this non-exploitable in practice because of OS design choices around migration?
Studying how a processor running an operating system actually behaves by peeking right through the privilege barrier is the ultimate wall hack.
Who needs noclip when we have Fractal?
At the risk of sounding extremely dumb, I have a question for you: if the hardware is susceptible to something that you can't actually reproduce with the software everyone runs on it, who should care, and why? Is it even really fair to call it a vulnerability at that point? Is the idea that this is supposed to help identify a different mechanism of exploiting the vulnerabilities with the shipped OS too?
To give an analogy, it almost feels like removing the protection circuitry from a Li-Ion battery and then testing if it can catch fire, and observing that it does. Should it really worry users?
Great analogy. Li-ion batteries have several layers of defense against exploding, one of which are vents that, if all else fails, let the hydrogen gas safely escape rather than building up. It's perfectly fair for independent testers to say "we haven't found any flaws in the protection circuitry yet, but we should bypass it to see if the vents work as designed".
I'm not disputing that it's fair to investigate that. What I'm asking is if it's fair to then call it a vulnerability without establishing that the thing is, in fact, vulnerable as a result.
I would say it's like calling the battery a fire hazard if the vents don't work, but actually that's not analogous because the necessity for vents doesn't merely arise from the need to protect against bad design of the protection circuitry. They're needed for safety even if your circuitry design is flawless. So the analogy is actually kind of poor in that regard.
This is why a distinction is often drawn between vulnerabilities and exploits — many more things can be weaknesses in a system that can only be exploited in combination with other vulnerabilities.
An obvious example is web browsers, where a vulnerability can easily be uninteresting because it lives in a sandboxed process… until you find a sandbox escape, then it is critical.
As long as you suspect there may be other vulnerabilities in the other layers, it is worthwhile investigating and fixing them, because defence in depth only works until someone manages to put together a full chain.
Not the author, but as someone who frequently has to answer this question, I'll chip in:
A mistake is a mistake, whether you have a way to reproduce it right now or not. It's pretty much a given that whatever means you have right now to reproduce the problem will evolve and broaden the scope. Also, if you haven't found a way to reproduce the problem, it doesn't mean it doesn't exist: it takes a lot more effort to prove that it's impossible to reproduce than to simply not being able to reproduce the problem.
As long as we're using analogies, let's use a car one. If your car gets into a car crash, you want it to be safe and not explode, yeah? Would you rather drive around, and see if it happens to explode if you happen to get into a crash, or would you rather setup a test arena, crash as many copies of your car, as many times as possible, to see if it ever also explodes. And then, once you've shown it can explode when the left back window is halfway down and the passenger door is halfway open, then from there it's easier to figure out how those set of circumstances might actually happen in the real world.
It's research, which often involves a ton of work for zero pay off. It's usually thankless and unrewarding, on the off chance that there is some exploit to be had.
have you considered forking existing OS and implementing changes that you needed instead?
it's hard for me to justify the tremendous effort of implementing the OS from scratch, instead of adding the functionality that you need to for example linux or xv6.
> (it) exposes primitives that let a single experiment switch privilege levels at runtime while executing the same instructions in the same address space.
i think that it can be achieved by following linux modifications:
- make all executable pages executable both in user and kernel mode
- define a new syscall number, let's call it 'fractal'
- upon 'svc' trap (syscall), if it's a fractal syscall, just branch to instruction after the 'svc' (still in kernel mode! no 'eret', as opposed to no-fractal syscalls)
> [...] they usually run their experiments on top of an operating system that was never built for the job. They open up macOS or Linux, patch the kernel by hand, and hope the modifications hold. The approach is unstable, hard to reproduce, and on Apple’s platforms, slated for deprecation.
I'd also like to hear more about why that's a problem, not because I disagree, but because I don't know jack about this and it's fascinating. However, I could imagine at least a couple of advantages to this approach.
* It's not a general purpose OS. It doesn't have to support 10,000,000 different accessories, just enough to get the kernel booted so researchers can interact with the hardware.
* You don't have to deal with general purpose constraints here. Who needs something like a fair scheduler when the goal is to give researchers direct access to the hardware for minutes at a time?
* If broad hardware support and universal use case support aren't goals, you can write something vastly simpler that basically loads a program and turns it loose on the underlying bare metal. I imagine that'd make repeatability vastly easier, with no "oops, an Ethernet packet came in so I need to service that mid-test" interrupt{,ion}s.
Those would seem like good reasons to make a minimal kernel that doesn't get between the researchers and their work.
Not to take away from the authors' work, but this was actually the approach taken by some engineers while Spectre / Meltdown were still under embargo. Not sure if they ever mentioned their work publicly so I will avoid naming them, but some talented folks from Microsoft who basically came to the same conclusion that a specialized environment free of noise was necessary both to test mitigations and find variants.
I'm really excited about this work, although I haven't read the code or paper yet. It seems to me Fractal would be ideal for running benchmarks for compilers so that the OS-induced noise is kept to a minimum.
I think you're better off watching any of the various recordings "Performance Matters" conference talks[0] by Emery Berger to learn about all the ways that developers are benchmarking the wrong thing using the wrong techniques, and what you could do instead
The "outer kernel thread" idea -- userspace memory but kernel privileges --
is such an obviously good idea in retrospect that I'm surprised nobody
did it before. You spend half your time in microarchitecture research
just trying to control for OS noise.
The Apple M1 phantom speculation finding is wild. I wonder if this is
actually a bug in Apple's implementation or if CSV2 just has a
fundamental race condition between the protection and the i-cache fill.
The paper makes it sound like the latter.
Also, 31k LOC for a from-scratch kernel supporting three ISAs is...
not a lot. That's either very impressive or they're skipping a lot of
stuff a production kernel needs. Curious which.
That title gave me a mild chuckle. As if the chips were wonders of nature that you can find deep in the forest, bring to a lab and build an operating system for them to study. Nice one! :-)
It is so cool to see some bare metal OSs being built. Do projects like this pave the way for a better standard ISA and less driver code, like the problem described in Casey Muratori's video "the 30 million line code problem"? I'm a bit new to this space, but this seems like a step in that direction.
Hardware is getting more specialized these days. It's becoming more difficult than ever to write bare metal code. I don't think most (any?) software wants to manage the details a BSP solves for them.
The paper's reference to https://github.com/blacktop/darwin-xnu-build does not support the statement made by the paper. It's not redaction or obfuscation that makes building XNU difficult. It's having the right toolchain; modifying makefiles and code to accommodate a slightly different toolchain; and needing a load of extra stuff that isn't pre-supplied with XNU. A lot of the patches and issues there are about compiler differences, language standard differences, and plain missing stuff.
This is a secondary niggle in the larger scheme of things, though. Not using something like XNU in the first place is the way, for the reasons that the paper goes into. (Whilst 'of course it runs NetBSD' applies to the M1, one wouldn't use NetBSD for this for the same reasons that one wouldn't use XNU.) People experienced in this sort of thing likely nodded along at decisions like coöperative rather than preëmptive multitasking.
I wonder whether they considered the Watanabe shell rather than the Debian Almquist shell. They picked vim instead of nvi2, after all.
I assume the idea is that finding tools and assembling other projects together into a build environment is comparatively easy but papering over entire components being missing is much harder
No. As I said, that's really a secondary niggle with the paper itself misrepresenting its reference, which as you can see already provides patches to paper over such stuff, as through the problem with XNU were redaction, which it isn't per that reference.
The primary reason not to use XNU is what the paper goes into in detail; which is the architecture of XNU simply getting in the way, just as the architecture of NetBSD would for the same reasons. If XNU being incomplete were the primary problem, NetBSD, a complete operating system that supports loadable kernel modules and provides a coherent development toolchain out of the box, would be the answer. But it is not.
I suppose the theory is when you're attacking a console like the Xbox One with some known hypervisors vulnerabilities, but generally what is considered to be secure hardware, you could use the patchable hypervisor vulnerability to install your custom OS, then use the OS itself to find silicon bugs, finally securing a pathway for permanent access to the device.
I am very confused by calling this kind of work "researches".
They are not pushing the boundary of human knowledge - they are playing game (reverse engineering) with other human.. maybe that is me having a very narrow definition of "research"
I think I see your point: how can you "research" something that was carefully constructed by highly skilled engineers and scientists who have access to every design document, artifact, and test used to build the CPU.
I don't have an answer to your question but I think you're being unfairly downvoted.
I actually do a phd in a closely related area.
Creating better tools to do research with is definitely part of the research process.
While there is a lot of work in general operating systems, those aimed to specifically do a lot of microarchitectural experiments is still undiscovered ground.
Feel free to suggest a more suitable word. Research is usually defined against the the body of knowledge of the entity performing it and not all of humanity that ever lived.
Yet a published peer-reviewed research should be against humanity. I am also curious whether such research can bring knowledge that apple don't know, otherwise even it is impressive, there is a level of sadness in it from my view.
> When security researchers want to understand what a modern processor is really doing with the kind of detail that determines whether attacks like Spectre and Meltdown are possible, they usually run their experiments on top of an operating system that was never built for the job. They open up macOS or Linux, patch the kernel by hand, and hope the modifications hold. The approach is unstable, hard to reproduce, and on Apple’s platforms, slated for deprecation.
> A team at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) decided to build something different. Fractal, an operating system kernel written from the ground up, treats the hardware itself as the object of study.
> Fractal supports x86_64, ARM64, and RISC-V, and consists of more than 31,000 lines of code. The team designed it as infrastructure rather than as a single experiment, with familiar POSIX system calls, a C library, and ports of standard tools like vim, GCC, and the dash shell, so that researchers can move existing experiment code over with minimal friction.
I was around the "what does the hardware really do?" space 4-ish decades ago - hacking together your own Minimum Viable OS was table stakes.
Obviously MIT's Fractal is vastly larger than anything we did back then - but is anyone in this space now, to comment on how special Fractal is...or isn't?
Hi everyone, Joseph (paper author) here. You can find Fractal on Github: https://github.com/jprx/fractal
The full paper, slides from my S&P talk, and all our experiment data can be found at the Fractal project website here: https://fractal-os.com
We've been building Fractal internally for a very long time (first commit was almost exactly 2 years ago), so it's exciting to finally share it with the world. Let me know what you think!
I didn’t quite understand the scope of impact of the issues highlighted in the article.
> The CPU still fetches the target into the instruction cache before the protection kicks in.
> In Phantom, ordinary instructions, including a no-op, can be misinterpreted by the CPU as branches, triggering speculative behavior the program never asked for.
Is the idea you combine these two to execute a BTB style attack? Is there a world in which speculative cache fetching is still fine if it’s non exploitable or is it always a risk and the performance cost of fixing the hardware negligible?
> The Fractal team showed that the conditional branch predictor has no privilege isolation at all
This one seems more serious. Now that it’s confirmed, does it provide a map for how to exploit it in a real system or is this non-exploitable in practice because of OS design choices around migration?
Can it run Doom?
Haven't gotten around to it yet haha
Studying how a processor running an operating system actually behaves by peeking right through the privilege barrier is the ultimate wall hack. Who needs noclip when we have Fractal?
At the risk of sounding extremely dumb, I have a question for you: if the hardware is susceptible to something that you can't actually reproduce with the software everyone runs on it, who should care, and why? Is it even really fair to call it a vulnerability at that point? Is the idea that this is supposed to help identify a different mechanism of exploiting the vulnerabilities with the shipped OS too?
To give an analogy, it almost feels like removing the protection circuitry from a Li-Ion battery and then testing if it can catch fire, and observing that it does. Should it really worry users?
Great analogy. Li-ion batteries have several layers of defense against exploding, one of which are vents that, if all else fails, let the hydrogen gas safely escape rather than building up. It's perfectly fair for independent testers to say "we haven't found any flaws in the protection circuitry yet, but we should bypass it to see if the vents work as designed".
I'm not disputing that it's fair to investigate that. What I'm asking is if it's fair to then call it a vulnerability without establishing that the thing is, in fact, vulnerable as a result.
I would say it's like calling the battery a fire hazard if the vents don't work, but actually that's not analogous because the necessity for vents doesn't merely arise from the need to protect against bad design of the protection circuitry. They're needed for safety even if your circuitry design is flawless. So the analogy is actually kind of poor in that regard.
This is why a distinction is often drawn between vulnerabilities and exploits — many more things can be weaknesses in a system that can only be exploited in combination with other vulnerabilities.
An obvious example is web browsers, where a vulnerability can easily be uninteresting because it lives in a sandboxed process… until you find a sandbox escape, then it is critical.
As long as you suspect there may be other vulnerabilities in the other layers, it is worthwhile investigating and fixing them, because defence in depth only works until someone manages to put together a full chain.
Not the author, but as someone who frequently has to answer this question, I'll chip in:
A mistake is a mistake, whether you have a way to reproduce it right now or not. It's pretty much a given that whatever means you have right now to reproduce the problem will evolve and broaden the scope. Also, if you haven't found a way to reproduce the problem, it doesn't mean it doesn't exist: it takes a lot more effort to prove that it's impossible to reproduce than to simply not being able to reproduce the problem.
As long as we're using analogies, let's use a car one. If your car gets into a car crash, you want it to be safe and not explode, yeah? Would you rather drive around, and see if it happens to explode if you happen to get into a crash, or would you rather setup a test arena, crash as many copies of your car, as many times as possible, to see if it ever also explodes. And then, once you've shown it can explode when the left back window is halfway down and the passenger door is halfway open, then from there it's easier to figure out how those set of circumstances might actually happen in the real world.
It's research, which often involves a ton of work for zero pay off. It's usually thankless and unrewarding, on the off chance that there is some exploit to be had.
The real benchmark is whether it can run Doom while measuring why Doom runs.
chapeau for this project - and thanks for sharing it with the world!
have you considered forking existing OS and implementing changes that you needed instead?
it's hard for me to justify the tremendous effort of implementing the OS from scratch, instead of adding the functionality that you need to for example linux or xv6.
> (it) exposes primitives that let a single experiment switch privilege levels at runtime while executing the same instructions in the same address space.
i think that it can be achieved by following linux modifications:
- make all executable pages executable both in user and kernel mode
- define a new syscall number, let's call it 'fractal'
- upon 'svc' trap (syscall), if it's a fractal syscall, just branch to instruction after the 'svc' (still in kernel mode! no 'eret', as opposed to no-fractal syscalls)
and.. that's it?
From the article:
> [...] they usually run their experiments on top of an operating system that was never built for the job. They open up macOS or Linux, patch the kernel by hand, and hope the modifications hold. The approach is unstable, hard to reproduce, and on Apple’s platforms, slated for deprecation.
I'd also like to hear more about why that's a problem, not because I disagree, but because I don't know jack about this and it's fascinating. However, I could imagine at least a couple of advantages to this approach.
* It's not a general purpose OS. It doesn't have to support 10,000,000 different accessories, just enough to get the kernel booted so researchers can interact with the hardware.
* You don't have to deal with general purpose constraints here. Who needs something like a fair scheduler when the goal is to give researchers direct access to the hardware for minutes at a time?
* If broad hardware support and universal use case support aren't goals, you can write something vastly simpler that basically loads a program and turns it loose on the underlying bare metal. I imagine that'd make repeatability vastly easier, with no "oops, an Ethernet packet came in so I need to service that mid-test" interrupt{,ion}s.
Those would seem like good reasons to make a minimal kernel that doesn't get between the researchers and their work.
It’s not actually possible to have the kernel execute user pages like this on most modern systems
Not to take away from the authors' work, but this was actually the approach taken by some engineers while Spectre / Meltdown were still under embargo. Not sure if they ever mentioned their work publicly so I will avoid naming them, but some talented folks from Microsoft who basically came to the same conclusion that a specialized environment free of noise was necessary both to test mitigations and find variants.
Related (2019):
https://gamozolabs.github.io/metrology/2019/08/19/sushi_roll...
https://gamozolabs.github.io/metrology/2019/12/30/load-port-...
I suppose they did make their work public after all :)
Thank you for pulling up the references.
They didn’t build an operating system, they built a boot program that exposes the chip in a way an operating system doesn’t behave.
I'm really excited about this work, although I haven't read the code or paper yet. It seems to me Fractal would be ideal for running benchmarks for compilers so that the OS-induced noise is kept to a minimum.
Author: do you see issues with that use case?
I think you're better off watching any of the various recordings "Performance Matters" conference talks[0] by Emery Berger to learn about all the ways that developers are benchmarking the wrong thing using the wrong techniques, and what you could do instead
[0] https://www.youtube.com/watch?v=7g1Acy5eGbE&t=5m3s
That title gave me a mild chuckle. As if the chips were wonders of nature that you can find deep in the forest, bring to a lab and build an operating system for them to study. Nice one! :-)
It is so cool to see some bare metal OSs being built. Do projects like this pave the way for a better standard ISA and less driver code, like the problem described in Casey Muratori's video "the 30 million line code problem"? I'm a bit new to this space, but this seems like a step in that direction.
The only way to lessen the need of drivers would be to have more standardized and stable hardware interfaces and peripherals.
Hardware is getting more specialized these days. It's becoming more difficult than ever to write bare metal code. I don't think most (any?) software wants to manage the details a BSP solves for them.
The paper's reference to https://github.com/blacktop/darwin-xnu-build does not support the statement made by the paper. It's not redaction or obfuscation that makes building XNU difficult. It's having the right toolchain; modifying makefiles and code to accommodate a slightly different toolchain; and needing a load of extra stuff that isn't pre-supplied with XNU. A lot of the patches and issues there are about compiler differences, language standard differences, and plain missing stuff.
This is a secondary niggle in the larger scheme of things, though. Not using something like XNU in the first place is the way, for the reasons that the paper goes into. (Whilst 'of course it runs NetBSD' applies to the M1, one wouldn't use NetBSD for this for the same reasons that one wouldn't use XNU.) People experienced in this sort of thing likely nodded along at decisions like coöperative rather than preëmptive multitasking.
I wonder whether they considered the Watanabe shell rather than the Debian Almquist shell. They picked vim instead of nvi2, after all.
I assume the idea is that finding tools and assembling other projects together into a build environment is comparatively easy but papering over entire components being missing is much harder
No. As I said, that's really a secondary niggle with the paper itself misrepresenting its reference, which as you can see already provides patches to paper over such stuff, as through the problem with XNU were redaction, which it isn't per that reference.
The primary reason not to use XNU is what the paper goes into in detail; which is the architecture of XNU simply getting in the way, just as the architecture of NetBSD would for the same reasons. If XNU being incomplete were the primary problem, NetBSD, a complete operating system that supports loadable kernel modules and provides a coherent development toolchain out of the box, would be the answer. But it is not.
Just because someone did it doesn't make it easy? I found the reference to support the claim fairly well
I wonder if this could be practical for controlled environment devices like game consoles.
What do you mean? By the time you have kernel access like that you’ve already won.
I suppose the theory is when you're attacking a console like the Xbox One with some known hypervisors vulnerabilities, but generally what is considered to be secure hardware, you could use the patchable hypervisor vulnerability to install your custom OS, then use the OS itself to find silicon bugs, finally securing a pathway for permanent access to the device.
It’s practical in the sense that it lets a researcher find additional silicon bugs, although most game consoles now use merchant archs anyways
I am very confused by calling this kind of work "researches".
They are not pushing the boundary of human knowledge - they are playing game (reverse engineering) with other human.. maybe that is me having a very narrow definition of "research"
I think I see your point: how can you "research" something that was carefully constructed by highly skilled engineers and scientists who have access to every design document, artifact, and test used to build the CPU.
I don't have an answer to your question but I think you're being unfairly downvoted.
What you are talking about is sometimes called "basic research":
https://en.wikipedia.org/wiki/Basic_research
I actually do a phd in a closely related area. Creating better tools to do research with is definitely part of the research process. While there is a lot of work in general operating systems, those aimed to specifically do a lot of microarchitectural experiments is still undiscovered ground.
Security researcher is a common term, there's also market research which doesn't look like it falls under your definition
Feel free to suggest a more suitable word. Research is usually defined against the the body of knowledge of the entity performing it and not all of humanity that ever lived.
Yet a published peer-reviewed research should be against humanity. I am also curious whether such research can bring knowledge that apple don't know, otherwise even it is impressive, there is a level of sadness in it from my view.
No it's against what's published by all of humanity. So if somebody knows something and hasn't published it, someone else can still scoop them.
Yes your definition of research is incorrect.
> When security researchers want to understand what a modern processor is really doing with the kind of detail that determines whether attacks like Spectre and Meltdown are possible, they usually run their experiments on top of an operating system that was never built for the job. They open up macOS or Linux, patch the kernel by hand, and hope the modifications hold. The approach is unstable, hard to reproduce, and on Apple’s platforms, slated for deprecation.
> A team at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) decided to build something different. Fractal, an operating system kernel written from the ground up, treats the hardware itself as the object of study.
> Fractal supports x86_64, ARM64, and RISC-V, and consists of more than 31,000 lines of code. The team designed it as infrastructure rather than as a single experiment, with familiar POSIX system calls, a C library, and ports of standard tools like vim, GCC, and the dash shell, so that researchers can move existing experiment code over with minimal friction.
I was around the "what does the hardware really do?" space 4-ish decades ago - hacking together your own Minimum Viable OS was table stakes.
Obviously MIT's Fractal is vastly larger than anything we did back then - but is anyone in this space now, to comment on how special Fractal is...or isn't?
PHDs should be tool masters not knowledge basins.
Great to see.
The results are interesting but the whole project is worth a look.
https://people.csail.mit.edu/mengjia/data/2026.SP.fractal.pd...
Will it allow them install personally-made software, or will it require Google's approval?