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.
> 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?
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.
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 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'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
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 "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! :-)
22 comments
[ 2.3 ms ] story [ 43.1 ms ] threadhttps://people.csail.mit.edu/mengjia/data/2026.SP.fractal.pd...
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.
> 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?
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!
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 don't have an answer to your question but I think you're being unfairly downvoted.
Great to see.
Author: do you see issues with that use case?
[0] https://www.youtube.com/watch?v=7g1Acy5eGbE&t=5m3s
have a filesystem, userspace, peripheral support...
https://github.com/jprx/fractal