Das Microkernel-Konzept ist ein Ansatz für Betriebssystemkerne, welches nach seiner Befreiung aus einer akademischen Nische immer mehr praktische Verwendung findet. Die Grundlage von Microkerneln geht dabei bis in die 70er Jahre zurück. Sie basiert auf der Idee eines minimalen Betriebssystemkerns.
Ein Betriebssystemkern verwaltet verschiedene Ressourcen eines Computers und stellt den Anwendungen eine Schnittstelle zu diesen Ressourcen bereit. Diese Ressourcen sind primär Rechenzeit und Speicher, aber auch der Zugriff auf verschiedene Arten von Peripheriegeräten. Zum Management der Hardware kommen noch einige Dienstleistungen hinzu, wie das Starten und Betreiben von Anwendungsprogrammen sowie optional beispielsweise das Bereitstellen von Entropie oder die Verwaltung der unteren Schichten des Netzwerk-Stacks.
Klassischerweise werden alle diese Funktionen in einem sogenannten monolithischen Kernel integriert. Da für den Zugriff auf viele dieser Ressourcen sehr hohe Berechtigungen benötigt werden, werden monolithische Kernel durchgängig mit den höchsten Berechtigungen im Kernel-Mode ausgeführt. Anwendungsprogramme laufen hingegen im User-Mode mit weniger Berechtigungen. Durch diese Einschränkungen ist es Anwendungen im User-Mode nicht möglich, etwa selbstständig auf Hardware zuzugreifen oder andere Anwendungen zu beeinflussen.
Ein Grundsatz aus der IT-Sicherheit besagt, dass ein Prozess mit so viel Rechten wie nötig und so wenig wie möglich ausgestattet werden soll, auch bekannt als POLA (Principle Of Least Authority). Dieses gilt nicht nur für die Berechtigungen von Benutzern und Prozessen, sondern auch für Betriebssystemkerne. Ableitend aus dieser Anforderung stellt sich die Frage: Wie viel Funktionalität braucht ein Kernel, der im Kernel-Mode läuft und wie viele Aufgaben können an andere Anwendungen mit weniger Berechtigungen delegiert werden?
Eine Antwort auf diese Fragestellung wurde versucht mit der Entwicklung von Microkerneln zu finden. Die dabei zunächst entstandenen Microkernel waren vom Funktions- und Quelltextumfang her sehr klein, hatten aber große Performance-Probleme.
Diese Probleme werden durch die im Vergleich zu monolithischen Kernel zusätzlichen Kontextwechsel verursacht. Als Kontextwechsel wird der Vorgang des Umschaltens von einem Prozess - Kernel-Prozess jeweils eingeschlossen - zu einem anderen bezeichnet. Insbesondere bei Multiprozessorsystemen sind diese Umschaltvorgänge besonders zeitaufwändig. Wenn nun eine Anwendung zum Beispiel auf einen Gerätetreiber in einem monolithischen Kernel zugreift, gibt es nur zwei Kontextwechsel - vom User- in den Kernel-Mode und wieder zurück. Bei einem Microkernel läuft solch ein Gerätetreiber aber als separater User-Prozess, mit dem eine Anwendung nur über im Kernel vorhandenen Möglichkeiten zur Interprozesskommunikation zugreifen kann. Somit sind in diesem Fall mindestens vier Kontextwechsel notwendig.
Auf der anderen Seite haben sich aber auch Konzepte herausgebildet, die klassische User-Mode-Aufgaben in den Kernel integrieren, um an Performance zu gewinnen. Als Beispiele sind hierfür das Windows-Kernel-Modul http.sys sowie die Linux-Kernel-Module TUX und kHTTPd zu nennen. Bei diesen Kernel-Modulen handelt es sich um Webserver, die auf eine sehr hohe Performance ausgelegt sind, um möglichst schnell statische Webseiten auszuliefern. Allerdings ist hierbei zu beachten, dass ein Fehler innerhalb dieser Module potentiell immer von einem externen Angreifer ausgenutzt werden kann. Gelingt dieses, hat der Angreifer je nach Schwere des Fehlers uneingeschränkten Zugriff auf das gesamte System, da übliche Schutzmechanismen wie etwa Chroots, Container, Jails, Privilege-Separation oder Speicherschutz im Kernel-Mode nicht zur Anwendung kommen.
Im Bereich der Microkernel gibt es mehre Implementierungen. Eine der bekanntesten und heute noch verwendeten ist das MINIX (Mini Unix) Betriebssystem bzw. dessen Kernel von Andrew S. Tanenbaum. MINIX war in erster Linie ein praktisches Beispiel eines Unix-Betriebssystems, an dem Tanenbaum sein Standardwerk "Operating Systems: Design and Implementation" demonstrativ erläutern konnte. Ursprünglich nur für Lehrzwecke konzipiert, wird MINIX seit der dritten Revision zunehmend auch für den produktiven Einsatz weiterentwickelt. Ein Hauptmerkmal von MINIX3 ist dessen Fehlertoleranz. Das Konzept der Fehlertoleranz sieht vor, dass beim Auftreten eines Fehlers in einem System-Dienst, dieser nicht einfach abstürzen, sondern ohne Interaktion durch den Benutzer neugestartet wird und weiter läuft. Ebenso sollen Fehler in Teilsystemen nicht die Stabilität des Gesamtsystems gefährden.
Jochen Liedtke gelang es mit der Entwicklung des L4-Konzepts eine - im Vergleich zu den bis dahin bekannten Microkerneln - sehr performante Variante eines Microkernels zu realisieren. Abgeleitet von diesem Konzept gab es mehrere weitere Implementierungen.
Die Firma SYSGO AG entwickelt PikeOS. Diese L4-Implementierung legt ihren Fokus auf eingebettete Plattformen, Echtzeitfähigkeit und die Partitionierung von Ressourcen. PikeOS übernahm dabei eine Vorreiterrolle bei den auf Multiprozessorplattformen einsatzfähigen Echtzeitsystemen. Durch diese Eigenschaften eignet sich PikeOS für den Einsatz in Bereichen, in denen Safety eine große Rolle spielt, wie beispielsweise in der Avionik.
An der Technischen Universität Dresden wurde die L4-Variante L4/Fiasco geschaffen. Bei der Weiterentwicklung von L4/Fiasco zu L4/Fiasco.OC (Object Capabilities), kam der neuer Aspekt der Separation hinzu. Auf L4/Fiasco.OC können hierdurch zum Beispiel Prozesse nur dann untereinander kommunizieren, wenn jede Kommunikationsbeziehung kernel-seitig zuvor definiert worden ist. Ohne eine solche Festlegung kann kein Prozess mit einem anderen interagieren. Kernel mit dieser Eigenschaft werden allgemein auch als Separation-Kernel bezeichnet. L4/Fiasco.OC konzentriert sich in erster Linie auf die AMD/Intel- sowie die ARM-Architekturen, welche die Märkte von diversen Konsumergeräten bis hin zu Server-Hardware dominieren.
Ein weiterer nennenswerter L4-Vertreter ist seL4 (secure-embedded L4), dessen Implementierung bisher als einzige formal verifiziert worden ist. Darüber hinaus handelt es sich hierbei bisher um das einzige Protected-Mode-Betriebssystem, für das eine stichhaltige und für Echtzeitsysteme essentielle Worst Case Execution Time (WCET)-Analyse vorliegt. Dieser Nachweise wurden am Forschungsinstitut NICTA (National ICT Australia) in Zusammenarbeit mit der University of New South Wales geführt. Neben L4/Fiasco.OC ist seL4 ein weiterer L4-Abkömmling, welcher unter einer Open-Source-Lizenz offen zur Verfügung steht. Ebenso wie PikeOS und L4/Fiasco.OC zählt auch seL4 zur Klasse der Separation-Kernel, da auch diese Implementierung unter anderem die Kommunikation ihrer User-Mode-Prozesse mit Hardware und Nachbarprozessen über Capabilities reguliert.
Durch die Selbstvirtualisierungsfähigkeit, welche in den letzten Jahren auch in die AMD/Intel- sowie die ARM-Architektur Einzug hält, ist es möglich verbreitete Endkundensysteme, wie etwa GNU/Linux oder Microsoft Windows, auf einem Microkernel-Betriebssystem mit Hypervisor-Funktion unmodifiziert als Gastsystem zu betreiben. Damit lassen sich mehrere dieser Gäste parallel und sicher voneinander getrennt auf einer Hardware betreiben. Mit einem Separation-Kernel hat man dabei nicht nur die Möglichkeit, die Kommunikationsbeziehungen zwischen verschiedenen Gastsystemen genau zu kontrollieren, sondern auch die Kommunikation zwischen einem solchen System und der Hardware.
Bei einem Notebook, welches unterwegs und damit in nicht geschützten Umgebungen betrieben wird, kann ein Separation-Kernel jegliche Kommunikation zu Peripheriegeräten wie etwa Firewire- und USB-Geräten oder auch Netzwerk- und Mobilfunkschnittstellen unterbinden. Somit lassen sich vertrauliche und sensible Daten ausschließlich über definierte Schnittstellen wie den Bildschirm und die Tastatur betrachten und bearbeiten. Ein Datendiebstahl oder eine Manipulation der Software über die externen Kommunikationsschnittstellen ist damit ausgeschlossen.
Auch die Kontrolle der Interprozesskommunikation ermöglicht Anwendungsfelder, die durch den Einsatz von Separation-Kernel sicherer werden. Durch die strikte Kontrolle der Kommunikationsbeziehungen lassen sich Gastsysteme mit sensiblen Daten parallel zu nicht vertrauenswürdigen Umgebungen auf derselben Hardware betreiben. Der Separation-Kernel kann dabei die Kommunikation zwischen zwei Gästen strikt unterbinden, sie gestatten oder sie durch einen dritten Prozess beliebig filtern lassen. Anstatt jeweils einen Computer für geschäftliche und einen weiteren für private Zwecke getrennt voneinander zu verwenden, können somit beide Tätigkeiten auf einem physischen Gerät in zwei voneinander getrennten Arbeitsumgebungen durchgeführt werden.
Mit einem Microkernel welcher über Echtzeit- sowie Hypervisor-Fähigkeiten verfügt, eröffnen sich im Automotive- und Avionik-Bereich ebenfalls neue Anwendungsgebiete. Damit lassen sich Safety-kritische Anwendungen wie etwa für die Fahrzeugsteuerung und -regelung parallel zu Navigations- und Unterhaltungsanwendungen auf einer physischen Hardware sicher betreiben. Dies ermöglicht die Einsparung von Elektronikkomponenten, was seinerseits zur Senkung der Herstellungs- und durch Gewichtsreduktion der Betriebskosten führt.
Die zuvor erwähnten Anwendungsmöglichkeiten beschränken sich natürlich nicht ausschließlich auf den Einsatz von Microkernel. Auch mit monolithischen Implementierungen lassen sich diese Anforderungen umsetzen. Allerdings ist die sogenannte Trusted-Computing-Base (TCB) bei einem monolithischen Kernel weitaus größer. Die TCB ist in all den oben benannten Szenarien genau der Umfang an Programmcode, welcher für die Umsetzung der versprochenen Safety- und Security-Anforderungen verantwortlich ist. Bei einem Microkernel ist der Umfang der TCB im Vergleich zu einem monolithischen Kernel dabei um bis zu drei Größenordnungen kleiner.
Zur Zeit wird im Forschungsprojekt SIBASE ein Sicherheitsbaukasten erarbeitet, bei dem unter anderem Microkernel eine wesentliche Rolle spielen. SIABSE ist ein vom Bundesministerium für Bildung und Forschung gefördertes Forschungsprojekt (Förderkennzeichen: 01IS13020). Ziel dieses Vorhabens ist es, ein Baukastensystem aus Sicherheitskomponenten zu entwickeln, aus dem dann für die verschiedensten Anwendungsfelder wie Automotive, Avionik, Industriesteuerungen und Energieversorgung neue Sicherheitslösungen erstellt werden können. Das Baukastensystem umfasst dabei die verschiedensten Bestandteile wie etwa Hardware-Security-Modules (HSMs), Microkernel, Secure-Elements und Physical-Unclonable-Functions (PUFs). Die Firmen Genua GmbH und SYSGO AG verbessern dabei im Rahmen von SIBASE die L4-Implementierungen L4/Fiasco.OC und PikeOS.