Timothy Roscoe (ETH Zurich, co-lead of the Barrelfish multikernel and the Enzian research computer) gave the joint OSDI/ATC keynote in 2021 and announced up front that he’d chosen the “keynote as therapy” format. What he unloads is a simple argument that keeps getting more true: the machine Linux thinks it runs on doesn’t exist, the thing actually managing a modern computer was never designed by anyone, and the systems research community has mostly stopped looking. Five years on, with every server carrying a BMC running hundreds of thousands of lines of code and every phone a dozen firmware-running cores, it reads less like a complaint and more like a description of where operating system work has to go.
A niche topic at its own conference
Roscoe starts with the program. OSDI 2021 had 31 papers; about six were about operating system design and implementation, while a quarter were machine learning. OS work didn’t get its own session and shared one with hardware, “which is ironic given what I’m about to talk about.” Most of the OS papers that did appear were built inside Linux and tuned it.
The folklore explanation is that Linux works, so why explore alternatives. His claim is the opposite: now is exactly when the field needs people who understand OS design, because hardware has changed in ways that break the model.
Define the OS by what it does
He rejects the ontological definition, “the kernel plus daemons plus runtime libraries,” as vague and as discouraging thought about what the OS is for. The definition he uses is functional and textbook-standard: the software that securely multiplexes the machine’s hardware, abstracts it, and protects applications, the OS and data from each other.
The rest of the talk applies that definition to real hardware and asks what it picks out.
The machine Linux imagines
The computer we teach is the one Unix was written for, slightly updated: a processor, memory, devices on a bus. The modern version is a cache-coherent NUMA machine with identical cores, a single physical address space, and devices on PCIe. The resulting OS is “just a special shared-memory multithreaded program” running processes on top. You can tweak locking, NUMA placement and drivers, or move drivers into user space, but the shape stays.
“This model of a cache-coherent NUMA machine is a fantasy. This is not what a computer looks like. This is what Linux wants a computer to look like.”
What computers actually look like
His evidence is a series of SoC block diagrams: NVIDIA Parker, a Xilinx Zynq, an NXP i.MX part used for teaching at ETH. Each circle is a different set of processors with a different view of physical address space, a different architecture, and coherence that may or may not exist. RISC-V was supposed to clean this up and hasn’t.
On such a chip, Linux runs on one small cluster. The rest runs a “random bric-a-brac” of real-time kernels, microkernels and firmware executives that collectively boot the system, manage power and enforce security. Apply the functional definition and the operating system for this machine includes Linux as one component among many.
“This is not an operating system that has been designed. This is an operating system that has congealed.”
Saying the phone “runs Linux,” he jokes, is like saying it runs SpongeBob Krusty Cook-Off because a game happens to run on part of the hardware.
Why it matters: security and power
The first example is the Qualcomm “QualPwn” exploit. Linux treats the WiFi modem as a dumb DMA device fenced by the system MMU. In reality the modem has its own DSP running its own OS. A malicious packet takes over that OS, which then persuades the Linux driver to program the SMMU in a way that looks legitimate but grants the modem access to all memory. The patch went into the driver. The underlying fault, that Linux assumes it’s the only OS and that there’s one physical address space with no pointer translation, stayed. He calls this class “cross-SoC attacks” and notes that DARPA workshops are worried about it.
Power management is the second example. On the NXP part, power policy runs on a separate set of cores responsible for bringing up the chip. Anything Linux tries to do with application knowledge is second-guessing a policy engine on another processor, with a different ISA and address space, that it can’t negotiate with.
Architects see the OS not solving these problems and route around it in hardware: hidden security processors, transparent power controllers. The result is that hardware is designed to sandbox Linux in a corner where it can’t cause trouble, and the OS has retreated into an enclave where the cozy model still holds.
The publishing incentive
The few new-OS papers in recent OSDIs all targeted PCs and ended up structurally similar to Linux. The message to students, as he reads it: work on ML, databases, consensus, graph processing, security or privacy, which all have their own dedicated venues, or if you insist on OSes, work on Linux, or something that looks like Linux.
His anecdote is the sharpest moment in the talk. His group built a Barrelfish version with a formally specified model of multiple address spaces that tracked authorization through every translation, which would have prevented the QualPwn class of bug. Formal methods venues loved it. Systems venues didn’t understand it because it wasn’t Linux. So they removed the implementation and evaluation sections, recast a subset as something that could map into Linux, and sent it to HotOS, where it was accepted. He diagnoses two problems in the community: ignorance of what hardware looks like, and denial, meaning a preference for staying in the part of the machine where Linux works.
Two suggestions
First, try to write a system that manages the whole chip. Development boards are cheap (a Raspberry Pi boots from its GPU, which makes it interesting already). The NXP reference manual is 8,981 pages, and his students find their way around it without trouble. Complexity is the business computer scientists are in, and formal specification, verified kernels, code synthesis from specs and runtime verification all depend on modelling the hardware accurately.
He connects this to the 2011 Mind the Gap paper he wrote with Jeff Mogul, Andrew Baumann and Livio Soares: architects and OS people barely talk, so architects solve OS problems in silicon, and SoC design is now ossifying around an OS that isn’t managing the machine.
Second, build your own computers, which is much easier than in 2011. ETH’s Enzian pairs a Cavium ThunderX with a large FPGA as a research platform. Building it taught them what’s inside a server. The board management controller at the centre of the signal-flow diagram sequences power and clocks, does thermal monitoring and throttling, can read and write memory and configure memory controllers, and runs several hundred thousand lines of code (Linux and OpenBMC) before the main CPU leaves reset. Every voltage regulator has its own processor. The idea that servers are the simple, cozy case, he says, did not survive writing that firmware.
From the Q&A
Asked whether he’s arguing that an SoC should be treated as a distributed system with one OS per core cluster, Roscoe says no. He made that argument with Barrelfish about 12 years earlier and it won a test-of-time award, but calling it a distributed system is another ontological move that doesn’t tell you how to make anything work. The task is to think about what manages the whole machine. On whether moving work to user space addresses the problem, he says it’s orthogonal: it still assumes uniform cores and a single address space. On whether OS work is just too hard: “Systems are hard, we must work harder,” and seL4 or FreeBSD are far easier starting points than Linux.
Key takeaways
- Define an operating system by function (multiplexing, abstraction, protection) and the OS of a modern SoC or server turns out to be far larger than Linux.
- The cache-coherent, homogeneous, single-address-space machine assumed by Linux and by most textbook diagrams doesn’t describe real hardware.
- The actual system-wide OS is a collection of undesigned firmware, RTOSes and executives that grew up around Linux.
- Cross-SoC attacks like QualPwn exploit the gap between Linux’s assumptions and the hardware, and driver patches don’t close it.
- Hardware designers respond to OS limitations by hiding more management functions from the OS, so the problem compounds.
- Servers aren’t the exception: a BMC running hundreds of thousands of lines of privileged code is standard.
- Roscoe’s prescription is to program whole SoCs from their manuals and to build research hardware, both far more feasible than a decade earlier.
Source
- Talk: It’s Time for Operating Systems to Rediscover Hardware
- Speaker: Timothy Roscoe (ETH Zurich)
- Event: USENIX ATC ‘21 / OSDI ‘21 joint keynote, July 2021
- Duration: 1:06:19
- URL: https://www.youtube.com/watch?v=36myc8wQhLo
Note: the highest-resolution source for this upload is 720p, so these screenshots are below the series’ usual 1080p.