Modern Microkernels: The Evolution of Operating

Systems Research in Broad Strokes

Nathan TeGrotenhuis

Abstract
A microkernel operating system provides a small set of basic abstractions typically including primitives for
memory management, interprocess communication, and task management, that provide all necessary hardware
functionality. The rest of the operating system such as the file system, drivers, and daemons / servers are executed
in user land. This paper attempts to inform the reader about the strengths of the microkernel approach, providing a
brief overview of the history and influence of the Mach and L4 kernels, and then looking to the future by presenting
two research operating systems that utilize microkernels: MINIX 3 and Singularity.
 I. I NTRODUCTION
It is a commonly held belief that the design of current operating systems have not kept pace with the
evolution of hardware and software. Since the operating system is the foundation of the software stack,
so inadequacies in OS design cascade. Influencing the design of the rest of the software that is run on
it problems with the OS design hinder usability of any software running on it. Historically, maximizing
the speed of linear programs was a primary objective of operating systems design. Monolithic kernels
traditional met this requirement by avoiding the overhead involved with communication between the kernel
and user mode programs. However, this kind of design is not well suited to the needs of evolving modern
technologies. Since microkernels offer a simple set of abstractions to user mode programs, they enable
great flexibility and organization that help careful design of the higher level services and programs. Much
current operating systems research, for example Microsoft’s Singularity Project, and Tenenbaum’s MINIX
3 continue a redesign operating systems using microkernels to support the ever changing ways computers
are used.
Microkernels suffered major setbacks in the late 1980s and early 1990s due to the weak performance of
Mach [3]. However, this problem was partially solved in the creation of the L4 kernel [8] which is much
more efficient than Mach and the dramatic increase in the speed of hardware has made the overhead from
a microkernel more acceptable for many applications. The advantages of Microkernels include simplicity,
extensibility, and security. Their simple design means that bugs are less likely to occur in kernel mode
and that it can be possible to understand the interactions between different components of the system.
Because a microkernel provides only a small set of basic primitives, one microkernel may support a
variety of different approaches to design of the higher levels of abstraction in user land. This extensibility
means that one microkernel, for example L4 can serve both as a virtulization layer in high performance
applications and as a kernel for embedded devices. The modular design of microkernels makes it easier
to isolate processes and resources in the interest of security. Since the microkernel concept supports these
goals of operating systems research, it is natural that cutting edge research projects use them.
Computer users expect their computers to work. MINIX 3 is focused on applications on consumer
machines such as desktops, notebooks, and portable devices. The overhead that comes with reliability
and self healing is too great for high performance applications [5]. Fortunately, consumers have few high
performance needs, instead they use web services and their expensive computation is performed in the
cloud. The goal of MINIX 3 is to achieve a mean time to failure so long that few users would ever
experience a crash. MINIX 3 is built around a microkernel and uses a sophisticated system of daemons
to offer services to programs in user land. The kernel is only 5000 lines of code, compared to 5 millions
lines in the windows XP kernel or 2.5 million lines in the Linux kernel. As the name suggests, MINIX
3 supports a UNIX environment.
Microsoft’s Singularity system is more experimental than MINIX 3, and while their philosophies of
design are similar, their objectives are different [7]. While MINIX 3 accepts the overhead associated with
a microkernel’s use of message passing between many processes, Singularity focuses at performance of
parallel programming and inter-process communication while sacrificing performance of other components.
Most of the Singulariy kernel is written in the Sign# language (an extension of C# created for Singularity)
which is type-safe, and garbage collected. Both systems emphasize a simple design to reduce the likelihood
of bugs.

II. H ISTORY: M ACH AND XNU

Mach was developed at Carnegie Mellon in 1986 as a microkernel for UNIX [1]. During that era in
operating systems research, it was clear that multiprocessor machines would increasingly be used and that
future operating systems should easily scale to take advantage of such systems. Mach was designed to
support distributed environments and complicated architectures using the UNIX model of interfaces. This
allowed a consistent framework for designing systems on varied kinds of hardware. It was also designed
to exploit the fundamental advantage of microkernels that the damage a bug can cause is minimized by
moving more code into user space rather than kernel space [6].
The design of Mach set a precedence for design of microkernel systems by providing a small set of basic
functions in the kernel. These functions support the foundation for more complex services and utilities,
called servers, that run in user mode. The Mach kernel provides four basic abstractions (tasks, threads,
ports, and messages) that support creating servers and enabling them to interact with other programs. The
Mach kernel acts as a server for these abstractions and provides an API which user level programs may
access. A task contains a virtual address space and access to other resources such as cores, and virtual
memory. Each task may possess multiple threads, each of which is a separate execution path. Ports and
messages facilitate interprocess communication. A port is an object-oriented contract with the kernel that
accepts and sends messages. A task asks the kernel which ports it can use to send or receive messages. It
then can sends a message by sending an object of some type to a port that accepts that type. The kernel
then directs that message to the appropriate receiving port on another task or thread.
Mach’s interprocess communication model provided very good support both for distributed and multi-
core computing. Unfortunately, Mach suffered significant performance issues that inhibited its success as
a UNIX kernel. One reason was that implementing UNIX compatible services requires a large number
of tasks and considerable interprocess communication [2]. Each message passed to a port in the kernel
required a context switch into kernel mode, execution of kernel code, and then a context switch into
user mode to execute the task responsible for handling the message. All this context and mode switching
accrued great overhead. Another cause of inefficiency was that the kernel did not effectively utilize the
CPU cache, frequently overfilling and flushing the cache causing a lot of wasted CPU time. These problems
were mitigated in the development of XNU the basis of OSX and IOS by moving user mode utilities into
the kernel at the sacrifice of microkernel principles [6].

