View source for Microkernel

{{Short description|Kernel that provides fewer services than a traditional kernel}}
{{Use dmy dates|date=February 2021}}
{{More citations needed|date=September 2025}}
[[File:OS-structure.svg|thumb|450px|Structure of monolithic and microkernel-based operating systems, respectively]]

In [[computer science]], a '''microkernel''' (often abbreviated as '''μ-kernel''') is the near-minimum amount of [[software]] that can provide the mechanisms needed to implement an [[operating system]] (OS). These mechanisms include low-level [[address space]] management, [[thread (computing)|thread]] management, and [[inter-process communication]] (IPC).

If the hardware provides multiple [[Protection ring|rings]] or [[CPU modes]], the microkernel may be the only software executing at the most privileged level, which is generally referred to as [[kernel mode|supervisor or kernel mode]]. Traditional operating system functions, such as [[device driver]]s, [[protocol stack]]s and [[file system]]s, are typically removed from the microkernel itself and are instead run in [[user space]].<ref>{{cite web
 | url = http://www.minix3.org/theses/herder-true-microkernel.pdf
 | title = Toward a True Microkernel Operating System
 | date = 23 February 2005 | access-date = 22 June 2015
 | first = Jorrit N. | last=Herder | website = minix3.org
}}</ref>

In terms of the source code size, microkernels are often smaller than [[monolithic kernel]]s. The [[MINIX&nbsp;3]] microkernel, for example, has only approximately 12,000 lines of code.<ref>{{cite web|url=http://wiki.minix3.org/doku.php?id=www:documentation:read-more|title=read-more|access-date=20 December 2016}}</ref>

==History==
Microkernels trace their roots back to Danish computer pioneer [[Per Brinch Hansen]] and his tenure in Danish computer company [[Regnecentralen]] where he led software development efforts for the RC 4000 computer.<ref name="ieee_2002">{{cite web
| url = https://www.computer.org/profiles/per-hansen
| title = Per Brinch Hansen
| publisher = IEEE Computer Society
| access-date = 13 September 2016
}}
</ref> In 1967, Regnecentralen was installing a RC 4000 prototype in the [[Zakłady Azotowe Puławy]] fertilizer plant in Poland. The computer used a small real-time operating system tailored for the needs of the plant. Brinch Hansen and his team became concerned with the lack of generality and reusability of the RC 4000 system. They feared that each installation would require a different operating system so they started to investigate novel and more general ways of creating software for the RC 4000.<ref name="Hansen_2004">{{cite book
| url = http://brinch-hansen.net/memoirs/contents.html
| title = A Programmer's Story: The Life of a Computer Pioneer
| last= Brinch Hansen
| first=Per
| year=2004
| access-date = 13 September 2016}}
</ref>
In 1969, their effort resulted in the completion of the [[RC 4000 multiprogramming system|RC 4000 Multiprogramming System]]. Its nucleus provided inter-process communication based on message-passing for up to 23 unprivileged processes, out of which 8 at a time were protected from one another. It further implemented scheduling of time slices of programs executed in parallel, initiation and control of program execution at the request of other running programs, and initiation of data transfers to or from peripherals. Besides these elementary mechanisms, it had no built-in strategy for program execution and resource allocation. This strategy was to be implemented by a hierarchy of running programs in which parent processes had complete control over child processes and acted as their operating systems.<ref name="Hansen_1969">{{cite tech report
| first = Per
| last = Brinch Hansen
| title = RC 4000 Software: Multiprogramming System
| institution = Regnecentralen
| date = April 1969
| url = http://brinch-hansen.net/papers/1969a.pdf
| access-date = 13 September 2016
}}
</ref><ref>{{cite journal
 | author = Brinch Hansen, Per
 | year = 1970
 | volume = 13
 | title = The Nucleus of a Multiprogramming Operating System
 | journal = Communications of the ACM
 | pages = 238–250
 | url = http://www.brinch-hansen.net/papers/1970a.pdf
 | doi = 10.1145/362258.362278
 | citeseerx = 10.1.1.105.4204
 | issue = 4
| s2cid = 9414037
 }}
</ref>

Following Brinch Hansen's work, microkernels have been developed since the 1970s.<ref name="Wulf_74">.{{cite journal
 | last1 = Wulf
 | first1 = William
 | last2 = Cohen
 | first2 = Ellis
 | last3 = Corwin
 | first3 = William
 | last4 = Jones
 | first4 = Anita
 | last5 = Levin
 | first5 = Roy
 | last6 = Pierson
 | first6 = C.
 | last7 = Pollack
 | first7 = Fred
 | date = June 1974
 | title = HYDRA: The Kernel of a Multiprocessor Operating System
 | journal = Communications of the ACM
 | volume = 17
 | issue = 6
 | pages = 337–345
 | doi = 10.1145/355616.364017
 | s2cid = 8011765
 | doi-access = free
 }}</ref> The term microkernel itself first appeared no later than 1981.<ref name="Rashid_81">{{cite conference
 | last1 = Rashid
 | first1 = Richard
 | last2 = Robertson
 | first2 = George
 | title = Accent: A communication oriented network operating system kernel
 | doi = 10.1145/800216.806593
 | book-title = SOSP '81 Proceedings of the eighth ACM symposium on Operating systems principles
 | pages = 64–75
 | date = December 1981
 | location = Pacific Grove, California, USA
 }}</ref> Microkernels were meant as a response to changes in the computer world, and to several challenges adapting existing "[[mono-kernel]]s" to these new systems. New device drivers, protocol stacks, file systems and other low-level systems were being developed all the time. This code was normally located in the monolithic kernel, and thus required considerable work and careful code management to work on. Microkernels were developed with the idea that all of these services would be implemented as user-space programs, like any other, allowing them to be worked on monolithically and started and stopped like any other program. This would not only allow these services to be more easily worked on, but also separated the kernel code to allow it to be finely tuned without worrying about unintended side effects. Moreover, it would allow entirely new operating systems to be "built up" on a common core, aiding OS research.

