Microkernel: Exokernel und L4

Zusammenfassung

Der L4 und der Exokernel, sind zwei Varianten der sogenannten µ-Kernel. Es werden kurz die Motivation für diesen Typus Kernel vorgestellt und danach die Charakteristika der beiden Modelle. Beim Exokernel ist dies sicheres Multiplexen der Hardware, Secure Bindings und Downloadable Code.

Anmerkung: Im Augenblick ist hier noch keine Information über den L4 Kernel zu finden, dieser Bereich folgt noch. Christian Burger 16:48, 14 December 2006 (CET)

Motivation

µ-Kernelentwickler motivieren µ-Kernel gegenüber monolithischen Kernel, insbesondere in drei Punkten:

• hohes Abstraktionsniveau der Hardwareschnittstellen verhindert Flexibilität und demotiviert Innovation der Anwendungsentwickler bei der Implementation – neue Abstraktionen müssen auf bestehenden Abstraktionen aufsetzen.¹
• erschwerte Wartung des Kernels, denn alle Kernelbestandteile im monolithischen Kernel teilen sich einen Adressraum im Speicher. Somit kann ein Kernel-Prozess direkt auf einen anderen zugreifen. Klare Schnittstellendefinitionen zwischen den Komponenten sind nicht vorhanden oder können unterlaufen werden, und somit zu einem nicht zu überschauendem Kausalitätensystem führen.
• Gefährdung der Systemstabilität aus dem selben Grund wie zuvor: Ein Kernelprozess kann in den Speicher eines anderen schreiben und Code oder Daten manipulieren.

¹ Datenbankmanagementsysteme implementieren ein eigenes System, um Daten (Tabelle, Beziehungen, Indizies) auf der Festplatte zu speichern, welches unnötigerweise auf dem bestehenden Dateisystem implementiert wird.

Exokernel

Ein Exokernel ist kurz gesagt: Eine minimale Ausgabe eines Kernels, der wichtige Ressourcen – ohne viele Umwege über Abstraktionen – multiplext und den Anwendungen, die im Besitz einer Ressource sind, den Zugriff darauf sichert.

Prinzipien

Das Exokernelkonzept folgt drei Kernprinzipien:

1. Multiplexen der Hardware,
2. minimale Abstraktion der Hardware und
3. möglichst vollständige Repräsentation der Hardware.

Der daraus entstehende Kernel soll besonders stabil und schnell sein, denn er ist klein und überschaubar – damit auch leicht zu warten. Den Programmierern von Anwendungen räumt er viel Freiraum und großes Optimierungspotential bei der Umsetzung ihrer Algorithmen ein.

Multiplexen der Hardware heißt, dass jeder Prozess über den Kernel auf die Hardware zugreifen kann und das für ihn die Ressource scheinbar allein zur Verfügung steht – ein ähnlicher Ausdruck ist Virtualisierung. Dabei soll die Hardwarearchitektur so wenig wie möglich durch den Kernel abstrahiert werden. Das bedeutet auch, dass der Kernel sehr wenig Verwaltungsaufwand betreibt und wenig bis keine Ahnung von der Hardware hat, die er den Anwendungen gegenüber exponiert.

Dieses Vorgehen der minimalen Abstraktion steht im extremen Gegensatz zu den heute weit verbeiteten monolithischen Kerneln. Diese bieten den Prozessen eine hohe Abstraktionsebene der Hardware mit gewissen Funktionalitäten, wie zum Beispiel Arbeitsspeicher als virtueller Speicher mit Swapping oder die Festplatte als Dateisystem mit Rechteverwaltung.

Zwischen den Grundprinzipien muss aber ein Kompromiss hergestellt werden: Ohne höhere Abstraktion ist selten Multiplexen möglich. Darum beschränken sich die Ur-Implementationen (Aegis und Xok) auf das Multiplexen des Arbeitsspeichers, der CPU, der Festplatte und des Netzwerkes. Man übertreibt sicher nicht, wenn man diese als die notwendigsten Bestandteile eines Computers bezeichnet. Andere Geräte, wie zum Beispiel der Drucker werden vom Kernel nicht multiplext, dies muss dann auf Anwendungsebene geschehen.

Vollständige Repräsentation der Hardware schließt im Fall des Exokernels sogar den Zugriff auf Direct Memory Access, Translation Lookaside Buffer oder eigentlich priviligierte Prozessorkommandos auf die ein User-Level-Prozess im Normalfall keinen Zugriff hätte – alles wird in den Anwendungsbereich exportiert, was dem Entwickler beim Optimieren helfen kann. Immer natürlich unter der Prämisse, dass dem Prozess nur soviel gestattet wird, dass er andere Prozesse nicht gefährden kann.