III. S ECOND G ENERATION : L4

The most microkernel used in commercial applications is L4 [8]. Originally developed in 1994 and
designed with performance in mind, L4 took lessons learned from the design of Mach and developed
a very useful system. L4 has a much simpler interprocess communication model than Mach helping it
achieve much greater performance. L4 was carefully tuned for optimal cache utilization and minimal
IPC overhead in order to achieve performance that was considered almost unachievable at the time. L4’s
breakthrough has been credited with restoring interest in microkernel research. L4 thus takes advantage of
the nature of a microkernel in a way that improves rather than worsens performance because the processor
cache can hold most of high performance code in the simple kernel.
L4 is commonly used in embedded devices, cell phones and as a virtualization layer enabling guest
operating systems to run as services on top of L4. Because of its simplicity and generality, L4 is easy
to port to many platforms. Developers wishing to port an operating system onto a new platform may
find that it is easier to port L4 to that platform and run their chosen OS on top of L4 than to port their
whole OS to the platform. Versions of Linux, BSD, SymbianOS, Android, and Windows have all been
implemented over the L4. These implementations is that they can take advantage of L4’s security and
robustness to ensure that they are isolated from other virtual machines.

IV. R ELIABILITY AND S ELF H EALING : MINIX 3

In contrast to L4, the goal of MINIX 3 is not performance, but perfection [4]. MINIX 3 was announced
in 2005 and designed with the assumption that average computer users expect their systems to function
flawlessly. MINIX 3 takes the concept of a multikernel further than previous work such as Mach and
L4. MINIX 3 takes many ideas from earlier operating systems research in fault tolerance, multiserver
operating systems, separation of policies and mechanisms, error detection and transparent recovery for
driver failures. MINIX 3 attempts to achieve compatibility with existing UNIX/LINUX programs and
paradigms to encourage its adoption.
The main weakness of monolithic kernels that MINIX 3 addresses is the fact that the kernel program
is so big and complex that it inevitably contains bugs. Moreover, since drivers in such systems generally
run in kernel mode, bugs in drivers are bugs in the kernel. Since drivers are much more likely to contain
bugs (being developed by third parties and less rigorously tested than main branch kernel code), running
drivers in kernel mode greatly damages reliability. By limiting kernel mode code to a simple microkernel
and excluding drivers, MINIX 3 reduces the risk of bugs causing system instability.
Drawing ideas from the Nooks project in Linux [11], which keeps running drivers in protective wrappers
that protect the rest of the system from faults in the driver, MINIX 3 uses a multi-server architecture to
isolate drivers and other programs in user mode processes that are handled by a process manager. The
kernel handles interrupt handling, sending instructions to processors, I/O scheduling, and provides a set of
functions to enable interprocess communication. Message passing is performed through shared memory.
Simplifying the design even further than L4, MINIX 3 performs no interprocess communication buffering
in the kernel. The kernel also contains a table of policies that determine what privileges each process in
the system has at its disposal. Each process might have access to only some subset of IPC functions, only
be allowed to communicate to certain processes, use certain blocks of memory ect. The kernel is broken
down into two different programs, SYS and CLOCK. SYS handles low level kernel operations such as
process and memory management and I/O. CLOCK performs cpu scheduling and interrupt handling.
MINIX 3 also consists of a set of user mode programs that implement the POSIX specification and
facilitate a UNIX compatible environment. These modules are the Data Store (DS), the Memory Manager
(MM), the Reincarnation Server (RS), the File Server (FS), and the Process Manager (PM). The Memory
Manager, File Server, and Process Manager basically provide the standard functionality found in many
systems. They also provide the POSIX interface through functions such as fork(), open(), and malloc(). One
advantage of this design is that modules and programs are not implementation dependent. For example,
different memory management schemes that support the interface of the Memory Manager can be swapped
in and out.
The Reincarnation Server helps to manage privileged process such as servers and drivers. Programs that
run with privileges are created as children of the Reincarnation Server process. Whenever a system process
exits, a signal is sent to the RS which may tell it to restart the service. The RS can also periodically ping
services to see if they are alive and responsive, and if they are not then the RS has the ability to restart
them. The quantum based process scheduler will decay the priority of processes that are stuck in infinite
loops to the point that they become unresponive. The RS will then recognize that they are broken and
restart them.
The Data Store contributes to fault tolerance by allowing system processes to store their states so that
if they must be restarted by the RS their State may be partially recovered from the version in the DS.
The DS also assigns a name to each process which is then looked up during interprocess communication
so that messages can be passed to the right process. The DS enables interprocess communication without
requiring a buffer in the kernel.
The Reincarnation Server and the Data Store work together so the system can isolate faults and then
recover to a stable state by restarting the broken process instead of the whole computer. Using the principle
of least authority, [9] they limit the privileges of each process to the minimum. Programs normally cannot
even call kernel functions, but must use the POSIX interface and even the set of processes that are allowed
to be communicated with is limited. Different policies for fault recovery can be set in the RS depending
on what kind of process has failed and in what way.
The performance of MINIX 3 is not as good as L4, but MINIX 3 provides a very robust system in
addition to a full POSIX implementation that was designed along with the kernel to meet the same goals.
However, its ecosystem has less similarity to the traditional design such as Mach. This makes MINIX 3
more complicated than L4 and potentially makes it harder to program and design systems for it. MINIX
3 is a much newer system than L4, and is under active development. It may eventually compete with L4
as a UNIX microkernel.

V. P ERFORMANCE AND S OFTWARE I SOLATED P ROCESSES : S INGULARITY

Singularity, from Microsoft Research takes an entirely different road from L4 and Minix 3. Rather than
attempt to create a microkernel that can serve as the basis for existing OS designs patterns, Singularity
tries a lot of new and different ideas [7]. Using Software-Isolated Processes (SIP), a managed code
environment, contract-based communication channels, and manifest-based programs Singularity is more
like a laboratory for experimenting with new concepts in operating systems than a system designed for
widespread adoption. Most of the system is programmed using Sign#, an extension of C# that supports
low level systems programming. One interesting lesson from Singularity is that the choice of language
can play a huge role in the design of an operating system.
Software Isolated Processes are like processes but are efficiently isolated by the Sing# language’s type
and memory safety. All user programs are contained within a SIP which handles information about what
resources the process has access to and the execution context. SIPs are an impressive security feature.
The kernel is able to verify algorithmically using both static and runtime checks that code in a SIP cannot
access memory outside of its assigned region. Avoiding the overhead of hardware for memory management
and isolation, SIPs are extremely lightweight. They can be created without creating page tables, and they
don’t require flushing of TLBs during creation or context switches. This makes them suitable as a fine
grained solution to support operating systems services. Singularity’s design is greatly simplified because
the power SIPs reduces the need for redundant systems.
The second unique feature of Singularity is the use of Contract Based Channels for interprocess
communication between SIPs. They are real time verifiable which means that mistakes in contracts can
be easily detected. They are very efficient and support information sharing without requiring memory to
be copied. Contract Based Channels are a feature of Sing# and the compiler can analyze and verify them
for consistency.
Manifest Based Programs are the third foundational Singularity feature. To start a program, a user
invokes a manifest rather than running an executable file. A manifest describes not only the code associated
with a program, but also it’s configuration meta data, permissions, and dependencies. The manifest is a
description of the program’s expected behavior that can be verified at runtime to ensure security and
safety. The manifest can either be a binary or code in a scripting language. Because the manifest provides
guarantees type safety and many important run time properties the OS can actually compile Sing# programs
native code, rather than running them in the Microsoft Common Language Runtime environment.

VI. C ONCLUSION : C OMMON T HREADS AND F UTURE S YSTEMS

Microkernels provide a good foundation for OS research because of their simplicity and extensibility.
The idea of minimizing the amount of code that has to run in kernel mode makes intuitive sense because
kernel mode is more dangerous. Many goals of operating system design such as modularity, isolation,
clearly defined interfaces, and consistent behaviors are already partially satisfied in the concept of a
microkernel. That both MINIX 3 and Singularity, two prominent research efforts utilize microkernels is
evidence that they are likely to be used in future operating systems. Both systems hope to achieve enhanced
security and reliability beyond the capabilities of current technologies and sacrifice performance concerns
in exchange for their other goals.
Despite these broad similarities, the two projects are extremely different, but observing them both
provides some insights. The most fundamental difference in objectives is that MINIX 3 serves as a basis
on which a full UNIX system can be built whereas Singularity isn’t backwards compatible with anything.
Providing a POSIX implementation constrains the flexibility of MINIX 3’s design. Where Singularity
refreshes the entire concept of processes, MINIX 3 offers a more traditional approach augmented by the
presence of the reincarnation server and data store. MINIX 3 seems more like another iteration in the
patterns of Mach and L4. While the decision to support UNIX compatibility limits MINIX 3’s ability to
innovate in new directions, it also increases the likelihood that the system will gain supporters since a
large number of popular applications such as vi, emacs, bash, and X11 have already been ported to the
system.
Singularity pushes boundaries in so many different directions that it is difficult to tell which of its
features are the most valuable, and which may be unnecessary or sub-optimal. The idea that seems most
profound is the use of a garbage collected, type safe language for kernel development. The degree to
which Sing# is integrated in the system makes it easy to understand how incredible features such as
Software Isolated Processes, and verification are achieved. The papers on Singularity discuss a wide array
of potential benefits and pitfalls of the various innovations in the system that are beyond the scope of
this discussion, but it is clear that the choice to design the system from scratch provided a very valuable
testing ground. However, since Singularity is so dramatically experimental, it is not likely to attract many
users. It seems reasonable to think that Microsoft is using it to prototype ideas for future versions of
Windows or even planning on developing it as a co-existing technology to replace Windows many years
from now.
Mach showed that the fundamental ideas behind the microkernel approach were good, but suffered
from performance issues. These drawbacks are understandable for such an early approach, and L4 solved
these problems through it’s performance focused design. Though L4 made only limited contributions to
the research ecosystem, it importantly showed that microkernels can be practical in the real world, even
in performance intensive settings such as embedded devices and cell phones. MINIX 3 and Singularity
are just two of several current research projects utilizing microkernels, but they offer an interesting taste
of the types of ideas currently being studied. Perhaps features drawing from the ideas of MINIX 3 will
become a part of consumer systems in the near future, maybe 2 or 3 years. Because Singularity lacks a
backwards compatible and I think it may be a decade before a kernel written in a language like Sing#
is ready for widespread adoption. It may even come to pass that further improvements in programming
languages such as F# may open new avenues for innovation in operating systems.
It seems natural that the discussion of operating systems in this paper moved away from discussion of
the specifics of microkernels. Their very nature is that they are simple and easy to understand. What is so
interesting is the flexibility of the paradigm that such different systems as MINIX 3 and Singularity are
actually quite similar at the low levels. Both kernels provide a simple set of abstractions for interprocess
communication, memory management, and task handling and many of the interesting abstractions such
as the Reincarnation Server and Manifests actually run in user mode.
 R EFERENCES
[1] M. Accetta, R. Baron, W. Bolosky, D. Golub, R. Rashid, A. Tevanian, and M. Young. Mach: A new kernel foundation for UNIX
development. contract, 39(85-C):1034.
[2] M. Condict, D. Bolinger, E. McManus, D. Mitchell, and S. Lewontin. Microkernel modularity with integrated kernel performance.
Technical report, Technical report, OSF Research Institute, Cambridge, MA, 1994.
[3] H. H
”artig, M. Hohmuth, J. Liedtke, J. Wolter, and S. Sch
”onberg. The performance of µ-kernel-based systems. In Proceedings of the sixteenth ACM symposium on Operating systems principles,
pages 66–77. ACM, 1997.
[4] J. Herder, H. Bos, B. Gras, P. Homburg, and A. Tanenbaum. Reorganizing unix for reliability. Advances in Computer Systems
Architecture, pages 81–94, 2006.
[5] J.N. Herder, H. Bos, B. Gras, P. Homburg, and A.S. Tanenbaum. MINIX 3: A highly reliable, self-repairing operating system. ACM
SIGOPS Operating Systems Review, 40(3):80–89, 2006.
[6] T. Holwerda. Kernel designs explained, 2007.
[7] G.C. Hunt and J.R. Larus. Singularity: rethinking the software stack. ACM SIGOPS Operating Systems Review, 41(2):37–49, 2007.
[8] S. Ruocco. Real-time programming and L4 microkernels. In Proceedings of the 2006 Workshop on Operating System Platforms for
Embedded Real-Time Applications, Dresden, Germany. Citeseer, 2006.
[9] J.H. Saltzer and M.D. Schroeder. The protection of information in computer systems. Proceedings of the IEEE, 63(9):1278–1308,
1975.
[10] J.S. Shapiro and N. Hardy. EROS: A principle-driven operating system from the ground up. IEEE Software,, pages 26–33, 2002.
[11] M.M. Swift, B.N. Bershad, and H.M. Levy. Improving the reliability of commodity operating systems. In Proceedings of the nineteenth
ACM symposium on Operating systems principles, pages 207–222. ACM, 2003.