Structural variantsMonolithic, Mikrokernel and Exokernel

5.12.2005

OS kernel: a definition

• Quick and dirty definition:

• mandatory part of the OS

• common to all applications

• Responsible for

• security

• managability

• enables a uniform execution environment

OS-kernel: a definition

• An operating system kernel provides

• virtualization of hardware resources

• isolation of individual tasks and applications

• common platform-independent abstractions

• secure access to hardware devices

• access control and policy enforcement

Virtualization

• Present logical resources not physical entities

• manage isolated access by multiple users

• lock physical entities at the kernel level

• expose “virtual” resources based on the capabilities of the physical devices

• hide the fact that physical resources are scarce and may only be controlled by a single owner

• multiplex access to hardware resources

• enforce access conditions and permissions

Virtualization: CPU

• Virtualization of CPU resources

• Execution is continuous

• starting of the current program counter

• controlled by the program’s instructions

• restricted to the current address space

• However

• different applications will execute in different spaces

• a context switch requires heightened privileges

• potential security problem!

Virtualization: CPU

• Provide multiple “virtual” CPUs

• use time-division to provide individual timeslices

• periodically take a scheduling decision

• execute the context switch from a trusted environment to avoid privilege escalation

• OS kernel implementation

• provides exception (and IRQ) handlers

• runs in supervisor mode

Virtualization: CPU

• Implementation details

• a task list with

• memory context

• execution context: area for “register spillage”

• an exception handler for a periodic (timer) interrupt

• a scheduling algorithm

• Every process seems a dedicated “virtual” CPU

Virtualization: I/O

• Ethernet

• Background

• Dedicated, serial transmission medium

• Transmits frames from memory buffers to the transmission medium

• Problem

• Central instance needed

• to classify incoming packets

• to distribute packets to individual applications

Abstraction

• Abstraction

• Definition

• reduce and manage complexity

• factor out details to focus on few concepts

• Example: block-devices in UNIX

• Provision of a common interface

• Hides the details of various devices and media

e.g.: Flash media vs. a hard-disk

OS kernel variants

• Three major strategies to implement an operating system kernel

• Monolithic kernels

• Microkernel systems

• Pure microkernel designs

• Hybrid microkernel designs

• Exokernel approach

• All have different advantages an drawbacks

• There is no single “silver bullet”

Monolithic kernels

• The OS kernel is a single (monolithic) structure

• executing entirely in supervisor mode

• process management

• memory management

• drivers for hardware

• provides a set of system calls to interface with operating system services

• may use modules to optimize resource utilization

Monolithic kernels

• Typical examples

• Traditional UNIX kernels (System V and BSD flavours)

• FreeBSD

• Solaris

• Linux (see www.kernel.org for source code)

Monolithic kernels

• Advantages

• Efficiently using function calls between kernel modules

• Requires a low number of context switches

• Drawbacks

• Limitations in robustness

• No fault or privilege isolation

• History

• In widespread use before MMUs became common

Monolithic kernels

• Summary

• easy to design and develop

• hard to evolve without risking growing pains

Microkernel designs

• Design goals

• use a very simple abstraction over hardware

• thread management

• address spaces

• interprocess communication

• reduce the functionality in supervisor mode

• move specific drivers to user-space

• isolate individual network services in a separate context

Microkernel designs

• Examples

• AIX

• AmigaOS

• Amoeba

• Chorus

• Mach

• Minix (remember Tannenbaum vs. Torvalds?)

• QNX

• Symbian OS

Microkernel designs

• Overall architecture

• OS consists of a kernel and “servers”

• “Servers” provide high-level functionality

• external pager

• device drivers

• communication is performed using IPC/RPC

• potential performance problem

• context switches are expensive

Using an external pager

• A page-fault is handled by an external pager

• The RPC to the pager appears to originate from the faulting process

COMMUNICATIONS OF THE ACM September 1996/Vol. 39, No. 9 71

late 1980s, the software technology advantagesseemed obvious:

• Different application program interfaces (APIs),different file systems, and perhaps even differentbasic operating system strategies can coexist in onesystem. They are implemented as competing orcooperating servers.

• The system becomes more flexible and extensible.It can be more easily and effectively adapted tonew hardware or new applications. Only selectedservers need to be modified or added to the sys-tem. In particular, the impact of such modifica-tions can be restricted to a subset of the system, soall other processes are not affected. Furthermore,modifications do not require build-ing a new kernel; they can be madeand tested online.