Umsetzungsideen

Um die Hardware sicher verteilen zu können, bedient sich der Kernel einem Konzept, dass Secure Bindings genannt wird. Ein Prozess kann vom Kernel ein Secure Binding von einer Hardwareressource anfordern. Ist diese Anforderung erfolgreich, wird der Prozess der Besitzer der Ressource und hat dann die Möglichkeit die Ressource nach seinem Belieben zu manipulieren, mit anderen zu teilen oder sie wieder freizugeben. Um von einer sicheren Verteilung zu sprechen, muss eine 1-zu-1-Beziehung zwischen Besitzer und Ressource vom Kernel gesichert sein.

Um die Hardware multiplexen zu können, wird die Ressource eines bestimmten Typus in mehrere kleinere Einheiten unterteilt, die dann einzeln zugewiesen werden können. Dabei soll diese Einteilung von der Natur der Ressource so wenig wie nur möglich abweichen:

1. eine Festplatte ist in Sektoren eingeteilt,
2. der Arbeitsspeicher in Seiten,
3. der Prozessor in eine feste Anzahl von Zeitquanten und
4. eine Soundkarte könnte in Kanäle aufgeteilt werden.

Zu bedenken ist, dass man für die Festplatte oder Soundkarte das Abstraktionsniveau noch niedriger halten könnte und direkt die Hardware-Ports exponiert. Hier wird zugunsten der Multiplexing-Eigenschaft ein höheres Niveau gewählt.

Der Kernel hat die Möglichkeit durch Visible Resource Revocation und ein Abort Protocol gesponsorte Ressourcen wieder zurück zu verlangen. Die Visible Resource Revocation ist als eine Art Bitte des Kernels zu verstehen, Ressourcen von einem Typ freizugeben (z.B.: physikalischer Arbeitsspeicher). Welche konkrete Instanz (z.B.: Speicherseite Nummer x) er freigeben möchte ist dem Prozess selbst überlassen. Das Abort Protocol ist die letzte Maßnahme des Kernels, um Ressourcen wieder zu erhalten, damit wird einem unkooperativen Prozess die Ressource einfach entzogen und dieser wird darüber informiert.

Üblicherweise findet Resource Revocation im monolithischen Systemen transparent oder invisible für den User-Level-Prozess statt – schön zu veranschaulichem am Beispiel des Auslagerungsspeichers: Wird der physikalische Arbeitsspeicher knapp, lagert der Kernel Speicherseiten aus. Davon wissen die Anwendungen aber gar nichts, sie könnten höchstens eine gewisse Latenz beim Zugriff auf eine ausgelagerte Speicherseite feststellen.

Ein weiteres interessantes Konzept im Exokernel ist der Downloadable Code. Dies ermöglicht einem Prozess Code in den Kernel zu laden, der auf bestimmte Ereignisse hin ausgeführt wird und anstelle des Prozesses reagieren kann. Um die Systemstabilität zu erhalten, nutzt man Methoden wie Sandboxing und Codeverifizierung. Die aus Downloadable Code gewonnenen Vorteile sind:

1. weniger Kontextwechsel und Privilegienwechsel zwischen Kernel und Anwendungen und
2. damit einhergehend eine schnellere Reaktionszeit auf bestimmte Hardwareereignisse.

Downloadable Code wird zum Beispiel eingesetzt, um Netzwerkpakete an die zuständigen Anwendungen zu verteilen. Der Kernel führt bei einem eingehenden Ethernetpaket (seine rudimentäre Abstraktionsebene für Netzwerkkommunikation) von einem Prozess hineingeladenen Code aus, der wiederum das TCP/IP in Bruchstücken versteht und anhand von Merkmalen – wie IPAdresse und Port – bestimmen kann, ob das Paket zu seiner Anwendung gehört. Ist dies der Fall, kann er zum Beispiel die Anwendung – wenn sie geschlafen haben sollte – schedulen und das Paket an sie übermitteln, oder aber das Paket direkt beantworten ohne die Anwendung zu wecken.

Schlussbemerkung

Leider ging aus dem, für diesen Text zugrundeliegendem Papier (siehe Quellen: Exokernel) nicht hervor, welche Gründe oder Maßstäbe der Kernel für das Zurückfordern einer Ressource ansetzt. So blieben auch weitere Details ungeklärt. Da der Exokernel aber ein Konzept, eine Idee ist, bleibt der Implementation am Ende vorbehalten, in welchem Maße die gegebenen Ansätze genutzt werden.

Quellen

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

– Dawson R. Engler, M. Frans Kaashoek, and James O’Toole Jr. - [1]

• Exodisk: maximizing application control over storage management – Robert Grimm [2]