Mikrokernel

Struktur von monolithischen und mikrokernelbasierten Betriebssystemen

Im Informatik, a Mikrokernel (oft abgekürzt wie μ-Kernel) ist die nahezu minimale Menge von Software das kann die Mechanismen liefern, die für die Implementierung eines benötigt werden Betriebssystem (OS). Diese Mechanismen umfassen niedrige Ebene Adressraum Management, Faden Management und Interprozesskommunikation (IPC).

Wenn die Hardware mehrere bietet Ringe oder CPU -ModiDas Mikrokernel ist möglicherweise die einzige Software, die auf der privilegierten Ebene ausführt, die im Allgemeinen als als bezeichnet wird Vorgesetzter oder Kernelmodus. Herkömmliche Betriebssystemfunktionen wie z. Gerätetreiber, Protokollstapel und Dateisysteme, werden typischerweise vom Mikrokernel selbst entfernt und stattdessen eingeführt Benutzerraum.[1]

In Bezug auf die Quellcodegröße sind Mikrokernel oft kleiner als Monolithische Kerne. Das Minix 3 Microkernel hat beispielsweise nur ungefähr 12.000 Codezeilen.[2]

Geschichte

Microkernels verfolgen ihre Wurzeln zurück zum dänischen Computerpionier Per Brinch Hansen und seine Amtszeit in der dänischen Computerfirma Regralen wo er Softwareentwicklungsbemühungen für den RC 4000 -Computer leitete.[3] 1967 installierte Regnecentralen einen RC 4000 -Prototyp in der Zakłady Azotowe Puławy Düngemittelanlage in Polen. Der Computer verwendete ein kleines Echtzeit-Betriebssystem, das auf die Bedürfnisse der Anlage zugeschnitten war. Brinch Hansen und sein Team besorgt über die mangelnde Allgemeinheit und Wiederverwendbarkeit des RC 4000 -Systems. Sie befürchteten, dass jede Installation ein anderes Betriebssystem erfordern würde, sodass sie neuartige und allgemeinere Möglichkeiten zur Erstellung von Software für den RC 4000 untersuchen würden.[4] 1969 führte ihre Bemühungen zur Fertigstellung der RC 4000 Multiprogrammierungssystem. Sein Kern lieferte eine interprozessfreie Kommunikation, die auf dem Börsengang für bis zu 23 nicht privilegierte Prozesse basierte, von denen 8 jeweils voreinander geschützt waren. Es wurde die Planung von Zeitscheiben von Programmen, die parallel, die Initiierung und Kontrolle der Programmausführung auf Anfrage anderer laufender Programme sowie die Initiierung von Datenübertragungen an oder von Peripheriegeräten durchgeführt wurden. Neben diesen Elementarmechanismen gab es keine integrierte Strategie für die Programmausführung und Ressourcenzuweisung. Diese Strategie sollte durch eine Hierarchie der laufenden Programme implementiert werden, in denen übergeordnete Prozesse die vollständige Kontrolle über Kinderprozesse hatten und als ihre Betriebssysteme fungierten.[5][6]

Nach den Arbeiten von Brinch Hansen werden seit den 1970er Jahren Mikrokernel entwickelt.[7] Der Begriff Microkernel selbst erschien erstmals später als 1981.[8] Microkernels waren als Reaktion auf Veränderungen in der Computerwelt und auf mehrere Herausforderungen, die vorhanden sind. "Mono-Kernel"Zu diesen neuen Systemen. Neue Geräte-Treiber, Protokollstapel, Dateisysteme und andere Systeme auf niedriger Ebene wurden ständig entwickelt. Dieser Code befand sich normalerweise im monolithischen Kernel und erforderte daher eine beträchtliche Arbeit und sorgfältige Codemanagement, um daran zu arbeiten . Microkernel wurden mit der Idee entwickelt, dass alle diese Dienste als Benutzer-Raum-Programme wie jedes andere implementiert werden würden, sodass sie monolithisch bearbeitet werden und wie jedes andere Programm gestoppt und gestoppt werden können. Dies würde nicht nur zulassen, dass diese Dienste sein. Leichter bearbeitet, trennte sich aber auch den Kernelcode, damit er fein abgestimmt ist, ohne sich über unbeabsichtigte Nebenwirkungen zu sorgen. Darüber hinaus würde es völlig neue Betriebssysteme ermöglichen, auf einem gemeinsamen Kern "aufgebaut" zu werden und die OS -Forschung zu unterstützen.

Mikrokernel waren in den 1980er Jahren ein sehr heißes Thema, als der erste Gebrauchsbetrieb lokale Netzwerke wurden eingeführt .. die Amigaos Geschäftsführer Kernel war ein frühes Beispiel, das 1986 eingeführt und in einem PC mit relativem kommerziellen Erfolg verwendet wurde. Der mangelnde Speicherschutz, der in anderer Hinsicht als Fehler berücksichtigt wurde, ermöglichte es diesem Kernel, eine sehr hohe Leistungsleistung zu erzielen, da er keine Daten kopieren musste, während er Nachrichten zwischen User-Space-Programmen austauschte.[9]

Die gleichen Mechanismen, die es dem Kernel ermöglichten, in den Benutzerbereich verteilt zu werden, ermöglichte es auch, dass das System über Netzwerkverbindungen verteilt wird. Die ersten Mikrokernel, insbesondere Mach erstellt von Richard Rashid, erwies sich als eine enttäuschende Leistung, aber die inhärenten Vorteile schienen so groß zu sein, dass es sich um eine große Forschungslinie der späten neunziger Jahre handelte. Während dieser Zeit wuchs die Computergeschwindigkeit jedoch in Bezug auf Netzwerksysteme stark, und die Leistungsnachteile überfordern die Vorteile in Entwicklungsbedingungen.