• All servers can use the mechanismsprovided by the microkernel, such asmultithreading and IPC.

• Server malfunction is as isolated asnormal application malfunction.

• These advantages also hold fordevice drivers.

• A clean microkernel interfaceenforces a more modular system struc-ture.

• A smaller kernel can be more easilymaintained and should be less proneto error.

• Interdependencies between the vari-ous parts of the system can be restrict-ed and reduced. In particular, the trustedcomputing base (TCB) comprises only the hard-ware, the microkernel, a disk driver, and perhaps abasic file system.1 Other drivers and file and networksystems need no longer be absolutely trustworthy.

Although these advantages seemed obvious, the first-generation microkernels could not substantiate them.

The First GenerationThe microkernel idea met with efforts in the researchcommunity to build post-Unix operating systems.New hardware (e.g., multiprocessors, massively paral-lel systems), new application requirements (e.g.,security, multimedia, and real-time distributed com-puting) and new programming methodologies (e.g.,object orientation, multithreading, persistence)required novel operating-system concepts.

The corresponding objects and mechanisms—threads, address spaces, remote procedure calls(RPCs), message-based IPC, and group communica-tion—were lower-level, more basic, and more general

abstractions than the typical Unix primitives. In addi-tion to the new mechanisms, providing an API com-patible with Unix or another conventional operatingsystem was a sine qua non; hence implementing Unixon top of the new systems was a natural consequence.Therefore, the microkernel idea became widelyaccepted by operating-system designers for two com-pletely different reasons: (1) general flexibility andpower and (2) the fact that microkernels offered atechnique for preserving Unix compatibility whilepermitting development of novel operating systems.

Many academic projects took this path, includingAmoeba [19], Choices [4], Ra [1], and V [7]; someeven moved to commercial use, particularly Chorus[11], L3 [15], and Mach [10], which became the flag-

ship of industrial microkernels. Mach’s external pager [22] was the first conceptu-

al breakthrough toward real microkernels. The con-ceptual foundation of the external pager is that thekernel manages physical and virtual memory but for-wards page faults to specific user-level tasks. Thesepagers implement mapping from virtual memory tobacking store by writing back and loading pageimages. After a page fault, they usually return theappropriate page image to the kernel, which thenestablishes the virtual-to-physical memory mapping(see Figure 1). See the sidebar “Frequently AskedQuestions on External Pagers.”

This technique permits the mapping of files anddatabases into user address spaces without having tointegrate the file/database systems into the kernel.Furthermore, different systems can be used simulta-neously. Application-specific memory sharing anddistributed shared memory can also be implementedby user-level servers outside the kernel.

The second conceptual step toward microkernelswas the idea of handling hardware interrupts as IPC

1The TCB is the set of all components whose correct functionality is a precondition for security. Hardware and kernel both belong to the TCB.

Application Pager

Microkernel

RPCresumepagefault

Figure 1. Page fault processing

Fast IPC

• Issues in IPC

• context switch overheads

• additional processing for policy enforcement

• The L4 approach

• Reduce additional processing

• Policy enforcement is not part of the kernel

• Visibility provides security at the kernel level

• Reduce context switch overheads

• No intermediate switch to kernel mode

Benefit of microkernels

• Essential to trusted computing concepts

• Provides a small, controlled operating system core

• Controls the hardware and resources

• Holds initial ownership of all resources

• Delegates individual resources to trusted processes

• Isolates privileges and resources

• Can provide service level guarantees

L4: a microkernel

• Small number of mechanisms

• Address spaces

• Creating address spaces

• Mapping pages into address spaces

• Revoking mappings

• Scheduling

• Yielding the current time-slice to a specific thread

• Interprocess communication

• Performing message transfer to specific threads

L4: a microkernel

• Small number of mechanisms (continued)

• IPC protocols for specific functions

• external pager (pagefault handling)

• interrupt notification

• preemption notification

• exception notification

L4: Security

• Selective address space manipulation (system partitioning) provides as a framework for security

• Memory permissions reflect process permissions

completely to user-level servers. To illustrate, wesketch some low-level services that can be implement-ed by address-space servers based on the mechanisms.A server managing the initial address space is a classicmain memory manager, though outside the micro-

kernel. Memory managers can easilybe stacked; the initial memory servermaps or grants parts of the physicalmemory to memory server 1 andmemory server 2. Now we have twocoexisting main-memory managers.