Microkernels were a very hot topic in the 1980s when the first usable [[local area network]]s were being introduced.{{Citation needed|date=November 2012}}. The AmigaOS [[Exec (Amiga)|Exec]] kernel was an early example, introduced in 1986 and used in a PC with relative commercial success. The lack of memory protection, considered in other respects a flaw, allowed this kernel to have very high message-passing performance because it did not need to copy data while exchanging messages between user-space programs.<ref name="amiga_rkm_libs_exec">{{cite book|title=Amiga ROM Kernel Reference Manual|last=Sassenrath|first=Carl|year=1986|location=Exec}}</ref>

The same mechanisms that allowed the kernel to be distributed into user space also allowed the system to be distributed across network links. The first microkernels, notably [[Mach (kernel)|Mach]] created by [[Richard Rashid]], proved to have disappointing performance, but the inherent advantages appeared so great that it was a major line of research into the late 1990s.<ref>{{cite web |title=CMU CS Project Mach Home Page |url=https://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html |website=www.cs.cmu.edu |publisher=Carnegie Mellon University |access-date=8 August 2024}}</ref> However, during this time the speed of computers grew greatly in relation to networking systems, and the disadvantages in performance came to overwhelm the advantages in development terms.{{citation needed|date = June 2015}}

Many attempts were made to adapt the existing systems to have better performance, but the overhead was always considerable and most of these efforts required the user-space programs to be moved back into the kernel. By 2000, most large-scale [[Mach (kernel)|Mach]] kernel efforts had ended, although Apple's [[macOS]], released in 2001, still uses a [[hybrid kernel]] called [[XNU]], which combines a heavily modified (hybrid) [[OSF/1]]'s [[Mach kernel]] ([[OSF MK]] 7.3 kernel) with code from BSD UNIX,<ref>{{cite AV media|url=https://www.youtube.com/watch?v=ggnFoDqzGMU |archive-url=https://ghostarchive.org/varchive/youtube/20211211/ggnFoDqzGMU| archive-date=2021-12-11 |url-status=live|author=Jim Magee|title=WWDC 2000 Session 106 - Mac OS X: Kernel|minutes=14}}{{cbignore}}</ref><ref>{{cite web|title=Porting UNIX/Linux Applications to Mac OS X|url=https://developer.apple.com/library/mac/#documentation/Porting/Conceptual/PortingUnix/glossary/glossary.html#//apple_ref/doc/uid/TP40002859-TPXREF101|publisher=Apple|access-date=26 April 2011}}</ref> and this kernel is also used in [[iOS]], [[tvOS]], and [[watchOS]]. [[Windows NT]], starting with [[Windows NT 3.1|NT 3.1]] and continuing with [[Windows 11]], uses a hybrid kernel design. {{As of|2012}}, the Mach-based [[GNU Hurd]] is also functional and included in testing versions of [[Arch Linux]] and [[Debian]].

Although major work on microkernels had largely ended, experimenters continued development.<ref>{{cite web |title=Redox - Your Next(Gen) OS - Redox - Your Next(Gen) OS |url=https://www.redox-os.org/ |website=www.redox-os.org}}</ref><ref>{{cite web |title=Helios |url=https://ares-os.org/docs/helios/ |website=ares-os.org |language=en-us}}</ref> Using a more pragmatic approach to the problem, including [[assembly code]] and relying on the processor to enforce concepts normally supported in software led to a new series of microkernels with dramatically improved performance.

Microkernels are closely related to [[exokernel]]s.<ref name="Liedtke_96">{{cite journal
 | last = Liedtke
 | first = Jochen
 | date = September 1996
 | title = Towards Real Microkernels
 | journal = Communications of the ACM
 | volume = 39
 | issue = 9
 | pages = 70–77
 | doi = 10.1145/234215.234473
 | s2cid = 2867357
 | doi-access = free
 }}</ref> They also have much in common with [[hypervisor]]s,<ref name="Heiser_UL_06">{{cite journal
 |title        = Are Virtual-Machine Monitors Microkernels Done Right?
 |author-link1 = Gernot Heiser
 |last1        = Heiser
 |first1       = Gernot
 |last2        = Uhlig
 |first2       = Volkmar
 |last3        = LeVasseur
 |first3       = Joshua
 |journal      = ACM SIGOPS Operating Systems Review
 |volume       = 40
 |issue        = 1
 |pages        = 95–99
 |date         = January 2006
 |url          = http://os.ibds.kit.edu/65_747.php
 |publisher    = ACM
 |doi          = 10.1145/1113361.1113363
 |s2cid        = 7414062
 |access-date  = 13 January 2014
 |archive-date = 13 January 2014
 |archive-url  = https://web.archive.org/web/20140113115308/http://os.ibds.kit.edu/65_747.php
 |url-status   = dead
}}</ref> but the latter make no claim to minimality and are specialized to supporting [[virtual machine]]s; the [[L4 microkernel]] frequently finds use in a hypervisor capacity.

==Introduction==
Early operating system kernels were rather small, partly because computer memory was limited. As the capability of computers grew, the number of devices the kernel had to control also grew. Throughout the early history of [[Unix]], kernels were generally small, even though they contained various [[device driver]]s and [[file system]] implementations. When address spaces increased from 16 to 32 bits, kernel design was no longer constrained by the hardware architecture, and kernels began to grow larger.

The [[Berkeley Software Distribution]] (BSD) of [[Unix]] began the era of larger kernels. In addition to operating a basic system consisting of the CPU, disks and printers, BSD added a complete [[protocol stack|TCP/IP networking system]] and a number of "virtual" devices that allowed the existing programs to work 'invisibly' over the network. This growth continued for many years, resulting in kernels with millions of lines of [[source code]]. As a result of this growth, kernels were prone to bugs and became increasingly difficult to maintain.

The microkernel was intended to address this growth of kernels and the difficulties that resulted. In theory, the microkernel design allows for easier management of code due to its division into [[user space]] services. This also allows for increased security and stability resulting from the reduced amount of code running in [[kernel mode]]. For example, if a networking service crashed due to [[buffer overflow]], only the networking service's memory would be corrupted, leaving the rest of the system still functional.

==Inter-process communication==
[[Inter-process communication]] (IPC) is any mechanism which allows separate processes to communicate with each other, usually by sending [[message passing|messages]]. [[Shared memory]] is, strictly defined, also an inter-process communication mechanism, but the abbreviation IPC usually refers to message passing only, and it is the latter that is particularly relevant to microkernels. IPC allows the operating system to be built from a number of smaller programs called servers, which are used by other programs on the system, invoked via IPC. Most or all support for peripheral hardware is handled in this fashion, with servers for device drivers, [[network protocol stack]]s, file systems, graphics, etc.

IPC can be synchronous or asynchronous. Asynchronous IPC is analogous to network communication: the sender dispatches a message and continues executing. The receiver checks ([[Polling (computer science)|polls]]) for the availability of the message, or is alerted to it via some notification mechanism. Asynchronous IPC requires that the kernel maintains buffers and queues for messages, and deals with buffer overflows; it also requires double copying of messages (sender to kernel and kernel to receiver). In synchronous IPC, the first party (sender or receiver) blocks until the other party is ready to perform the IPC. It does not require buffering or multiple copies, but the implicit rendezvous can make programming tricky. Most programmers prefer asynchronous send and synchronous receive.

First-generation microkernels typically supported synchronous as well as asynchronous IPC, and suffered from poor IPC performance. [[Jochen Liedtke]] assumed the design and implementation of the IPC mechanisms to be the underlying reason for this poor performance. In his [[L4 microkernel family|L4 microkernel]] he pioneered methods that lowered IPC costs by an [[order of magnitude]].<ref name="Liedtke_93">{{cite conference
 | first = Jochen
 | last = Liedtke
 | author-link = Jochen Liedtke
 | title = Improving IPC by kernel design
 | conference = 14th ACM Symposium on Operating System Principles
 | pages = 175–88
 |date=December 1993
 | location = Asheville, NC, USA
 | citeseerx = 10.1.1.40.1293
 }}</ref> These include an IPC system call that supports a send as well as a receive operation, making all IPC synchronous, and passing as much data as possible in registers. Furthermore, Liedtke introduced the concept of the ''direct process switch'', where during an IPC execution an (incomplete) [[context switch]] is performed from the sender directly to the receiver. If, as in L4, part or all of the message is passed in registers, this transfers the in-register part of the message without any copying at all. Furthermore, the overhead of invoking the scheduler is avoided; this is especially beneficial in the common case where IPC is used in a [[remote procedure call]] (RPC) type fashion by a client invoking a server. Another optimization, called ''lazy scheduling'', avoids traversing scheduling queues during IPC by leaving threads that block during IPC in the ready queue. Once the scheduler is invoked, it moves such threads to the appropriate waiting queue. As in many cases a thread gets unblocked before the next scheduler invocation, this approach saves significant work. Similar approaches have since been adopted by [[QNX]] and [[MINIX 3]].{{Citation needed|date=August 2010}}

In a series of experiments, Chen and Bershad compared memory [[cycles per instruction]] (MCPI) of monolithic [[Ultrix]] with those of microkernel [[Mach (kernel)|Mach]] combined with a [[4.3BSD]] [[Unix]] server running in [[user space]]. Their results explained Mach's poorer performance by higher MCPI and demonstrated that IPC alone is not responsible for much of the system overhead, suggesting that optimizations focused exclusively on IPC will have a limited effect.<ref name="Chen_Bershad_93">{{cite conference
 | first1 = J. Bradley
 | last1 = Chen
 | first2 = Brian N.
 | last2 = Bershad
 | title = The Impact of Operating System Structure on Memory System Performance
 | book-title = SOSP '93 Proceedings of the fourteenth ACM symposium on Operating systems principles
 | pages = 120–133
 | date= December 1993
 | location = Asheville, NC, USA
 | doi = 10.1145/168619.168629
 | url = https://people.eecs.berkeley.edu/~prabal/resources/osprelim/CB93.pdf
 }}</ref> Liedtke later refined Chen and Bershad's results by making an observation that the bulk of the difference between Ultrix and Mach MCPI was caused by capacity [[CPU cache#CACHE-MISS|cache-misses]] and concluding that drastically reducing the cache working set of a microkernel will solve the problem.<ref name="Liedtke_95">{{cite conference
 | first = Jochen
 | last = Liedtke
 | author-link = Jochen Liedtke
 | title = On µ-Kernel Construction
 | book-title = SOSP '95 Proceedings of the fifteenth ACM symposium on Operating systems principles
 | pages = 237–250
 | date= December 1995
 | location = Copper Mountain Resort, CO, USA 
 | doi = 10.1145/224056.224075
 | doi-access = free
 }}</ref>

In a client-server system, most communication is essentially synchronous, even if using asynchronous primitives, as the typical operation is a client invoking a server and then waiting for a reply. As it also lends itself to more efficient implementation, most microkernels generally followed L4's lead and only provided a synchronous IPC primitive. Asynchronous IPC could be implemented on top by using helper threads. However, experience has shown that the utility of synchronous IPC is dubious: synchronous IPC forces a multi-threaded design onto otherwise simple systems, with the resulting synchronization complexities. Moreover, an RPC-like server invocation sequentializes client and server, which should be avoided if they are running on separate cores. Versions of L4 deployed in commercial products have therefore found it necessary to add an asynchronous notification mechanism to better support asynchronous communication. This [[signal (computing)|signal]]-like mechanism does not carry data and therefore does not require buffering by the kernel. By having two forms of IPC, they have nonetheless violated the principle of minimality. Other versions of L4 have switched to asynchronous IPC completely.<ref name="elphinstone_2013">{{cite conference
 | first1 = Kevin
 | last1 = Elphinstone
 | first2 = Gernot
 | last2 = Heiser
 | title = From L3 to seL4: What Have We Learnt in 20 Years of L4 Microkernels?
 | book-title = SOSP '13 Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles
 | pages = 133–150
 | date = November 2013
 | location = Farmington, PA, USA 
 | doi = 10.1145/2517349.2522720
| doi-access = free
 }}
