There used to be a debate between folks about whether monolithic kernels or microkernels were the superior architecture. It might have been interesting, but it got pretty ugly at times. While the flame war raged on, research and development continued in parallel within both the academic and industrial worlds. Looking back on it now, it's clearly not merely a matter of monolith vs. microkernel architecture. Rather, it's a larger discussion about code modularity.
The last few years have shown us a few key trends hidden among the often-overlooked activity in the world of Operating System (OS) development. Chief among them is the idea that the future need not look like the past. From Google's Fuchsia project to BPF in Linux, the era of kernel modularity has arrived.
Modular kernels currently under development
If you keep your ear to the ground, you'll inevitably hear the excited rumblings of folks watching the not-so-secret development of Google's new open source Fuchsia operating system. The Fuchsia kernel is called Zircon and is written in C++. Zircon is notable for a variety of reasons, not the least of which is the eschewing of the traditional POSIX standard in favor of what it's supporters refer to as "more modern" conventions. Of particular note is the intentional deprecation of dotdot filesystem conventions for security reasons. Anyone interested in what else Google's Fuchsia team considers to be modern conventions should be referred to the Fuchsia docs, with the most popular destination being The Book. This recent set of notes from China may also be of interest.
Though Google Fuchsia has forsaken POSIX, not all modular kernels have followed suit. For example, the Redox project has opted to continue the POSIX tradition while clearly going for a microkernel approach. Since the goal of Redox is to make a reliable, secure, general purpose OS, the team chose to write everything in the Rust programming language. This seems like a great idea as Rust has really wonderful safety guarantees and very ergonomic error handling.
On the Rust front, Redox isn't the only game in town as the new Tock OS receives more attention for targeting embedded and low-power systems. The website touts the ability for Tock to run on everything from industrial sensors to security keys to watches. If you're into IoT and value security and reliability, keep an eye on Tock.
Moreover, there's even an experimental research OS called Manticore, also written in Rust, aiming to explore the world and concepts of parakernels.
No discussion of modular kernels would be complete without a mention of the Genode project. Genode isn't an actual kernel so much as a microkernel construction kit. Even though it's written in C++, Genode claims that it offers a security-first approach to OS development with sights set on both IoT as well as more traditional workloads.
The monolith strikes back
Despite its roots as a monolithic kernel, Linux was always able to sidestep an entire class of problems by leveraging dynamically linked kernel modules at run time. However, while this has proven a successful strategy, the discussion of modularity has shifted with the advent of kernel support for running programs written using the Berkeley Packet Filter (BPF) mechanism. Originally developed for controlling network IO, BPF has since been extended (eBPF) to allow for attaching filters to various OS functions. The upshot of ePBF support in Linux is that it allows for tying code deep into the kernel without modifying the kernel itself.
Brendan Gregg has a terrific compilation of eBPF learning resources available on his blog and the IO Visor project also maintains a pretty solid overview. Also, there is a performance-oriented BPF book set to be published in October of 2019.
Even though they're certainly smaller than classical OSes, the newer world of Unikernels borrows heavily from the research world's development of nanokernels carrying with them the concept of a LibraryOS. Standing tall among them is the venerable MirageOS project, a library OS written entirely in OCaml. For people interested in the "mini-monolith" (minilith?) approach of Unikernels looking to develop in languages other than OCaml, the Unikernels website maintains a list of projects from which you can pick anything from Go to BEAM languages.
Another exciting option, geared more toward traditional development, is the UniK project started by my friend Idit Levine, which can take almost any existing program and produce a Unikernel from it. There are examples for common languages and platforms such as Node.js, Python3, and even Java. One of the cooler things about UniK is how clean the code is, you can read through the (Go) source and understand a great deal about how it provides a pluggable backend supporting flavors such as rumprun and even Firecracker.
What about a language VM as the kernel?
There have been multiple attempts to write OS kernels in interpreted or semi-compiled languages. Two of the most notable are actually the now defunct JNode and JX projects. However, one additional effort from the past also stands out as significant.
The Singularity OS research project at Microsoft has been discontinued now for the better part of a decade, but has continued to intrigue me whenever I think about it. An attempt to make an entire OS in nothing but C# and a minimal VM, it was rumored to have heavily leveraged a Just-In-Time (JIT) compiler to provide runtime profile and optimizations far beyond what a traditional Ahead-Of-Time (AOT) compiled kernel could offer. Additionally, the supposed memory safety of such managed languages could offer some terrific security guarantees like runtime memory inspection and execution supervision.
In recent months, I have watched the development of WebAssembly (WASM) and the announcement of the WebAssembly System Interface (WASI) with great interest. While tools like wasmer make it easy to run applications compiled to WASM, I was just exposed to this effort by the NanoVM folks to run WASM unikernels. Pretty cool.
Great, so what's the point?
There's clearly a larger discussion happening about code and system modularity in a variety of areas. As people explore techniques like microservice architectures (which are NOT a solution for every problem), the community continues to develop a variety of viewpoints. Therefore, it seems only natural that OS development would have a contribution to make to such discussions and that it would be influenced in return. Let's see what develops (pun intended).
Top comments (1)
Thank you Jonathan, it's a terrific overview :)
The landscape of practical and research operating systems is super lively!