Es wurden viele Versuche unternommen, die vorhandenen Systeme an eine bessere Leistung anzupassen, aber der Overhead war immer beträchtlich und die meisten dieser Bemühungen mussten die Benutzer-Raum-Programme wieder in den Kernel versetzt werden. Bis 2000 am meisten groß angelegt Mach Die Kernel -Bemühungen waren beendet, obwohl Apple's Mac OS, veröffentlicht im Jahr 2001, verwendet immer noch a Hybridkern genannt Xnu, was einen stark modifizierten (Hybrid) kombiniert OSF/1's Mach Kernel (OSFMK 7.3 Kernel) mit Code von BSD Unix,[10][11] Und dieser Kernel wird auch in verwendet iOS, tvos, und Watchos. Windows NTBeginnend mit NT 3.1 und fortgesetzt mit Windows 10 verwendet ein Hybrid -Kernel -Design. Wie 2012, die Mach Gnu Hurd ist auch funktional und in Testversionen von enthalten Arch Linux und Debian.

Obwohl die wichtigsten Arbeiten an Mikrokernels weitgehend beendet waren, setzten die Experimentatoren die Entwicklung fort. Seitdem wurde gezeigt, dass viele der Leistungsprobleme früherer Entwürfe keine grundlegende Einschränkung des Konzepts waren, sondern aufgrund des Wunsches des Designers, einzelne Sichtsysteme zu verwenden, um so viele dieser Dienste wie möglich zu implementieren. Verwendung eines pragmatischeren Ansatzes für das Problem, einschließlich Montagecode und das Verlassen des Prozessors, Konzepte durchzusetzen, die normalerweise in Software unterstützt werden, führte zu einer neuen Reihe von Mikrokernel mit dramatisch verbesserter Leistung.

Mikrokernel sind eng mit dem verwandt mit Exokernel.[12] Sie haben auch viel gemeinsam mit Hypervisoren,[13] Letztere erheben jedoch keinen Anspruch auf Minimalität und sind auf die Unterstützung spezialisiert virtuelle Maschinen; das L4 Microkernel Findet häufig die Verwendung in einer Hypervisorkapazität.

Einführung

Frühe Betriebssystemkerne waren ziemlich klein, teilweise weil der Computerspeicher begrenzt war. Als die Fähigkeit von Computern zunahm, wuchs auch die Anzahl der Geräte, die der Kernel steuern musste. Während der frühen Geschichte von Unix, Kerne waren im Allgemeinen klein, obwohl sie verschiedene enthielten Gerätetreiber und Dateisystem Implementierungen. Als die Adressräume von 16 auf 32 Bit stiegen, wurde das Kerneldesign durch die Hardware -Architektur nicht mehr eingeschränkt, und die Kernel begannen, größer zu werden.

Das Berkeley Software Distribution (BSD) von Unix begann die Ära größerer Kerne. Neben dem Betrieb eines grundlegenden Systems, das aus CPU, Scheiben und Druckern besteht, fügte BSD eine vollständige hinzu TCP/IP -Netzwerksystem und eine Reihe von "virtuellen" Geräten, die es den vorhandenen Programmen ermöglichten, "unsichtbar" über das Netzwerk zu arbeiten. Dieses Wachstum dauerte viele Jahre und führte zu Kernel mit Millionen von Linien von Quellcode. Infolge dieses Wachstums waren Kerne anfällig für Käfer und wurden immer schwieriger zu bewahren.

Der Mikrokernel sollte dieses Wachstum von Kerneln und den entstandenen Schwierigkeiten berücksichtigen. Theoretisch ermöglicht das Microkernel -Design eine leichtere Verwaltung des Codes aufgrund seiner Aufteilung in Benutzerraum Dienstleistungen. Dies ermöglicht auch eine erhöhte Sicherheit und Stabilität, die sich aus der reduzierten Menge an Code ergibt Kernelmodus. Zum Beispiel, wenn ein Networking -Dienst abgestürzt ist PufferüberlaufNur der Speicher des Netzwerkdienstes würde beschädigt werden, so dass der Rest des Systems noch funktionsfähig bleibt.

Interprozesskommunikation

Interprozesskommunikation (IPC) ist jeder Mechanismus, mit dem getrennte Prozesse miteinander kommunizieren können, normalerweise durch Senden Mitteilungen. Geteilte Erinnerung ist, streng definiert, auch ein Kommunikationsmechanismus mit Interprozess, aber der Abkürzung-IPC bezieht sich normalerweise nur auf das Passieren von Nachrichten, und letzteres ist für Mikrokernel besonders relevant. Mit IPC kann das Betriebssystem aus einer Reihe kleinerer Programme erstellt werden, die als Server bezeichnet werden und von anderen Programmen auf dem System verwendet werden und über IPC aufgerufen werden. Die meisten oder alle Unterstützung für periphere Hardware wird auf diese Weise mit Servern für Gerätefahrer behandelt. Netzwerkprotokollstapel, Dateisysteme, Grafiken usw.

IPC kann synchron oder asynchron sein. Asynchrones IPC ist analog zur Netzwerkkommunikation: Der Absender sendet eine Nachricht und führt weiter aus. Der Empfänger prüft (Umfragen) für die Verfügbarkeit der Nachricht oder wird durch einen Benachrichtigungsmechanismus darauf aufmerksam gemacht. Asynchrone IPC verlangt, dass der Kernel Puffer und Warteschlangen für Nachrichten verwaltet und sich mit Pufferüberläufen befasst. Es erfordert auch ein Doppelkopieren von Nachrichten (Absender zu Kernel und Kernel zum Empfänger). In synchronem IPC blockiert die erste Partei (Absender oder Empfänger), bis die andere Partei bereit ist, den IPC auszuführen. Es erfordert keine Pufferung oder mehrere Kopien, aber das implizite Rendezvous kann das Programmieren schwierig machen. Die meisten Programmierer bevorzugen asynchrone Send und synchrones Empfang.

Mikrokernel der ersten Generation unterstützten typischerweise sowohl synchrone als auch asynchrone IPC und litten unter einer schlechten IPC-Leistung. Jochen liestke Angenommen, die Gestaltung und Implementierung der IPC -Mechanismen als der Grund für diese schlechte Leistung. In seinem L4 Microkernel Er war der Pionier der Methoden, die die IPC -Kosten um einen senkten Größenordnung.[14] Dazu gehören ein IPC -Systemanruf, der sowohl einen Send als auch einen Empfangsvorgang unterstützt, das alle IPC -Synchron synchron macht und so viele Daten wie möglich in Registern überholt. Darüber hinaus führte Lieedtke das Konzept der vor Direkter Prozessschalter, wo während einer IPC -Ausführung A (unvollständig) Kontextschalter wird vom Absender direkt an den Empfänger durchgeführt. Wenn wie in L4 ein Teil oder die gesamte Nachricht in Registern weitergegeben wird, überträgt dies den in registrierten Teil der Nachricht, ohne dass überhaupt kopiert wird. Darüber hinaus wird der Aufwand des Schedulers vermieden; Dies ist besonders vorteilhaft in dem gemeinsamen Fall, in dem IPC in einem verwendet wird Remote -Verfahrensanruf (RPC) Geben Sie die Mode durch einen Client ein, der einen Server aufruft. Eine weitere Optimierung, genannt faule ZeitplanungVermeiden Sie das Durchqueren der Planungswarteschlangen während IPC, indem Sie Threads, die während der IPC in der Ready -Warteschlange blockieren, blockieren. Sobald der Scheduler aufgerufen ist, verschiebt er solche Themen in die entsprechende Warteschlange. Wie in vielen Fällen wird ein Thread vor dem nächsten Scheduler -Aufruf entsperrt, dieser Ansatz spart erhebliche Arbeit. Ähnliche Ansätze wurden seitdem von verfolgt von Qnx und Minix 3.

In einer Reihe von Experimenten verglichen Chen und Bershad das Gedächtnis Zyklen pro Anweisung (MCPI) von monolithisch Ultrix mit denen von Mikrokernel Mach kombiniert mit a 4.3bsd Unix Server laufen ein Benutzerraum. Ihre Ergebnisse erklärten die schlechtere Leistung von Mach durch höhere MCPI und zeigten, dass IPC allein nicht für einen Großteil des Systemaufwands verantwortlich ist, was darauf hindeutet, dass sich die Optimierungen ausschließlich auf IPC konzentrieren werden.[15] Lieedtke verfeinerte später die Ergebnisse von Chen und Bershad, indem sie beobachtete, dass der Großteil des Unterschieds zwischen Ultrix und Mach MCPI durch Kapazität verursacht wurde Cache-Mitte und zu dem Schluss, dass die drastisch reduzierte Verringerung des Cache -Arbeitssatzes eines Mikrokernels das Problem lösen wird.[16]

In einem Client-Server-System ist die meiste Kommunikation im Wesentlichen synchron, selbst wenn sie asynchrone Primitive verwenden, da der typische Betrieb ein Client ist, der einen Server aufruft und dann auf eine Antwort wartet. Da es sich auch für eine effizientere Implementierung eignet, folgten die meisten Mikrokernel im Allgemeinen L4 von L4 und boten nur einen synchronen IPC -Primitiv. Asynchrones IPC könnte oben mit Helfer -Threads implementiert werden. Erfahrung hat jedoch gezeigt, dass der Nutzen von synchronem IPC zweifelhaft ist: Synchrones IPC erzwingt ein Multi-Thread-Design auf ansonsten einfache Systeme mit den resultierenden Synchronisationskomplexitäten. Darüber hinaus sequentiell ein RPC-ähnlicher Server-Invocation Client und Server, der vermieden werden sollte, wenn sie auf separaten Kernen ausgeführt werden. Versionen von L4, die in kommerziellen Produkten eingesetzt wurden, haben daher festgestellt, dass es notwendig ist, einen asynchronen Benachrichtigungsmechanismus hinzuzufügen, um die asynchrone Kommunikation besser zu unterstützen. Dies Signal-Bemähnlicher Mechanismus trägt keine Daten und erfordert daher keine Pufferung durch den Kernel. Durch zwei Formen von IPC haben sie dennoch gegen das Prinzip der Minimalität verstoßen. Andere Versionen von L4 haben vollständig auf asynchrones IPC gewechselt.[17]

Als synchrones IPC blockiert die erste Partei, bis der andere fertig ist, die uneingeschränkte Verwendung leicht zu Deadlocks führen. Darüber hinaus könnte ein Kunde leicht a montieren Denial of Service Angriff auf einen Server, indem Sie eine Anfrage senden und nie versuchen, die Antwort zu erhalten. Synchrones IPC muss daher ein Mittel bereitstellen, um eine unbestimmte Blockierung zu verhindern. Viele Mikrokernel bieten Zeitüberschreitungen Bei IPC -Aufrufen, die die Blockierungszeit einschränken. In der Praxis ist die Auswahl sinnvoller Zeitüberschreitungswerte schwierig, und Systeme verwenden unweigerlich unendliche Zeitüberschreitungen für Kunden und keine Zeitüberschreitungen für Server. Infolgedessen ist der Trend, keine willkürlichen Zeitüberschreitungen bereitzustellen, sondern nur ein Flag, das angibt, dass der IPC sofort fehlschlagen sollte, wenn der Partner nicht bereit ist. Dieser Ansatz bietet effektiv eine Auswahl der beiden Zeitüberschreitungswerte von Null und Unend. Jüngste Versionen von L4 und Minix haben diesen Weg eingegangen (ältere Versionen von L4 verwendeten Timeouts). QNX vermeidet das Problem, indem der Client den Antwortpuffer als Teil der Nachricht senden soll. Wenn der Server antwortet, kopiert der Kernel die Daten in den Puffer des Clients, ohne dass der Client die Antwort explizit erhält.[18]

Server

Mikrokernel -Server sind im Wesentlichen Dämon Programme wie alle anderen, außer dass der Kernel einige davon Privilegien gewährt, mit Teilen des physischen Gedächtnisses zu interagieren, die ansonsten für die meisten Programme ausgeschlossen sind. Dies ermöglicht es einigen Servern, insbesondere Gerätetreibern, direkt mit Hardware zu interagieren.

Ein grundlegender Satz von Servern für ein allgemeines Mikrokernel enthält Dateisystemserver, Geräte-Treiber-Server, Netzwerkserver, Server anzeigenund Benutzeroberfläche Geräteserver. Dieser Server (gezeichnet von Servern aus Qnx) bietet ungefähr die von einer Unix angebotenen Dienstleistungen, die von einer Unix angeboten werden monolithischer Kernel. Die erforderlichen Server werden beim System Startup gestartet und bieten Dienste wie Datei, Netzwerk und Gerätezugriff für normale Anwendungsprogramme an. Bei solchen Servern, die in der Umgebung einer Benutzeranwendung ausgeführt werden, ähnelt die Serverentwicklung eher der normalen Anwendungsentwicklung als dem für die Entwicklung von Kernel benötigten Build-and-Boot-Prozess.

Zusätzlich können viele "Abstürze" durch einfach korrigiert werden Stoppen und Neustarten des Servers. Ein Teil des Systemzustands geht jedoch mit dem fehlenden Server verloren. Daher müssen bei diesem Ansatz Anwendungen mit dem Fehler umgehen. Ein gutes Beispiel ist ein Server für verantwortlich für TCP/IP Verbindungen: Wenn dieser Server neu gestartet wird, wird eine "verlorene" Verbindung hergestellt, ein normales Auftreten in einem vernetzten System. Für andere Dienste ist der Fehler weniger erwartet und erfordert möglicherweise Änderungen des Anwendungscode. Für QNX wird die Neustart -Funktion als QNX -Hochverfügbarkeits -Toolkit angeboten.[19]

Gerätetreiber

Gerätetreiber häufig durchführen direkter Speicherzugriff (DMA) und können daher an willkürliche Stellen des physischen Gedächtnisses schreiben, einschließlich verschiedener Kernel -Datenstrukturen. Solche Fahrer müssen daher vertrauenswürdig sein. Es ist ein weit verbreitetes Missverständnis, dass dies bedeutet, dass sie Teil des Kernels sein müssen. Tatsächlich ist ein Fahrer nicht mehr oder weniger vertrauenswürdig, indem er Teil des Kernels ist.

Während ein Gerätetreiber im Benutzerraum ausführt, reduziert dies nicht unbedingt den Schaden, den ein schlecht benachbarter Treiber verursachen kann, in der Praxis vorteilhaft für die Systemstabilität in Gegenwart von fehlerhaften (eher böswilligen) Treibern: Verstöße gegen den Speicherzugriff durch den Fahrercode selbst ( im Gegensatz zum Gerät kann immer noch von der Speichermanagement-Hardware erfasst werden. Darüber hinaus sind viele Geräte nicht DMA-fähig, ihre Treiber können nicht vertrauen, indem sie im Benutzerbereich ausgeführt werden. In jüngster Zeit eine zunehmende Anzahl von Computerfunktionen IommusViele davon können verwendet werden, um den Zugriff eines Geräts auf den physischen Speicher einzuschränken.[20] Dadurch können Benutzer-Mode-Treiber auch nicht vertrauenswürdig werden.

Benutzer-Mode-Treiber sind tatsächlich vor Mikrokernel. Das Michigan Terminalsystem (MTS) unterstützte 1967 die Treiber der Benutzerraum (einschließlich des Dateisystems), dem ersten Betriebssystem, das mit dieser Funktion entworfen wurde.[21] In der Vergangenheit waren die Fahrer weniger ein Problem, da die Anzahl der Geräte sowieso klein und vertrauenswürdig war. Daher vereinfachte sie im Kernel das Design und vermieden potenzielle Leistungsprobleme. Dies führte zum traditionellen Treiber im Kernel-Stil von Unix,[22] Linux und Windows Nt. Mit der Verbreitung verschiedener Arten von Peripheriegeräten dominiert die Menge des Treibercode, und in modernen Betriebssystemen dominiert der Kernelgröße den Kernel.

Wesentliche Komponenten und Minimalität

Da ein Mikrokernel willkürliche Betriebssystemdienste oben aufgebaut werden muss, muss es einige Kernfunktionen liefern. Zumindest umfasst dies:

  • Einige Mechanismen für den Umgang mit Adressräume, erforderlich für die Verwaltung des Speicherschutzes
  • Eine Ausführungsabstraktion zur Verwaltung der CPU -Zuordnung typischerweise typischerweise Themen oder Scheduler -Aktivierungen
  • Interprozesskommunikation, erforderlich, um Server aufzurufen, die in ihren eigenen Adressräumen laufen

Dieses minimale Design wurde von Pionierarbeit von Pionierarbeit Brinch Hansen's Kern und der Hypervisor von IBMs VM. Es wurde inzwischen in Lieedtke's formalisiert Minimalitätsprinzip:

Ein Konzept wird im Mikrokernel nur dann toleriert, wenn es außerhalb des Kernels bewegt wird, d. H. Durch konkurrierende Implementierungen, die Implementierung der erforderlichen Funktionen des Systems verhindern würde.[16]

Alles andere kann in einem Usmode -Programm durchgeführt werden, obwohl Gerätefahrer, die als Benutzerprogramme implementiert sind, auf einigen Prozessorarchitekturen spezielle Berechtigungen erfordern, um auf E/A -Hardware zuzugreifen.

Im Zusammenhang mit dem Minimalitätsprinzip und gleichermaßen wichtig für das Mikrokernel -Design ist die Trennung von Mechanismus und PolitikEs ist das, was die Konstruktion willkürlicher Systeme auf einem minimalen Kernel ermöglicht. Jede in den Kernel eingebaute Richtlinien können auf Benutzerebene nicht überschrieben werden und begrenzt daher die Allgemeinheit des Mikrokernels.[12] Richtlinien, die in Servernebene implementiert sind, können geändert werden, indem die Server ersetzt werden (oder die Anwendung zwischen konkurrierenden Servern wählen, die ähnliche Dienste anbieten).

Für die Effizienz enthalten die meisten Mikrokernel Scheduler und Verwalten von Timern, die gegen das Minimalitätsprinzip und das Prinzip der Trennung von Politik-Mechanismus verstoßen.

Anlaufen (Booten) eines auf Mikrokernel basierenden Systems erfordert Gerätetreiber, die nicht Teil des Kernels sind. Normalerweise bedeutet dies, dass sie mit dem Kernel im Boot -Bild verpackt werden, und der Kernel unterstützt ein Bootstrap -Protokoll, das definiert, wie sich die Treiber befinden und begonnen haben. Dies ist das traditionelle Bootstrap -Verfahren von L4 Microkernel. Einige Mikrokernel vereinfachen dies, indem einige wichtige Treiber im Kernel platziert werden (unter Verstoß gegen das Minimalitätsprinzip). Luchs und das Original Minix sind Beispiele. Einige enthalten sogar a Dateisystem im Kernel, um das Booten zu vereinfachen. Ein mikrokernelbasiertes System kann über Multiboot-kompatible Bootloader booten. Solche Systeme laden normalerweise statisch verknüpfte Server, um eine anfängliche Bootstrap zu erstellen oder ein Betriebssystembild zu montieren, um das Bootstrapping fortzusetzen.

Eine Schlüsselkomponente eines Mikrokernels ist gut IPC System- und virtuelles Memory-Manager-Design, mit dem das Implementieren von Seitenfehlerbehandlungen und -Swappern in Usermode-Servern auf sichere Weise implementiert werden kann. Da alle Dienste von Usmode -Programmen erbracht werden, sind effiziente Kommunikationsmittel zwischen den Programmen wesentlich mehr als in monolithischen Kerneln. Das Design des IPC -Systems macht oder bricht einen Mikrokernel. Um effektiv zu sein, muss das IPC -System nicht nur einen niedrigen Overhead aufweisen, sondern auch gut mit der CPU -Planung interagieren.

Leistung

Bei den meisten Mainstream-Prozessoren ist das Erhalten eines Dienstes in einem auf Mikrokernel basierenden System von Natur aus teurer als ein monolithisches System.[12] Im monolithischen System wird der Dienst durch einen einzelnen Systemaufruf erhalten, der zwei erfordert Modusschalter (Änderungen des Prozessors Ring oder CPU -Modus). Im von Microkernel basierenden System wird der Dienst erhalten, indem eine IPC-Nachricht an einen Server gesendet und das Ergebnis in einer anderen IPC-Nachricht vom Server abgerufen wird. Dies erfordert a Kontextschalter Wenn die Treiber als Prozesse oder als Funktionsaufruf implementiert werden, wenn sie als Verfahren implementiert werden. Darüber hinaus kann das Übergeben der tatsächlichen Daten an den Server und die Rückseite zusätzlicher Kopieraufwand entstehen, während der Kernel in einem monolithischen System direkt auf die Daten in den Puffern des Clients zugreifen kann.

Die Leistung ist daher ein potenzielles Problem in Mikrokernel -Systemen. Die Erfahrung von Mikrokernel der ersten Generation wie z. Mach und Chorusos zeigten, dass Systeme basierend auf ihnen sehr schlecht abschnitten.[15] Jedoch, Jochen liestke zeigten, dass Machs Leistungsprobleme das Ergebnis einer schlechten Konstruktion und Implementierung waren, insbesondere von Machs übermäßig Zwischenspeicher Fußabdruck.[16] Liestke demonstriert mit seinem eigenen L4 Microkernel Dass durch sorgfältiges Design und Implementierung und insbesondere durch das Minimalitätsprinzip die IPC -Kosten im Vergleich zu Mach um mehr als eine Größenordnung reduziert werden könnten. Die IPC -Leistung von L4 ist in einer Reihe von Architekturen immer noch ungeschlagen.[23][24][25]

Diese Ergebnisse zeigen zwar, dass die schlechte Leistung von Systemen, die auf Mikrokernel der ersten Generation basieren, für Kernel der zweiten Generation wie L4 nicht repräsentativ ist, dies ist kein Beweis dafür, dass auf Mikrokernel basierende Systeme mit guter Leistung aufgebaut werden können. Es wurde gezeigt, dass ein monolithischer Linux -Server, der auf L4 portiert ist, nur wenige Prozent über native Linux aufweist.[26] Ein solches einzelnes Server-System zeigt jedoch nur wenige, wenn überhaupt, der Vorteile, die Mikrokernel durch Strukturieren von Betriebssystemfunktionen in separate Server liefern sollen.

Es gibt eine Reihe kommerzieller Multi-Server-Systeme, insbesondere die Echtzeitsysteme Qnx und Integrität. Für diese Multiserver -Systeme wurde kein umfassender Vergleich der Leistung im Vergleich zu monolithischen Systemen veröffentlicht. Darüber hinaus scheint die Leistung nicht das übergeordnete Anliegen für diese kommerziellen Systeme zu sein, die stattdessen zuverlässig schnelle Interrupt -Reaktionszeiten (QNX) und Einfachheit der Robustheit betonen. Ein Versuch, ein Hochleistungs-Multiserver-Betriebssystem zu erstellen, war das IBM Sawmill Linux-Projekt.[27] Dieses Projekt wurde jedoch nie abgeschlossen.

Es wurde in der Zwischenzeit gezeigt, dass Geräte-Treiber auf Benutzerebene der Leistung von In-Kernel-Treibern selbst für so hohe Durchsatz von hohen Störungen wie Gigabit-Ethernet nahe kommen können.[28] Dies scheint zu implizieren, dass Hochleistungs-Multi-Server-Systeme möglich sind.

Sicherheit

Die Sicherheitsvorteile von Mikrokernel wurden häufig diskutiert.[29][30] Im Kontext der Sicherheit ist das Minimalitätsprinzip von Microkernels eine direkte Folge der Prinzip der geringsten Privilegien, nach denen jeder Code nur über die Berechtigungen verfügen sollte, um die erforderlichen Funktionen bereitzustellen. Die Minimalität erfordert, dass die eines Systems eines Systems Vertrauenswürdige Computerbasis (TCB) sollte minimal gehalten werden. Als Kernel (der Code, der im privilegierten Modus der Hardware ausgeführt wird) hat der nicht abgetriebene Zugriff auf alle Daten und kann somit seine Integrität oder Vertraulichkeit verletzen, der Kernel ist immer Teil des TCB. Das Minimieren ist in einem sicherheitsorientierten Design natürlich.

Infolgedessen wurden Mikrokernel-Designs für Systeme verwendet, die für Anwendungen mit hoher Sicherheit ausgelegt sind, einschließlich Kekos, EROS und Militärsysteme. In der Tat Gemeinsame Kriterien (CC) auf höchstem Niveau (höchste Gewissheit (Bewertungssicherungsstufe (EAL) 7) hat eine ausdrückliche Anforderung, dass das Ziel der Bewertung "einfach" ist, eine Bestätigung der praktischen Unmöglichkeit, wahre Vertrauenswürdigkeit für ein komplexes System zu etablieren. Auch hier ist der Begriff "einfach" irreführend und schlecht definiert. Zumindest das Verteidigungsministerium vertrauensgebundene Computersystembewertungskriterien wurden in den B3/A1 -Klassen ein wenig präziser ausführlich eingeleitet:

"Die TCB muss vollständige, konzeptionell einfache Schutzmechanismen mit präzise definierter Semantik implementieren. Die signifikante Systemtechnik muss auf die Minimierung der Komplexität des TCB gerichtet sein und aus dem TCB-Ausschluss der TCB-Module, die nicht schützend sind, ausgeschlossen werden."

-Verteidigungsministerium vertrauenswürdiger Computersystembewertungskriterien

Im Jahr 2018 behauptete eine Arbeit, die auf der Konferenz der asiatisch-pazifischen Systeme vorgestellt wurde, dass Mikrokernel nachweislich sicherer sei Cves für die Linux Kernel zu dieser Zeit. Die Studie kam zu dem Schluss, dass 40% der Probleme in einem formell verifizierten Mikrokernel überhaupt nicht auftreten konnten, und nur 4% der Probleme würden in einem solchen System vollständig nicht uneingeschränkt.[31]

Dritte Generation

Neuere Arbeiten zu Microkernels konzentrierten sich auf formale Spezifikationen der Kernel -API und formelle Beweise für die Sicherheitseigenschaften und die Korrektheit der Implementierung der API. Das erste Beispiel hierfür ist ein mathematischer Beweis für die Begrenzungsmechanismen in Eros, basierend auf einem vereinfachten Modell der EROS -API.[32] In jüngerer Zeit (2007) wurde eine umfassende Reihe von maschinellen Prüfungen über die Eigenschaften des Schutzmodells von durchgeführt Sel4, eine Version von L4.[33]

Dies hat zu dem geführt, was als als bezeichnet wird Mikrokernel der dritten Generation,[34] gekennzeichnet durch eine sicherheitsorientierte API mit Ressourcenzugriff, der von gesteuert wurde Fähigkeiten, Virtualisierung Als erstklassiges Anliegen sind neuartige Ansätze zum Kernel Resource Management,[35] und ein Designziel der Eignung für Eignung für Formale AnalyseNeben dem üblichen Ziel der Hochleistung. Beispiele sind Coyotos, Sel4, Nova,[36][37] Redox und Fiasco.oc.[36][38]

Im Fall von SEL4 wurde eine vollständige formale Überprüfung der Umsetzung erreicht,[34] d.h. ein mathematischer Beweis dafür, dass die Implementierung des Kernels mit seiner formalen Spezifikation übereinstimmt. Dies bietet eine Garantie dafür, dass die Immobilien über die API für den realen Kernel nachgewiesen wurden, ein gewisses Maß an Zusicherung, die über CC EAL über hinausgeht. Es folgten Nachweis der Sicherheitsverfolgungseigenschaften der API, und ein Beweis, der zeigt, dass der ausführbare Binärcode eine korrekte Übersetzung der C-Implementierung ist und den Compiler aus dem TCB herausnimmt. Zusammengenommen stellen diese Beweise einen End-to-End-Beweis für Sicherheitseigenschaften des Kernels fest.[39]

Beispiele

Einige Beispiele für Mikrokernel sind:

Nanokernel

Der Begriff Nanokernel oder Picokernel historisch erwähnt auf:

  • Ein Kernel, in dem die Gesamtmenge des Kernelcode, d. H. Code im privilegierten Modus der Hardware ausführt, ist sehr klein. Der Begriff Picokernel wurde manchmal verwendet, um die geringe Größe weiter zu betonen. Der Begriff Nanokernel wurde von Jonathan S. Shapiro in der Zeitung geprägt Die Kekos Nanokernel Architektur. Es war eine sardonische Antwort auf Mach, was behauptete, ein Mikrokernel zu sein, während Shapiro es für monolithisch, im Wesentlichen unstrukturiert und langsamer als die Systeme ersetzen wollte. Die anschließende Wiederverwendung und Reaktion auf den Begriff, einschließlich der Picokernel -Münzprägung, deuten darauf hin, dass der Punkt weitgehend übersehen wurde. Beide Nanokernel und Picokernel haben anschließend die gleiche Bedeutung, die durch den Begriff Mikrokernel ausgedrückt wird.
  • Eine Virtualisierungsschicht unter einem Betriebssystem, das als korrekter als als bezeichnet wird Hypervisor.
  • A Hardware -Abstraktionsschicht Das bildet den niedrigsten Teil eines Kernels, der manchmal verwendet wird, um bereitzustellen Echtzeit Funktionalität zu normalen Betriebssystemen wie Adeos.

Es gibt auch mindestens einen Fall, in dem der Begriff Nanokernel verwendet wird, um nicht auf einen kleinen Kernel, sondern einen, der a unterstützt Nanosekunde Taktauflösung.[40]

Siehe auch

Verweise

  1. ^ Herder, Jorrit N. (23. Februar 2005). "Auf dem Weg zu einem echten Mikrokernel -Betriebssystem" (PDF). minix3.org. Abgerufen 22. Juni 2015.
  2. ^ "Weiterlesen". Abgerufen 20. Dezember 2016.
  3. ^ "2002 Computer Pioneer Awardsempfänger". IEEE Computer Society. Abgerufen 13. September 2016.
  4. ^ Brinch Hansen, Per (2004). Die Geschichte eines Programmierers: Das Leben eines Computerpioniers. Abgerufen 13. September 2016.
  5. ^ Brinch Hansen, per (April 1969). RC 4000 -Software: Multiprogrammiersystem (PDF) (Technischer Bericht). Regralen. Abgerufen 13. September 2016.
  6. ^ Brinch Hansen, Per (1970). "Der Kern eines multiprogrammierenden Betriebssystems" (PDF). Kommunikation der ACM. 13 (4): 238–250. Citeseerx 10.1.1.105.4204. doi:10.1145/362258.362278. S2CID 9414037.
  7. ^ . Wulf, William; Cohen, Ellis; Corwin, William; Jones, Anita; Levin, Roy; Pierson, C.; Pollack, Fred (Juni 1974). "Hydra: Der Kernel eines Multiprozessor -Betriebssystems". Kommunikation der ACM. 17 (6): 337–345. doi:10.1145/355616.364017. S2CID 8011765.
  8. ^ Rashid, Richard; Robertson, George (Dezember 1981). Akzent: Ein kommunikationsorientiertes Netzwerk -Betriebssystem -Kernel. SOSP '81 Verfahren des achten ACM -Symposiums für Betriebssysteme. Pacific Grove, Kalifornien, USA. S. 64–75. doi:10.1145/800216.806593.
  9. ^ Sassenrath, Carl (1986). Amiga ROM Kernel Referenzhandbuch. Geschäftsführer.
  10. ^ Jim Magee. WWDC 2000 Sitzung 106 - Mac OS X: Kernel. 14 Minuten in. Archiviert vom Original am 11. Dezember 2021.
  11. ^ "Portierung von UNIX/Linux -Anwendungen in Mac OS X". Apfel. Abgerufen 26. April 2011.
  12. ^ a b c Lieedtke, Jungen (September 1996). "In Richtung echter Mikrokernel". Kommunikation der ACM. 39 (9): 70–77. doi:10.1145/234215.234473. S2CID 2867357.
  13. ^ Heiser, Gernot; Uhlig, Volkmar; Levasseur, Joshua (Januar 2006). "Sind Virtual-Machine-Monitore Mikrokernel richtig gemacht?". ACM SIGOPS -Betriebssysteme Überprüfung. ACM. 40 (1): 95–99. doi:10.1145/1113361.1113363. S2CID 7414062.
  14. ^ Lieedtke, Jungen (Dezember 1993). Verbesserung der IPC durch Kernel Design. 14. ACM -Symposium zu Betriebssystemprinzipien. Asheville, NC, USA. S. 175–88. Citeseerx 10.1.1.40.1293.
  15. ^ a b Chen, J. Bradley; Bershad, Brian N. (Dezember 1993). Die Auswirkungen der Betriebssystemstruktur auf die Leistung des Speichersystems (PDF). SOSP '93 Proceedings des vierzehnten ACM -Symposiums über Betriebssystemprinzipien. Asheville, NC, USA. S. 120–133. doi:10.1145/168619.168629.
  16. ^ a b c Lieedtke, Jungen (Dezember 1995). Auf µ-Kernel-Konstruktion. SOSP '95 Proceedings des fünfzehnten ACM -Symposiums für Betriebssysteme Prinzipien. Copper Mountain Resort, CO, USA. S. 237–250. doi:10.1145/224056.224075.
  17. ^ Elphinstone, Kevin; Heiser, Gernot (November 2013). Von L3 bis SEL4: Was haben wir in 20 Jahren von L4 Microkernels gelernt?. SOSP '13 Verfahren des vierundzwanzigsten ACM-Symposiums über Betriebssystemprinzipien. Farmington, PA, USA. S. 133–150. doi:10.1145/2517349.2522720.
  18. ^ "Synchrone Nachricht passieren". Abgerufen 14. Juli 2019.
  19. ^ "Das QNX -Hochverfügbarkeits -Toolkit" (PDF). Archiviert von das Original (PDF) am 24. August 2005.
  20. ^ Wong, William (27. April 2007). "I/O, ich/o, es geht um virtuelle Arbeiten, die wir gehen.". Elektronisches Design. Abgerufen 8. Juni 2009.
  21. ^ Alexander, Michael T. (1971). "Organisation und Merkmale des Michigan -Terminalsystems". Proceedings der vom 16. bis 18. November 1971, Herbst Joint Computer Conference. 40: 589–591. doi:10.1145/1478873.1478951. S2CID 14614148.
  22. ^ Lions, John (1. August 1977). Der Kommentar von Lions zu Unix 6. Ausgabe mit Quellcode. Peer-to-Peer-Kommunikation. ISBN 978-1-57398-013-5.
  23. ^ Lieedtke, Jungen; Elphinstone, Kevin; Schönberg, Sebastian; Härtig, Hermann; Heiser, Gernot; Islam, nayeem; Jaeger, Trent (Mai 1997). Erreichte IPC -Leistung (immer noch die Grundlage für die Erweiterbarkeit). 6. Workshop zu heißen Themen in Betriebssystemen. Cape Cod, MA, USA: IEEE. S. 28–31.
  24. ^ Gray, Charles; Chapman, Matthew; Chubb, Peter; Mosberger-Tang, David; Heiser, Gernot (April 2005). Itanium - die Geschichte eines Systemimplementers. Usenix jährliche technische Konferenz. Annaheim, CA, USA. S. 264–278.
  25. ^ Van Schaik, Carl; Heiser, Gernot (Januar 2007). Hochleistungsmikrokernel und Virtualisierung auf Arm und segmentierte Architekturen. 1. Internationaler Workshop über Mikrokernel für eingebettete Systeme. Sydney, Australien: Nicta. S. 11–21. Archiviert von das Original am 26. April 2007. Abgerufen 1. April 2007.
  26. ^ Härtig, Hermann; Hohmuth, Michael; Lieedtke, Jungen; Schönberg, Sebastian (Oktober 1997). "Die Leistung von µ-Kernel-basierten Systemen". Verfahren des Sechzehnten ACM -Symposiums über Betriebssystemprinzipien. 31 (5): 66–77. doi:10.1145/268998.266660. ISBN 0-89791-916-5. S2CID 1706253.
  27. ^ Gefflaut, Alain; Jaeger, Trent; Park, Yoonho; Lieedtke, Jungen; Elphinstone, Kevin J.; Uhlig, Volkmar; Tidswell, Jonathon E.; Deller, Luke; et al. (2000). Der Sägewerk Multiserver -Ansatz. 9. ACM Sigops European Workshop. Kolding, Dänemark. S. 109–114. Citeseerx 10.1.1.25.8376.
  28. ^ Leslie, Ben; Chubb, Peter; Fitzroy-Dale, Nicholas; Götz, Stefan; Gray, Charles; Macpherson, Luke; Potts, Daniel; Shen, Yueting; Elphinstone, Kevin; Heiser, Gernot (September 2005). "Gerätetreiber auf Benutzerebene: Leistung erzielt". Zeitschrift für Informatik und Technologie. 20 (5): 654–664. doi:10.1007/s11390-005-0654-4. S2CID 1121537.
  29. ^ Tanenbaum, Andrew S. "Tanenbaum-Torvalds Debatte, Teil II".
  30. ^ Tanenbaum, A., Herder, J. und Bos, H. (Mai 2006).
  31. ^ Biggs, Simon; Lee, Damon; Heiser, Gernot (2018). "Die Jury ist in: Monolithisches OS-Design ist fehlerhaft: Microkernel-basierte Designs verbessern die Sicherheit". Verfahren des 9. asiatisch-pazifischen Workshops über Systeme. Jeju Island, Republik Korea: Vereinigung für Computermaschinen. S. 1–7. doi:10.1145/3265723.3265733.
  32. ^ Shapiro, Jonathan S.; Weber, Samuel. Überprüfung des EROS -Begrenzungsmechanismus. IEEE -Konferenz über Sicherheit und Privatsphäre. Archiviert von das Original am 3. März 2016.
  33. ^ Elkaduwe, Dhammika; Klein, Gerwin; Elphinstone, Kevin (2007). Verifiziertes Schutzmodell des SEL4 -Mikrokernels. zur Veröffentlichung eingereicht.
  34. ^ a b Klein, Gerwin; Elphinstone, Kevin; Heiser, Gernot; Andronick, Juni; Schwanz, David; Derrin, Philip; Elkaduwe, Dhammika; Engelhardt, Kai; Kolanski, Rafal; Norrish, Michael; Sewell, Thomas; Tuch, Harvey; Winwood, Simon (Oktober 2009). SEL4: Formale Überprüfung eines OS -Kernels (PDF). 22. ACM -Symposium zu Betriebssystemprinzipien. Big Sky, MT, USA.
  35. ^ Elkaduwe, Dhammika; Derrin, Philip; Elphinstone, Kevin (April 2008). Kerneldesign für die Isolation und Gewissheit des physischen Gedächtnisses. 1. Workshop zur Isolation und Integration in eingebettete Systeme. Glasgow, Großbritannien. doi:10.1145/1435458. Archiviert von das Original am 24. April 2010. Abgerufen 17. August 2009.
  36. ^ a b "Tud Home: Betriebssysteme: Forschung: Microkernel & Hypervisor". Fakultät für Informatik. Technische Universität Dresden. 12. August 2010. Abgerufen 5. November 2011.
  37. ^ Steinberg, Udo; Kauer, Bernhard (April 2010). Nova: Eine Mikrohypervisor-basierte sichere Virtualisierungsarchitektur. Eurosys 2010. Paris, Frankreich. S. 209–222. doi:10.1145/1755913.1755935.
  38. ^ Lackorzynski, Adam; Warg, Alexander (März 2009). Taming -Subsysteme - Funktionen als universelle Ressourcenzugriffskontrolle in L4. IIES'09: Zweiter Workshop zur Isolation und Integration in eingebettete Systeme. Nürnberg, Deutschland. Citeseerx 10.1.1.629.9845.
  39. ^ Klein, Gerwin; Andronick, Juni; Elphinstone, Kevin; Murray, Toby; Sewell, Thomas; Kolanski, Rafal; Heiser, Gernot (Februar 2014). "Umfassende formale Überprüfung eines OS -Mikrokernel". ACM -Transaktionen auf Computersystemen. 32 (1): 2: 1–2: 70. doi:10.1145/2560537. S2CID 4474342.
  40. ^ David L. Mills und Poul-Henning Kamp (28. November 2000). "Der Nanokernel" (PDF). Abgerufen 28. August 2017.

Weitere Lektüre