To study how chips work, MIT researchers built their own operating system

312 points - last Monday at 4:06 PM

Comments

jprx today at 7:06 AM

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!

landr0id today at 5:36 AM

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.

polnurfer today at 1:12 PM

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.

feeley today at 8:02 AM

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?

ReyX today at 3:37 PM

  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.

austy69 today at 2:03 PM

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.

varispeed today at 5:29 PM

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! :-)

JdeBP today at 4:19 AM

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.

jdougan today at 3:26 AM

I wonder if this could be practical for controlled environment devices like game consoles.

deleted today at 5:01 PM

bell-cot today at 4:28 AM

> 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?

brador today at 7:55 AM

PHDs should be tool masters not knowledge basins.

Great to see.

j16sdiz today at 7:38 AM

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"

themafia today at 3:13 AM

The results are interesting but the whole project is worth a look.

https://people.csail.mit.edu/mengjia/data/2026.SP.fractal.pd...

p0w3n3d today at 6:37 AM

Will it allow them install personally-made software, or will it require Google's approval?

palmblock_dev today at 3:34 PM

[dead]

deleted today at 4:11 AM

peyton today at 3:13 AM

[flagged]