A pager may be integrated with amemory manager or use a memory-managing server. Pagers use themicrokernel’s grant, map, anddemap primitives. The remaininginterfaces, pager-client, pager-memo-ry server, and pager-device driver, arecompletely based on IPC and aredefined outside the kernel. Pagerscan be used to implement traditionalpaged virtual memory and file/data-base mapping, as well as unpaged res-ident memory for device drivers andreal-time or multimedia systems.

User-supplied paging strategies [5, 14] are handled atthe user level and are in no way restricted by themicrokernel. Stacked address spaces, like those inGrasshopper [18], and stacked file systems [13] canbe realized in the same fashion.

Multimedia and other real-time applicationsrequire allocation of memory resources in a way thatallows predictable execution times. For example,user-level memory managers and pagers permit fixedallocation of physical memory for specific data or forlocking data in memory for a given time. Multimediaand timesharing resource allocators can coexist if theservers cooperate.

Such memory-based devices as bitmap displays arerealized by a memory manager holding the screenmemory in its address space.

Improving the hit rates of a secondary cache bymeans of page allocation or reallocation [12, 21] canbe implemented through a pager that applies cache-dependent policies for allocating virtual pages inphysical memory.

Remote IPC is implemented by communicationservers translating local messages to external commu-nication protocols and vice versa. The communica-tion hardware is accessed by device drivers. If specialsharing of communication buffers and user addressspaces is required, the communication server alsoacts as a special pager for the client. In contrast to thefirst generation, there is no packet filter inside themicrokernel.

Unix system calls are implemented by IPC. TheUnix server can act as a pager for its clients and canshare memory for communication with its clients.The Unix server itself is pageable or resident.

ConclusionAlthough academic experiments in porting applica-tions and operating system personalities to second-generation microkernels look promising, we havecovered only the known problems of microkernels.There is no real-life practical experience with second-

76 September 1996/Vol. 39, No. 9 COMMUNICATIONS OF THE ACM

Application

Application

Application

Application Pager 2

Pager 1

Mem server 1 Mem server 2

Initial space (physical memory)

Driver

Driver

Figure 6. A maps page by IPC to B

Is a kernel without main-memory management still amicrokernel or is it a submicrokernel? It is a kernelbecause it is mandatory to all other levels. Thereis no alternative kernel, although alternative mem-ory servers may coexist. It is a microkernelbecause it is a direct result of applying the micro-kernel paradigm of making the kernel minimal. Theinsight that microkernels have to be much smallerthan in the first generation does not justify a new“submicro” term. The underlying paradigm is thesame.

Since the kernel is not usable without a memory serv-er, why not include it in the microkernel? Two rea-sons:

• Operating systems can offer coexisting alterna-tive memory servers. Examples are timesharing(paging), real-time, multimedia, and file cachingtechniques. • Memory servers may be as machine (not proces-sor) dependent as device drivers.

Specialized servers are required for controllingsecond-level caches and device-specific memories.If a machine has fast and slow (uncached) main-memory regions, a corresponding memory servermight ensure that only fast memory is used forpaging and slow memory is reserved for diskcaching.

Frequently Asked Questions on Memory Servers

COMMUNICATIONS OF THE ACM September 1996/Vol. 39, No. 9 75

address spaces (described inthe next section), threads,and IPC—implements onlyseven system calls, and needsonly 12 Kbytes of code.Across-address-space IPC ona 486-DX50 takes 5 µs for an8-byte argument and 18 µsfor 512 bytes. The corre-sponding Mach numbers are115 µs (8 bytes) and 172 µs(512 bytes). With 2 x 5 µs,the basic L4-RPC is twice asfast as a conventional Unixsystem call. It remains unknown whether L4’sabstractions, despite being substantially more flexi-ble than the abstractions of the first generation, areflexible and powerful enough for all types of oper-ating systems.

Both approaches seem to overcome the perfor-mance problem. Exokernel’s and L4’s communica-tion is up to 20 times faster than that offirst-generation IPC.

Some nonmicrokernel systems try to reduce com-munication costs by avoiding IPC. As with Chorus andMach, Solaris and Linux support kernel-loadablemodules. The Spin system [2] extends the Synthesis[20] idea and uses a kernel-integrated compiler togenerate safe code inside the kernel space. Commu-nicating with servers of this kind requires feweraddress-space switches. The reduced IPC costs of sec-ond-generation microkernels might make this tech-nique obsolete or even disqualify it, since kernelcompilers impose overhead on the kernel. However,the question of which is superior—kernel-compilertechnology or a pure microkernel approach—is openas long as there is no sound implementation integrat-ing a kernel-compiler with a second-level microkernel.

