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^[1] , serta memiliki banyak kesamaan dengan hypervisor.^[2] 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 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 peladen atas device driver, 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.

Peladen

Peladen mikrokernel pada dasarnya merupakan program jurik biasa seperti umumnya, dengan pengecualian kernel memberikan sejumlah kewenangan untuk berinteraksi dengan sebagian dari ingatan fisik yang biasanya dibatasi untuk program pada umumnya. Dengan cara demikian, hal ini memungkinkan para peladen, khususnya device driver, bisa berinteraksi secara langsung dengan perangkat keras.

Seperangkat peladen pada mikrokernel untuk kebutuhan umum melingkupi peladen sistem berkas, peladen device driver, peladen jaringan, pelanden tampilan, dan peladen antar muka pengguna. Seperangkat peladen tersebut secara kasar adalah menyediakan sejumlah layanan yang sama yang diberikan pada kernel monolithic UNIX. Peladen yang dibutuhkan akan dijalankan pada saat sistem mulai berjalan dan secara aktif menyediakan layanan, seperti berkas, jaringan, dan akses terhadap perangkat, pada program-program aplikasi. Dengan sejumlah peladen yang berjalan pada lingkungan aplikasi pengguna seperti ini, pengembangan sebuah peladen sama seperti halnya halnya pengembangan aplikasi umum biasa.

Device Driver

Device driver secara frekuentif melakukan akses pengingat langsung (DMA), dengan demikian device driver bisa melakukan pennulisan dan relokasi atas ingatan fisik, termasuk pula struktur data kernel, oleh karena itu terhadap driver tersebut perlu diberikan kewenangan khusus (trusted). Kekeliruan konsepsi yang terjadi menganggap bahwa untuk device driver seperti itu haruslah merupakan bagian dari kernel. Padahal faktanya, driver tidak selalu menjadi bagian yang tidak terpisahkan dari kernel.

Komponen-komponen mendasar dan minimalitas

Karena sebuah mikrokernal harus dapat meletakkan layanan-layanan sistem operasi pada level teratas, fungsionalitas yang harus dimiliki oleh mikrokernel setidaknya melingkupi:

Mekanisme pengaturan pengalamatan ruang, — dibutuhkan untuk mengatur proteksi ingatan.
Mekanisme eksekusi secara abstrak untuk mengatur alokasi CPU — biasanya adalah thread atau pengaktifan penjadual; dan
Komunikasi antarproses — dibutuhkan untuk menyediakan mekanisme pemanggilan peladen yang berjalan pada alamat ruang spesifik.

Hal terpenting yang harus dimiliki oleh sebuah mikrokernel adalah keberadaan mekanisme Komunikasi antarproses yang handal, dan disain pengatur ingatan virtual yang memungkinkan manajemen ingatan dan melakukan pertukaran alamat (swapping) secara dengan aman. Selanjutnya, karena pada akhirnya semua layanan sistem operasi dipanggil oleh program yang berjalan pada modus user membuat tingkat efisiensi mekanisme komunikasi antar program yang terdapat pada sebuah mikrokernel menjadi sangat penting.

Unjuk kerja

Pada sistem berbasis mikrokernel, permintaan atas suatu layanan melalaui IPC sebenarnya membutuhkan sumber daya yang lebih besar dibandingkan pada sistem dengan kernel berbasis monolithic yang hanya menggunakan pemanggilan tunggal secara internal sistem. Dengan demikian unjuk kerja sistem berbasis mikrokernel mungkin menimbulkan potensi masalah, sebagai contoh, unjuk kerja mikrokernel generasi pertama, Mach dan Chorus, menunjukkan hasil yang mengecewakan.^[3] Namun, Jochen Liedtke menunjukkan bahwa masalah unjuk kerja Mach lebih terkait pada kesalahan disain dan implementasi. Melalui demonstrasi yang ditunjukkannya pada mikrokernel L4, ia berhasil menujukkan bahwa dengan menggunakan disain dan implementasi yang dirancang dengan baik serta konsisten dalam menerapkan prinsip-prinsip minimalitas, permasalahan yang terkait dengan IPC bisa diminimalisir.^[4]^[5]^[6]

Keamanan

Manfaat tingkat keamanan yang lebih baik atas pengimplementasian mikrokernel seringkali didiskusikan.^[7]^[8]

The security benefits of microkernels have been frequently discussed.^[9]^[10] 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.^[11] 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.^[12]

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:

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.
A virtualization layer underneath an operating system; this 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 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]

References

^ Liedtke, Jochen (1996). "Towards Real Microkernels". Communications of the ACM. 39 (9): 70–77.
^ Heiser, Gernot; Uhlig, Volkmar and LeVasseur, Joshua (2006). "Are Virtual-Machine Monitors Microkernels Done Right?" (PDF). ACM SIGOPS Operating Systems Review. ACM. 40 (1): 95–99. doi:10.1145/1113361.1113363.
^ Chen, Bradley (1993). "The Impact of Operating System Structure on Memory System Performance". 14th ACM Symposium on Operating System Principles. Asheville, NC, USA. hlm. 120–33.
^ Liedtke, Jochen (1997). "Achieved IPC performance (still the foundation for extensibility)". 6th Workshop on Hot Topics in Operating Systems. Cape Cod, MA, USA: IEEE. hlm. 28–31.
^ Gray, Charles (April 2005). "Itanium—a system implementor's tale". USENIX Annual Technical Conference. Annaheim, CA, USA. hlm. 264–278.
^ van Schaik, Carl (January 2007). "High-performance microkernels and virtualisation on ARM and segmented architectures". 1st International Workshop on Microkernels for Embedded Systems. Sydney, Australia: NICTA. hlm. 11–21. Diakses tanggal 2007-04-01.
^ Tanenbaum, Andrew S., Tanenbaum-Torvalds debate, part II
^ Tanenbaum, A., Herder, J. and Bos, H. (May 2006).
^ Tanenbaum, Andrew S., Tanenbaum-Torvalds debate, part II
^ Tanenbaum, A., Herder, J. and Bos, H. (May 2006).
^ Shapiro, Jonathan S. "Verifying the EROS Confinement Mechanism". IEEE Conference on Security and Privacy.
^ Elkaduwe, Dhammika; Klein, Gerwin; Elphinstone, Kevin (2007), Verified Protection Model of the seL4 Microkernel, submitted for publication