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

landr0id an hour ago | parent | next [-]

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.

▲

p0w3n3d 6 minutes ago | parent | prev | next [-]

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

▲

JdeBP 2 hours ago | parent | prev | next [-]

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.

▲

saagarjha 2 hours ago | parent [-]

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

	▲	JdeBP 2 hours ago \| parent [-]
		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.

▲

jdougan 3 hours ago | parent | prev | next [-]

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

▲

pyrolistical 3 hours ago | parent [-]

What do you mean? By the time you have kernel access like that you’ve already won.

	▲	myng111 21 minutes ago \| parent \| next [-]
		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.
	▲	karlgkk 3 hours ago \| parent \| prev [-]
		It’s practical in the sense that it lets a researcher find additional silicon bugs, although most game consoles now use merchant archs anyways

▲

bell-cot 2 hours ago | parent | prev | next [-]

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

▲

themafia 4 hours ago | parent | prev [-]

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

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