More FlexibilityPerformance-related constraints seem to be disap-pearing. The problem of first-generation microker-nels was the limitation of the external-pager concepthardwiring a policy inside the kernel. This limitationwas largely removed by L4’s address-space concept,which provides a pure mechanism interface. Insteadof offering a policy, the kernel’s role is confined tooffering the basic mechanisms required to imple-ment the appropriate policies. These basic mecha-nisms permit implementation of various protectionschemes and even of physical memory managementon top of the microkernel.

The idea is to support the recursive construction ofaddress spaces outside the kernel (see Figure 5). Aninitial address space represents the physical memoryand is controlled by the first address-space server. Atsystem start time, all other address spaces are empty.For construction and maintenance of further address

spaces on top of the initial space, the microkernel pro-vides three operations: grant, map, and demap.

The owner3 of an address space can grant any of itspages to another space, provided the recipientagrees. The granted page is removed from thegranter’s address space and is included in thegrantee’s address space. The important restriction isthat instead of physical page frames, the granter cangrant only those pages already accessible to itself. Theowner of an address space can also map any of itspages into another address space, if the recipientagrees. Afterward, the page can be accessed in bothaddress spaces. In contrast to granting, in mapping,the page is not removed from the mapper’s addressspace. As in the granting case, the mapper can mappages to which it already has access.

The owner of an address space can demap any of itspages. The demapped page remains accessible in thedemapper’s address space but is removed from allother address spaces that received the page directlyor indirectly from the demapper. Although explicitconsent of the address-space owners is not required,the operation is safe, since it is restricted to ownedpages. The users of these pages already agreed toaccept a potential demapping when they received thepages by mapping or granting. See the sidebar “Fre-quently Asked Questions on Memory Servers.”

Since mapping a page requires consent betweenmapper and mappee, as does granting, it is imple-mented by IPC. In Figure 6, the mapper A sends amap message to the mappee B specifying by anappropriate receive operation that it is willing toaccept a mapping and determines the virtual addressof the page inside its own address space.

The address-space concept leaves memory man-agement and paging outside the microkernel; onlythe grant, map, and demap operations are retainedinside the kernel. Mapping and demapping arerequired to implement memory managers and pagerson top of the microkernel. Granting is used only inspecial situations to avoid double bookkeeping andaddress-space overflow. For a more detailed descrip-tion, see [16].

In contrast to the external-pager concept, the ker-nel confines itself to mechanisms. Policies are left

B

A

map IPC

send (‘map,’ virt. addr. in A)

receive (‘map,’ virt. addr. in B)

Figure 5. Recursively constructed address spaces

3“Owner” means the thread or threads that execute inside the address space.

Microkernel designs

• Summary

• Hard to design the component interfaces

• Provides long-term security and reliability benefits

Hybrid kernels

• The other approach to optimizing IPC

• Optimize performance, reduce latency

• Don’t focus on IPC

• Moves non-essential functionality into the kernel

• typically the pager

• frequently other OS services

• Examples

• MacOS X: XNU

• Windows NT and later

Exokernels

• A special case of microkernels

• Reduction of mechanisms in supervisor space

• Moves all abstractions to user-space

• Limited to virtualization

• Exposes the hardware to user-space programs

• Currently available as research prototypes only

Exokernel design

• Kernel mechanisms

• similar to those of L4 in many respects

• control of processor access

• control of address spaces

• different in controlling all functionality from the kernel

• primitives for different devices and device classes

e.g., block devices, network devices, ...

• not designed for user-space device drivers

Recommended Reading

• Engler D.R., Kaashock M.F., O’Toole J. Jr

Exokernel: An Operating System Architecture for Application-Level Resource Management

• Engler D.R., Kaashock M.F.

Exterminate all Operating System Abstractions

• Engler D.R., Kaashock M.F., O’Toole J. Jr

The Operating System as a Secure Programmable Machine

Recommended Reading

• Bershad B. N.

The Increasing Irrelevance of IPC Performance for Microkernel-Based Operating Systems

• Rashid R., et al.

Mach: A System Software Kernel

Recommended Reading

• Liedtke J.

On μ-Kernel Construction

• Liedtke J.

Improving IPC by Kernel Design

• Härtig H., Hohmuth M., Liedtke J., et al.

The Performance of μ-Kernel-based systems

Recommended Reading

• Härtig H., Hohmuth M., Wolter J.

Taming Linux

• LeVasseur J., Uhlig V., Stoess J., Götz S.

Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines