Mikrokernel

Structure of monolithic and microkernel-based operating systems, respectively

Dalam pengetahuan Ilmu Komputer, mikrokernel merupakan modul inti yang meyediakan beragam mekanisme yang dibutuhkan untuk mengembangkan sebuah sistem operasi, seperti halnya manajemen pengalamatan ruang tingkat rendah, manajemen thread, dan komunikasi antar proses. Dalam implementasinya mikrokernel merupakan satu-satunya perangkat lunak yang berjalan dengan tingkat kewenangan tertinggi (umumnya disebut sebagai modus supervisor atau modus kernel) dari serangkaian level kewenangan yang tersedia pada perangkat kerasnya. Layanan yang disediakan oleh sebuah sistem operasi beberapa diantaranya adalah device driver, protocol stack, Sistem berkas, dan kode antarmuka pengguna yang berada dalam Ruang pengguna.

Mikrokernel sangat erat terkait dengan exokernel , serta memiliki banyak kesamaan dengan hypervisor. namun implementasinya lebih bersifat minimalis, dan secara spesifik untuk mendukung pengimplementasian Mesin virtual. L4 microkernel sering juga disebut sebagai hypervisor, yang mengindikasikan kemungkinan pengimplementasian sebuah mikrokernel sebagai hypervisor. Istilah nanokernel dalam sejarahnya digunakan untuk membedakan mikrokernel saat ini dengan istilah mikrokernel sebelumnya yang menyediakan layanan sistem aktual, namun secara prinsip minimalitas menurut Jochen Liedtke dalam desain L4 microkernel menyebutkan bahwa istilah-istilah tersebut memiliki arti yang kurang lebih sama; mikrokernel merupakan terminologi modern.

Pendahuluan

Pada mulanya, kernel sistem operasi umumnya berukuran kecil, penyebabnya adalah besarnya ingatan komputer yang terbatas. Dengan semakin berkembangnya kapabiltas komputer, jumlah perangkat yang harus dikontrol oleh suatu kernel menjadi meningkat pula. Namun pada masa-masa awal sejarah sistem operasi unix, kernel pada umumnya berukuran kecil, meskipun kernel-kernel tersebut menyediakan pengendali perangkat keras (Device driver) dan pengatur sistem berkas. Saat pengalamatan ruang meningkat dari 16 menjadi 32 bit, disain kernel diubahsuai menjadi tidak lagi bergantung pada arsitektur perangkat keras yang ada, dan ukuran kernel pun mulai tumbuh membesar.

Berkeley UNIX (BSD) tercatat sebagai yang memulai era kernel berukuran besar. Sebagai tambahan dari pengoperasian sistem yang paling mendasar seperti CPU, media penyimpanan, dan pencetak, BSD mulai menambahkan sistem berkas, sistem jaringan TCP/IP yang lengkap, dan sejumlah perangkat "virtual" yang mengijinkan program yang ada untuk bekerja secara tersembunyi pada jaringan. Pertumbuhan ini berlanjut selama beberapa dekade dan menyebabkan kernel yang ada saat ini terdiri hingga jutaan baris kode. Sebagai akibat dari pertumbuhan ini pun, kernel yang ada saat ini lebih rentan terhadap bug dan menjadi lebih sulit untuk dikelola.

Mikrokernel didisain untuk mengatasi permasalahan yang disebabkan karena pertumbuhan kernel yang membesar dan kesulitan mengelolanya. Secara teori, disain mikrokernel mengijinkan pengelolaan kode yang lebih mudah karena arsitekturnya yang mendistribusikan layanan pada divisi ruang pengguna. Pengimplementasian seperti ini berdampak positif pula pada peningkatan keamanan dan stabilitas yang disebabkan karena menurunnya jumlah kode yang berjalan pada modus kernel. Sebagai contoh, jika layanan jaringan tidak bekerja karena serangan buffer overflow, sistem lainnya masih dapat berfungsi secara normal.

Komunikasi Antarproses

Komunikasi antarproses (IPC) merupakan suatu mekanisme yang memungkinkan suatu proses yang terpisah untuk berkomunikasi dengan proses lainnya, biasanya hal ini dilakukan dengan memanfaatkan mekanisme pengiriman pesan. Disamping itu Ingatan berbagi (shared memory) secara spesifik juga sering pula digunakan sebagai salah satu mekanisme yang digunakan untuk komunikasi antarproses, namun demikian, umumnya makna IPC lebih mengarah pada komunikasi memanfaatkan mekanisme pengiriman pesan, dan lebih lanjut menjadi relevan terhadap mekanisme yang digunakan pada mikrokernel. IPC mengijinkan sistem operasi dibuat dari sejumlah program kecil yang disebut pelayan, yang digunakan oleh program lainnya dalam sistem, melalui IPC sebagai mediator. Hampir dari semua dukungan atas periferal perangkat keras ditangani memalui cara ini, dengan pelayan atas pengendali perangkat keras, protokol jaringan, sistem berkas, grafis, dan lain-lain.

IPC dapat pula berjalan secara sinkronis, dan asinkronis. Analogi IPC asinkronis pada komunikasi jaringan contohnya: Pesan dikirim oleh program pengirim dan melajutkan proses tanpa menunggu pesan baliknya. Program penerima menampung/mengecek keberadaan pesan yang harus diproses baik secara inisialisasi mandiri, atau diingatkan oleh suatu mekanisme notifikasi. IPC asinkronis mensyaratkan kernel mengelola penampung dan mengimplementasikan antrian atas pesan-pesan tersebut, dan berkompromi terhadap kemungkinan terjadinya "buffer-overflow"; Kernel juga harus melakukan duplikasi pesan (pengirim-ke-kernel dan kernel-ke-penerima). Sementara pada IPC sinkronis, pihak pertama (baik pengirim atau penerima) yang melakukan blokade hingga pihak yang dituju siap untuk melakukan proses IPC. modus IPC sinkronis tidak membutuhkan pengelolaan penampung di sisi kernel, ataupun duplikasi pesan, namun komunikasi yang bersifat sinkronis seperti ini akan menyebabkan pemrograman menjadi lebih sulit. Kebanyakan programer lebih memilih menggunakan modus asinkronis untuk pengiriman dan modus sinkronis untuk penerimaan.

Mikrokernel generasi pertama biasanya mendukung IPC baik secara sinkronis, maupun asinkronis, namun terkendala pada buruknya kinerja IPC yang dihasilkan. Jochen Liedtke mengidentifikasi bahwa disain dan implementasi mekanisme IPC yang digunakan menjadi penyebab yang paling bertanggung jawab atas buruknya kinerja tersebut. Dalam L4 mikrokernel-nya, ia menjadi pionir atas suatu teknik yang kemudian menjadi suatu urutan atas besaran penurunan biaya IPC. Termasuk pula didalamnya sebuah sistem pemanggilan IPC yang mendukung baik operasi pengiriman maupun penerimaan, menjadikan semua IPC bersifat sinkronis, dan melewatkan data sebanyak mungkin pada register. Lebih jauh lagi Liedtke memperkenalkan suatu konsep saklar proses langsung (direct process switch), yaitu saat eksekusi IPC sebuah context swicth (tidak lengkap) dilakukan dari pengirim langsung ke penerimanya. Jika, seperti pada L4, sebagian atau seluruh dari pesan dilewatkan pada register, penyampaian pada sisi register dilakukan tanpa melakukan duplikasi sama sekali. Lebih jauh lagi, beban tambahan atas pemanggilan penjadual bisa dihindari; Mekanisme seperti ini secara spesifik menguntungkan dalam kasus-kasus umum saat IPC digunakan seperti halnya RPC oleh klien yang melakukan pemanggilan terhadap peladen. Optimasi lainnya, disebut sebagai penjadualan malas (lazy scheduling) untuk menghindari penjadualan antrian pada saat proses IPC dengan cara membiarkan thread yang terblokir saat IPC berada dalam antrian yang telah siap. Sekali sebuah penjadual dipanggil, penjadual tersebut akan memindahkan thread-thread tersebut antrian tungg yang sesuai. Karena dalam banyak kasus sebuah thread menjadi tidak terblokir sebelum pemanggilan penjadual berikutnya, pendekatan seperti ini menghemat kerja secara signifikan. Pendekatan lain yang mirip juga diimplementasikan pada QNX dan MINIX 3.

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, modern microkernels generally follow L4's lead and only provide a synchronous IPC primitive. Asynchronous IPC can be implemented on top by using helper threads. However, versions of L4 deployed in commercial products have found it necessary to add an asynchronous notification mechanism to better support asynchronous communication. This signal-like mechanism does not carry data and therefore does not require buffering by the kernel.

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 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, as does QNX).

Servers

Microkernel servers are essentially 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 servers, and user interface device servers. This set of servers (drawn from QNX) provides roughly the set of services offered by a monolithic UNIX 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 for by simply stopping and restarting the server. 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 TCP/IP connections: If this server is restarted, applications will experience a "lost" connection, a normal occurrence in 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.

In order to make all servers restartable, some microkernels have concentrated on adding various database-like techniques like transactions, replication and checkpointing in order to preserve essential state across single server restarts. An example is ChorusOS, which was targeted at high-availability applications in the telecommunications world. Chorus included features to allow any "properly written" server to be restarted at any time, with clients using those servers being paused while the server brought itself back into its original state. However, such kernel features are incompatible with the minimality principle, and are therefore not provided in modern microkernels, which instead rely on appropriate user-level protocols.

Device drivers

Device drivers frequently perform direct memory access (DMA), and therefore can write to arbitrary locations of physical memory, including over 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 IOMMUs, many of which can be used to restrict a device's access to physical memory. (IBM mainframes have had IO MMUs since the IBM System/360 Model 67 and System/370.) 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, the first operating system to be designed with that capability. 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, Linux, and Windows. With the proliferation of various kinds of peripherals, the amount of driver code escalated and in modern operating systems dominates the kernel in terms of code size.

Essential components & minimality

As a microkernel must allow building arbitrary operating-system services on top, it must provide some core functionality. At the least this includes:

• some mechanisms for dealing with address spaces — this is required for managing memory protection;
• some execution abstraction to manage CPU allocation — typically threads or scheduler activations; and
• inter-process communication — required to invoke servers running in their own address spaces.

This minimal design was pioneered by Brinch Hansen's Nucleus and the hypervisor of IBM's VM. It has since been formalised in Liedtke's minimality principle:

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.

Everything else can be done in a user program, although device drivers implemented as user programs may 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. 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 drivers, 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. 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. On other cases microkernel-based system may boot via multiboot compatible boot loader, GNU GRUB for example, such systems usually loads statically linked servers to make an initial bootstrap or mount OS image to continue bootstrapping.

A key component of a microkernel is a good IPC system and virtual memory manager design that allows to implement page fault handling and swapping in user space servers side 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

Obtaining a service is inherently more expensive in a microkernel-based system than a monolithic system. In the monolithic system, the service is obtained by a single system call, which requires two mode switches (changes of the processor's privilege level). 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. Indeed, the experience of first-generation microkernels such as Mach and Chorus showed that systems based on them performed very poorly. However, Jochen Liedtke showed that Mach's performance problems were the result of poor design and implementation, and specifically Mach's excessive cache footprint. 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.

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. 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 systems QNX and 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 simplicity for the sake of robustness. An attempt to build a high-performance multiserver operating system was the IBM Sawmill Linux project. 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. This seems to imply that high-performance multi-server systems are possible.

Security

The security benefits of microkernels have been frequently discussed. In the context of security the minimality principle of microkernels is 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) 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, EROS and military systems. In fact common criteria (CC) at the highest assurance level (EAL7) 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.

Recent work on microkernels is focusing on formal specifications of the kernel API, and formal proofs of security properties of the API. The first example of this is a mathematical proof of the confinement mechanisms in EROS, based on a simplified model of the EROS API. More recently, a comprehensive set of machine-checked proofs has been performed of the properties of the protection model of the seL4 version of L4.

Some projects go even further, aiming at complete formal verification, i.e. a mathematical proof that the kernel's implementation is consistent with its specification, which then provides a guarantee that the properties proved about the API actually hold for the real kernel. This degree of assurance goes beyond even CC EAL7. Such proofs are being attempted for Coyotos and seL4.

Nanokernel

In computer science, the term nanokernel or picokernel historically referred to:

1. 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 The KeyKOS NanoKernel Architecture. It was a sardonic response to Mach, which claimed to be a microkernel while being 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.
2. A virtualization layer underneath an operating system; this is more correctly referred to as a hypervisor.
3. A hardware abstraction layer that forms the lowest-level part of a kernel, sometimes used to provide real-time functionality to normal OS's, like 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. [1]

See also

• Kernel (computer science)
  • Exokernel, a research kernel architecture with a more minimalist approach to kernel technology.
  • Hybrid kernel
  • Monolithic kernel
  • Loadable kernel module
• Trusted computing base

Further reading

• scientific articles about microkernels (on CiteSeer), including:
  • Dan Hildebrand (1992). "An Architectural Overview of QNX". Proceedings of the Workshop on Micro-kernels and Other Kernel Architectures: 113–126. ISBN 1-880446-42-1.  - the basic QNX reference.
  • Tanenbaum, A., Herder, J. and Bos, H. (2006). "Can We Make Operating Systems Reliable and Secure?". Computer: 44–51.  Pemeliharaan CS1: Banyak nama: authors list (link) -the basic reliable reference.
  • 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. (1992). "Microkernel Operating System Architecture and Mach". J. Of Information Processing. 14(4).  Pemeliharaan CS1: Banyak nama: authors list (link) - the basic Mach reference.
• MicroKernel page from the Portland Pattern Repository
• The Tanenbaum-Torvalds debate
  • The Tanenbaum-Torvalds Debate, 1992.01.29
  • Tanenbaum, A. S. "Can We Make Operating Systems Reliable and Secure?".
  • Torvalds, L. Linus Torvalds about the microkernels again, 2006.05.09
  • Shapiro, J. "Debunking Linus's Latest".
  • Tanenbaum, A. S. "Tanenbaum-Torvalds Debate: Part II".