</ref>

As synchronous IPC blocks the first party until the other is ready, unrestricted use could easily lead to deadlocks. Furthermore, a client could easily mount a [[denial-of-service]] attack on a server by sending a request and never attempting to receive the reply. Therefore, synchronous IPC must provide a means to prevent indefinite blocking. Many microkernels provide [[timeout (telecommunication)|timeouts]] on IPC calls, which limit the blocking time. In practice, choosing sensible timeout values is difficult, and systems almost inevitably use infinite timeouts for clients and zero timeouts for servers. As a consequence, the trend is towards not providing arbitrary timeouts, but only a flag which indicates that the IPC should fail immediately if the partner is not ready. This approach effectively provides a choice of the two timeout values of zero and infinity. Recent versions of L4 and MINIX have gone down this path (older versions of L4 used timeouts). QNX avoids the problem by requiring the client to specify the reply buffer as part of the message send call. When the server replies the kernel copies the data to the client's buffer, without having to wait for the client to receive the response explicitly.<ref>{{cite web |title=Synchronous Message Passing |url=https://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.sys_arch/topic/ipc_Sync_messaging.html |access-date=3 September 2024 |ref=qnx_ipc}}</ref>

==Servers==
Microkernel servers are essentially [[daemon (computing)|daemon]] programs like any others, except that the kernel grants some of them privileges to interact with parts of physical memory that are otherwise off limits to most programs. This allows some servers, particularly device drivers, to interact directly with hardware.

A basic set of servers for a general-purpose microkernel includes file system servers, device driver servers, networking servers, [[display server]]s, and user interface device servers. This set of servers (drawn from [[QNX]]) provides roughly the set of services offered by a Unix [[monolithic kernel]]. The necessary servers are started at system startup and provide services, such as file, network, and device access, to ordinary application programs. With such servers running in the environment of a user application, server development is similar to ordinary application development, rather than the build-and-boot process needed for kernel development.

Additionally, many "crashes" can be corrected by simply [[Crash-only software|stopping and restarting the server]], which would not be feasible if the entire kernel had to reboot. However, part of the system state is lost with the failing server, hence this approach requires applications to cope with failure. A good example is a server responsible for [[Internet protocol suite|TCP/IP]] connections: If this server is restarted, applications will experience a "lost" connection, a normal occurrence in a networked system. For other services, failure is less expected and may require changes to application code. For QNX, restart capability is offered as the QNX High Availability Toolkit.<ref>{{cite web|url=http://www.qnx.com/download/download/8107/QNX_High_Availability_Toolkit.pdf|title=The QNX High Availability Toolkit|archive-url=https://web.archive.org/web/20050824015422/http://www.qnx.com/download/download/8107/QNX_High_Availability_Toolkit.pdf|archive-date=24 August 2005 }}</ref>

==Device drivers==
[[Device driver]]s frequently perform [[direct memory access]] (DMA), and therefore can write to arbitrary locations of physical memory, including various kernel data structures. Such drivers must therefore be trusted. It is a common misconception that this means that they must be part of the kernel. In fact, a driver is not inherently more or less trustworthy by being part of the kernel.

While running a device driver in user space does not necessarily reduce the damage a misbehaving driver can cause, in practice it is beneficial for system stability in the presence of buggy (rather than malicious) drivers: memory-access violations by the driver code itself (as opposed to the device) may still be caught by the memory-management hardware. Furthermore, many devices are not DMA-capable, their drivers can be made untrusted by running them in user space. Recently, an increasing number of computers feature [[IOMMU]]s, many of which can be used to restrict a device's access to physical memory.<ref name="Wong_07">{{cite journal |title=I/O, I/O, It's Off to Virtual Work We Go |url=http://www.electronicdesign.com/embedded/io-io-its-virtual-work-we-go |last=Wong |first=William |journal=[[Electronic Design (magazine)|Electronic Design]] |date=27 April 2007 |access-date=8 June 2009 }}</ref> This also allows user-mode drivers to become untrusted.

User-mode drivers actually predate microkernels. The [[Michigan Terminal System]] (MTS), in 1967, supported user space drivers (including its file system support), the first operating system to be designed with that capability.<ref>{{cite conference |title=Organization and Features of the Michigan Terminal System |first=Michael T. |last=Alexander |book-title=Proceedings of the November 16–18, 1971, Fall Joint Computer Conference |volume=40 |year=1971 |pages=589–591 |doi=10.1145/1478873.1478951|s2cid=14614148 |doi-access=free }}</ref> Historically, drivers were less of a problem, as the number of devices was small and trusted anyway, so having them in the kernel simplified the design and avoided potential performance problems. This led to the traditional driver-in-the-kernel style of Unix,<ref name="Lions book">{{cite book |title=Lions' Commentary on UNIX 6th Edition, with Source Code |last=Lions |first=John |date=1 August 1977 |isbn=978-1-57398-013-5 |publisher=Peer-To-Peer Communications|title-link=Lions' Commentary on UNIX 6th Edition, with Source Code }}</ref> Linux, and Windows NT. With the proliferation of various kinds of peripherals, the amount of driver code escalated and in modern operating systems dominates the kernel in code size.

==Essential components and minimality==
As a microkernel must allow building arbitrary operating system services on top, it must provide some core functionality. At a minimum, this includes:
* Some mechanisms for dealing with [[address space]]s, required for managing memory protection
* Some execution abstraction to manage CPU allocation, typically [[thread (computing)|threads]] or [[scheduler activations]]
* [[Inter-process communication]], required to invoke servers running in their own address spaces

This minimal design was pioneered by [[Brinch Hansen]]'s [[RC 4000 Multiprogramming System|Nucleus]] and the hypervisor of IBM's [[VM (operating system)|VM]]. It has since been formalised in Liedtke's ''minimality principle'':
<blockquote>A concept is tolerated inside the microkernel only if moving it outside the kernel, i.e., permitting competing implementations, would prevent the implementation of the system's required functionality.<ref name="Liedtke_95" /></blockquote>
Everything else can be done in a usermode program, although device drivers implemented as user programs may on some processor architectures require special privileges to access I/O hardware.

Related to the minimality principle, and equally important for microkernel design, is the [[separation of mechanism and policy]], it is what enables the construction of arbitrary systems on top of a minimal kernel. Any policy built into the kernel cannot be overwritten at user level and therefore limits the generality of the microkernel.<ref name="Liedtke_96"/> Policy implemented in user-level servers can be changed by replacing the servers (or letting the application choose between competing servers offering similar services).

For efficiency, most microkernels contain schedulers and manage timers, in violation of the minimality principle and the principle of policy-mechanism separation.

Start up ([[booting]]) of a microkernel-based system requires [[device driver]]s, which are not part of the kernel. Typically, this means that they are packaged with the kernel in the boot image, and the kernel supports a bootstrap protocol that defines how the drivers are located and started; this is the traditional bootstrap procedure of [[L4 microkernel family|L4 microkernels]]. Some microkernels simplify this by placing some key drivers inside the kernel (in violation of the minimality principle), [[LynxOS]] and the original [[Minix]] are examples. Some even include a [[file system]] in the kernel to simplify booting. A <!-- In other cases,  [[GNU GRUB]] for example, (This is NOT according to GRUB wiki) --> microkernel-based system may boot via multiboot compatible boot loader. Such systems usually load statically-linked servers to make an initial bootstrap or mount an OS image to continue bootstrapping.

A key component of a microkernel is a good [[Inter-process communication|IPC]] system and virtual-memory-manager design that allows implementing page-fault handling and swapping in usermode servers in a safe way. Since all services are performed by usermode programs, efficient means of communication between programs are essential, far more so than in monolithic kernels. The design of the IPC system makes or breaks a microkernel. To be effective, the IPC system must not only have low overhead, but also interact well with CPU scheduling.

==Performance==
On most mainstream processors, obtaining a service is inherently more expensive in a microkernel-based system than a monolithic system.<ref name="Liedtke_96"/> In the monolithic system, the service is obtained by a single system call, which requires two ''mode switches'' (changes of the processor's [[ring (computer security)|ring]] or [[CPU modes|CPU mode]]). In the microkernel-based system, the service is obtained by sending an IPC message to a server, and obtaining the result in another IPC message from the server. This requires a [[context switch]] if the drivers are implemented as processes, or a function call if they are implemented as procedures. In addition, passing actual data to the server and back may incur extra copying overhead, while in a monolithic system the kernel can directly access the data in the client's buffers.

Performance is therefore a potential issue in microkernel systems. The experience of first-generation microkernels such as [[Mach (kernel)|Mach]] and [[ChorusOS]] showed that systems based on them performed very poorly.<ref name="Chen_Bershad_93" /> However, [[Jochen Liedtke]] showed that Mach's performance problems were the result of poor design and implementation, specifically Mach's excessive [[CPU cache|cache]] footprint.<ref name="Liedtke_95"/> Liedtke demonstrated with his own [[L4 microkernel]] that through careful design and implementation, and especially by following the minimality principle, IPC costs could be reduced by more than an order of magnitude compared to Mach. L4's IPC performance is still unbeaten across a range of architectures.<ref name="Liedtke_ESHHIJ_97">{{cite conference
 | first1 = Jochen
 | last1 = Liedtke
 | author-link1 = Jochen Liedtke
 | last2 = Elphinstone | first2 = Kevin | last3 = Schönberg | first3 = Sebastian | last4 = Härtig | first4 = Hermann | author-link5 = Gernot Heiser | last5 = Heiser | first5 = Gernot | last6 = Islam | first6 = Nayeem | last7 = Jaeger | first7 = Trent
 | title = Achieved IPC performance (still the foundation for extensibility)
 | conference = 6th Workshop on Hot Topics in Operating Systems
 | pages = 28–31
 | publisher = IEEE
 | date = May 1997
 | location = Cape Cod, MA, USA
 | doi = 10.1109/HOTOS.1997.595177
| hdl = 1959.4/39929 | hdl-access = free }}</ref><ref name="Gray_CCMH_05">{{cite conference
 |first=Charles |last=Gray |author2=Chapman, Matthew |author3=Chubb, Peter |author4=Mosberger-Tang, David |author5-link=Gernot Heiser |author5=Heiser, Gernot |title=Itanium—a system implementor's tale |conference=USENIX Annual Technical Conference |pages=264–278 |date=April 2005|location=Annaheim, CA, USA |url=http://www.usenix.org/publications/library/proceedings/usenix05/tech/general/gray.html
}}</ref><ref name="vanSchaik_Heiser_07">{{cite conference
 | first1 = Carl
 | last1 = van Schaik
 | author-link2 = Gernot Heiser
 | last2 = Heiser
 | first2 = Gernot
 | title = High-performance microkernels and virtualisation on ARM and segmented architectures
 | conference = 1st International Workshop on Microkernels for Embedded Systems
 | pages = 11–21
 | publisher = NICTA
 | date = January 2007
 | location = Sydney, Australia
 | url = http://ertos.nicta.com.au/publications
 | access-date = 1 April 2007
 | archive-url = https://web.archive.org/web/20070426092901/http://www.ertos.nicta.com.au/publications/
 | archive-date = 26 April 2007
 | url-status = dead
 }}</ref>

While these results demonstrate that the poor performance of systems based on first-generation microkernels is not representative for second-generation kernels such as L4, this constitutes no proof that microkernel-based systems can be built with good performance. It has been shown that a monolithic Linux server ported to L4 exhibits only a few percent overhead over native Linux.<ref name="Hartig_97">{{cite conference | first1 = Hermann | last1 = Härtig |
last2 = Hohmuth | first2 = Michael | author-link3 = Jochen Liedtke | last3 = Liedtke | first3 = Jochen | last4 = Schönberg | first4 = Sebastian | book-title = Proceedings of the sixteenth ACM symposium on Operating systems principles - SOSP '97 | title = The performance of μ-kernel-based systems | date = October 1997 | volume = 31 | issue = 5 | url = http://portal.acm.org/citation.cfm?id=266660&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618 | pages=66–77|doi=10.1145/268998.266660 | isbn = 0-89791-916-5 | s2cid = 1706253 | url-access = subscription }}</ref> However, such a single-server system exhibits few, if any, of the advantages microkernels are supposed to provide by structuring operating system functionality into separate servers.

A number of commercial multi-server systems exist, in particular the [[Real-time operating system|real-time systems]] [[QNX]] and [[Integrity (operating system)|Integrity]]. No comprehensive comparison of performance relative to monolithic systems has been published for those multiserver systems. Furthermore, performance does not seem to be the overriding concern for those commercial systems, which instead emphasize reliably quick interrupt handling response times (QNX) and simplicity for the sake of robustness. An attempt to build a high-performance multiserver operating system was the IBM Sawmill Linux project.<ref name="Gefflaut_JPLEUTDR_00">
{{cite conference
 | first1 = Alain
 | last1 = Gefflaut
 | last2 = Jaeger | first2 = Trent | last3 = Park | first3 = Yoonho | author-link4 = Jochen Liedtke | last4 = Liedtke | first4 = Jochen | last5 = Elphinstone | first5 = Kevin J. | last6 = Uhlig | first6 = Volkmar | last7 = Tidswell | first7 = Jonathon E. | last8 = Deller | first8 = Luke | last9 = Reuther | first9 = Lars | display-authors=8
 | title = The Sawmill multiserver approach
 | conference = 9th ACM SIGOPS European Workshop
 | location = Kolding, Denmark
 | pages = 109–114
 | year = 2000
| citeseerx = 10.1.1.25.8376}}</ref> However, this project was never completed.

It has been shown in the meantime that user-level device drivers can come close to the performance of in-kernel drivers even for such high-throughput, high-interrupt devices as Gigabit Ethernet.<ref name="Leslie_CFGGMPSEH_05">{{cite journal |last1=Leslie |first1=Ben |last2=Chubb|first2= Peter|last3 = FitzRoy-Dale|first3= Nicholas|last4= Götz|first4 =Stefan|last5= Gray|first5= Charles|last6= Macpherson|first6= Luke|last7= Potts|first7= Daniel|last8= Shen|first8= Yueting|last9= Elphinstone|first9= Kevin| author-link10=Gernot Heiser|last10=Heiser|first10= Gernot | date=September 2005 |title=User-level device drivers: achieved performance |journal=Journal of Computer Science and Technology |volume=20 |issue=5 |pages=654–664 |doi=10.1007/s11390-005-0654-4|s2cid=1121537 |hdl= 1959.4/39966|hdl-access= free}}</ref> This seems to imply that high-performance multi-server systems are possible.

== Security ==
The security benefits of microkernels have been frequently discussed.<ref>{{cite web | author-link = Andrew S. Tanenbaum | last = Tanenbaum | first = Andrew S. | url = http://www.cs.vu.nl/~ast/reliable-os/ | title = Tanenbaum-Torvalds debate, part II }}</ref><ref>Tanenbaum, A., Herder, J. and Bos, H. (May 2006).</ref> In the context of security the minimality principle of microkernels is, some have argued, a direct consequence of the [[principle of least privilege]], according to which all code should have only the privileges needed to provide required functionality. Minimality requires that a system's [[trusted computing base]] (TCB) should be kept minimal. As the kernel (the code that executes in the privileged mode of the hardware) has unvetted access to any data and can thus violate its integrity or confidentiality, the kernel is always part of the TCB. Minimizing it is natural in a security-driven design.

Consequently, microkernel designs have been used for systems designed for high-security applications, including [[KeyKOS]], [[Extremely Reliable Operating System|EROS]] and military systems. In fact [[common criteria]] (CC) at the highest assurance level ([[Evaluation Assurance Level]] (EAL) 7) has an explicit requirement that the target of evaluation be "simple", an acknowledgment of the practical impossibility of establishing true trustworthiness for a complex system. Again, the term "simple" is misleading and ill-defined. At least the Department of Defense Trusted Computer System Evaluation Criteria introduced somewhat more precise verbiage at the B3/A1 classes:

{{Blockquote|text="The TCB shall [implement] complete, conceptually simple protection mechanisms with precisely defined semantics. Significant system engineering shall be directed toward minimizing the complexity of the TCB, as well as excluding from the TCB those modules that are not protection-critical."|sign=|source=Department of Defense Trusted Computer System Evaluation Criteria}}

In 2018, a paper presented at the Asia-Pacific Systems Conference claimed that microkernels were demonstrably safer than monolithic kernels by investigating all published critical [[Common Vulnerabilities and Exposures|CVE]]s for the [[Linux]] kernel at the time. The study concluded that 40% of the issues could not occur at all in a formally verified microkernel, and only 4% of the issues would remain entirely unmitigated in such a system.<ref>{{cite conference |url=https://dl.acm.org/doi/abs/10.1145/3265723.3265733 |title=The Jury Is In: Monolithic OS Design Is Flawed: Microkernel-based Designs Improve Security |last1=Biggs |first1=Simon |last2=Lee |first2=Damon |last3=Heiser |first3=Gernot |date=2018 |publisher=Association for Computing Machinery |book-title=Proceedings of the 9th Asia-Pacific Workshop on Systems |pages=1–7 |location=Jeju Island, Republic of Korea|doi=10.1145/3265723.3265733 |url-access=subscription }}</ref>

==Third generation==
More recent work on microkernels has been focusing on formal specifications of the kernel API, and formal proofs of the API's security properties and implementation correctness. The first example of this is a mathematical proof of the confinement mechanisms in EROS, based on a simplified model of the EROS API.<ref>{{cite conference
 |first1      = Jonathan S.
 |last1       = Shapiro
 |last2       = Weber
 |first2      = Samuel
 |title       = Verifying the EROS Confinement Mechanism
 |conference  = IEEE Conference on Security and Privacy
 |url         = http://www.eros-os.org/papers/oakland2000.ps
 |url-status     = dead
 |archive-url  = https://web.archive.org/web/20160303174121/http://www.eros-os.org/papers/oakland2000.ps
 |archive-date = 3 March 2016
}}</ref> More recently (in 2007) a comprehensive set of machine-checked proofs was performed of the properties of the protection model of [[L4 microkernel family#High assurance: seL4|seL4]], a version of L4.<ref>{{Cite book
  | first1 = Dhammika
  | last1 = Elkaduwe
  | first2 = Gerwin
  | last2 = Klein
  | first3 = Kevin
  | last3 = Elphinstone
  | title = Verified Protection Model of the seL4 Microkernel
  | year = 2007
  | publisher = submitted for publication
  | url = http://ertos.org/publications/papers/Elkaduwe_GE_07.abstract
  | access-date = 10 October 2007
  | archive-date = 29 November 2011
  | archive-url = https://web.archive.org/web/20111129122037/http://ertos.org/publications/papers/Elkaduwe_GE_07.abstract
  | url-status = usurped
  }}</ref>

This has led to what is referred to as ''third-generation microkernels'',<ref Name="Klein_EHACDEEKNSTW_09">
{{cite conference
 | first1 = Gerwin
 | last1 = Klein
 | last2 = Elphinstone | first2 = Kevin | last3 = Heiser | first3 = Gernot | last4 = Andronick | first4 = June | last5 = Cock | first5 = David | last6 = Derrin | first6 = Philip | last7 = Elkaduwe | first7 = Dhammika | last8 = Engelhardt | first8 = Kai | last9 = Kolanski | first9 = Rafal | last10 = Norrish | first10 = Michael | last11 = Sewell | first11 = Thomas | last12 = Tuch | first12 = Harvey | last13 = Winwood | first13 = Simon
 | title = seL4: Formal verification of an OS kernel
 | conference = 22nd ACM Symposium on Operating System Principles
 | date = October 2009
 | location = Big Sky, MT, USA
 | url = http://www.sigops.org/sosp/sosp09/papers/klein-sosp09.pdf
}}</ref> characterised by a security-oriented API with resource access controlled by [[capability-based security|capabilities]], [[virtual machines#System virtual machines|virtualization]] as a first-class concern, novel approaches to kernel resource management,<ref Name="Elkaduwe_DE_08">{{cite conference
 | first1 = Dhammika
 | last1 = Elkaduwe
 | last2 = Derrin
 | first2 = Philip
 | last3 = Elphinstone
 | first3 = Kevin
 | title = Kernel design for isolation and assurance of physical memory
 | conference = 1st Workshop on Isolation and Integration in Embedded Systems
 | date = April 2008
 | location = Glasgow, UK
 | doi = 10.1145/1435458
 | url = http://ertos.nicta.com.au/publications/papers/Elkaduwe_DE_08.abstract
 | access-date = 17 August 2009
 | archive-url = https://web.archive.org/web/20100424035229/http://www.ertos.nicta.com.au/publications/papers/Elkaduwe_DE_08.abstract
 | archive-date = 24 April 2010
 | url-status = dead
 | url-access = subscription
 }}</ref> and a design goal of suitability for [[formal methods|formal analysis]], besides the usual goal of high performance. Examples are [[Coyotos]], [[L4 microkernel family#High assurance: seL4|seL4]], Nova,<ref name="TUD">{{cite web |url=http://www.inf.tu-dresden.de/index.php?node_id=2697 |date=12 August 2010 |title=TUD Home: Operating Systems: Research: Microkernel & Hypervisor |work=Faculty of Computer Science |publisher=Technische Universität Dresden |access-date=5 November 2011 |archive-url=https://web.archive.org/web/20120406021703/http://www.inf.tu-dresden.de/index.php?node_id=2697 |archive-date=6 April 2012 |url-status=dead}}</ref><ref Name="Steinberg_Kauer_EuroSys_2010">
{{cite conference
 | first1 = Udo
 | last1 = Steinberg
 | first2 = Bernhard
 | last2 = Kauer
 | title = NOVA: A Microhypervisor-Based Secure Virtualization Architecture
 | conference = Eurosys 2010
 | date = April 2010
 | location = Paris, France
 | pages=209–222
 | doi = 10.1145/1755913.1755935
 }}</ref> [[Redox (operating system)|Redox]] and Fiasco.OC.<ref name="TUD"/><ref name=Lackor_Warg_IIES_09>{{cite conference
 | first1 = Adam
 | last1 = Lackorzynski
 | first2 = Alexander
 | last2 = Warg
 | title = Taming Subsystems – Capabilities as Universal Resource Access Control in L4
 | conference = IIES'09: Second Workshop on Isolation and Integration in Embedded Systems
 | date = March 2009
 | location = [[Nuremberg]], Germany
 | url = http://portal.acm.org/citation.cfm?id=1519135&dl=ACM
 | citeseerx = 10.1.1.629.9845
 }}</ref>

In the case of seL4, complete formal verification of the implementation has been achieved,<ref Name="Klein_EHACDEEKNSTW_09"/> i.e. a mathematical proof that the kernel's implementation is consistent with its formal specification. This provides a guarantee that the properties proved about the API actually hold for the real kernel, a degree of assurance which goes beyond even CC EAL7. It was followed by proofs of security-enforcement properties of the API, and a proof demonstrating that the executable binary code is a correct translation of the C implementation, taking the compiler out of the TCB. Taken together, these proofs establish an end-to-end proof of security properties of the kernel.<ref name="Klein_AEMSKH_14">{{cite journal
 | last1 = Klein
 | first1 = Gerwin
 | last2 = Andronick
 | first2 = June
 | last3 = Elphinstone
 | first3= Kevin 
 | last4 = Murray
 | first4 = Toby 
 | last5 = Sewell
 | first5 = Thomas 
 | last6 = Kolanski
 | first6 = Rafal 
 | last7 = Heiser
 | first7 = Gernot
 | date = February 2014
 | title = Comprehensive Formal Verification of an OS Microkernel
 | journal = ACM Transactions on Computer Systems
 | volume = 32
 | issue = 1
 | pages = 2:1–2:70
 | doi = 10.1145/2560537
 | s2cid = 4474342
 }}</ref>

== Examples ==
Some examples of microkernels are:

* [[AmigaOS]]
* [[Amoeba (operating system)|Amoeba OS]]
* BlackBerry [[QNX]]
* [[Genode]]
* [[HarmonyOS]] ([[HarmonyOS NEXT]])
* [[HelenOS]]
* [[Nintendo Switch system software#Technology|Horizon]] ([[Nintendo Switch system software]])
* The [[L4 microkernel family]]
* [[Mach (kernel)|Mach]]
* [[Mac OS 7]] to [[Mac OS 9]] ([[Mac OS nanokernel]])
* [[Minix]] (abandoned)
* [[Midori (operating system)|Midori]] (discontinued)
* [[Phantom OS]]
* [[Qubes OS]]
* [[Redox (operating system)|Redox]]
* [[Symbian]] (discontinued)
* [[SymbOS]] 
* [[ThreadX]]
* [[Fuchsia (operating system)#Kernel|Zircon]]

== Nanokernel ==
The term ''nanokernel'' or ''picokernel'' historically referred to:
* A kernel where the total amount of kernel code, i.e. code executing in the privileged mode of the hardware, is very small. The term ''picokernel'' was sometimes used to further emphasize small size. The term ''nanokernel'' was coined by Jonathan S. Shapiro in the paper [https://web.archive.org/web/20110621235229/http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html ''The KeyKOS NanoKernel Architecture'']. It was a sardonic response to [[Mach (kernel)|Mach]], which claimed to be a microkernel while Shapiro considered it monolithic, essentially unstructured, and slower than the systems it sought to replace. Subsequent reuse of and response to the term, including the picokernel coinage, suggest that the point was largely missed. Both ''nanokernel'' and ''picokernel'' have subsequently come to have the same meaning expressed by the term microkernel.
* A virtualization layer underneath an operating system, which is more correctly referred to as a [[hypervisor]].
* A [[hardware abstraction layer]] that forms the lowest-level part of a kernel, sometimes used to provide [[Real-time computing|real-time]] functionality to normal operating systems, like [[Adaptive Domain Environment for Operating Systems|Adeos]].

There is also at least one case where the term nanokernel is used to refer not to a small kernel, but one that supports a [[nanosecond]] clock resolution.<ref name="udel">{{cite web|url=http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.pdf|date=28 November 2000|title=The Nanokernel|author=David L. Mills and Poul-Henning Kamp |access-date=28 August 2017}}</ref>

==See also==
*[[Kernel (operating system)]]
**[[Exokernel]]
**[[Hybrid kernel]]
**[[Loadable kernel module]]
**[[Monolithic kernel]]
*[[Microservices]]
*[[Tanenbaum–Torvalds debate]]
*[[Trusted computing base]]
*[[Unikernel]]
*[[Multi-Environment Real-Time]]

== References ==
{{Reflist}}

==Further reading==
* [http://citeseerx.ist.psu.edu/search?q=microkernel Scientific articles about microkernels] (on [[CiteSeerX]]), including:
** {{cite conference | author=   Dan Hildebrand|title=An Architectural Overview of QNX|book-title=Proceedings of the Workshop on Micro-kernels and Other Kernel Architectures  | year=1992 |   pages=113–126 | isbn=   1-880446-42-1 |citeseerx=10.1.1.459.4481}} – the basic QNX reference.
** {{cite journal | title=Can We Make Operating Systems Reliable and Secure? | author=Tanenbaum, A., Herder, J. and Bos, H. | journal=Computer | date=May 2006 | url=http://www.computer.org/portal/site/computer/menuitem.eb7d70008ce52e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1&path=computer/homepage/0506&file=cover1.xml&xsl=article.xsl | pages=44–51 | doi=10.1109/MC.2006.156 | volume=39 | issue=5 | s2cid=99779 | access-date=3 April 2020 | archive-url=https://web.archive.org/web/20170621194406/https://www.computer.org/portal/site/computer/menuitem.eb7d70008ce52e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1&path=computer%2Fhomepage%2F0506&file=cover1.xml&xsl=article.xsl | archive-date=21 June 2017 | url-status=dead | url-access=subscription }} -the basic reliable reference.
** {{cite journal |title=Microkernel Operating System Architecture and Mach | author=Black, D.L., Golub, D.B., Julin, D.P., Rashid, R.F., Draves, R.P., Dean, R.W., Forin, A., Barrera, J., Tokuda, H., Malan, G., and Bohman, D. |journal=Journal of Information Processing|volume=14 |date=March 1992 | issue=4}} – the basic Mach reference.
* *{{cite journal | journal=Byte | date=January 1994 | title=Small Kernels Hit It Big | first=Peter D. | last=Varhol | url=http://www.byte.com:80/art/9401/sec8/art2.htm | url-status=dead | archive-url=https://web.archive.org/web/20060307075538/http://www.byte.com/art/9401/sec8/art2.htm | archive-date=7 March 2006 | access-date=20 September 2017}} An assessment of the present and future state of microkernel based OSes as of January 1994
* [http://c2.com/cgi/wiki?MicroKernel MicroKernel page] from the [[Portland Pattern Repository]]
* The [[Tanenbaum–Torvalds debate]]
** [http://www.oreilly.com/catalog/opensources/book/appa.html The Tanenbaum-Torvalds Debate, 1992.01.29]
** Tanenbaum, A. S. "[http://www.computer.org/csdl/mags/co/2006/05/r5044-abs.html Can We Make Operating Systems Reliable and Secure?]".
** Torvalds, L. [http://www.realworldtech.com/forums/index.cfm?action=detail&id=66630&threadid=66595&roomid=11 Linus Torvalds about the microkernels again, 2006.05.09]
** Shapiro, J. "[https://web.archive.org/web/20160922022726/http://www.coyotos.org/docs/misc/linus-rebuttal.html Debunking Linus's Latest]".
** Tanenbaum, A. S. "[http://www.cs.vu.nl/~ast/reliable-os/ Tanenbaum-Torvalds Debate: Part II]".

{{Microkernel}}
{{Operating system}}

{{Authority control}}

[[Category:Microkernels]]

[[fr:Noyau de système d'exploitation#Systèmes à micro-noyaux]]
[[it:Kernel#Microkernel]]
[[fi:Käyttöjärjestelmän ydin#Mikroydin]]