Der Durchschnittsbenutzer vergleicht seinen Computer mit seinem Fernseher: In beiden steckt wundersame Elektronik und beide haben große Bildschirme. Und er besitzt eine genaue Vorstellung, wie das mit einem Fernseher funktioniert.

Das Problem: Computer sind unzuverlässig

Erstens: Er kauft das Gerät. Zweitens: Er verkabelt es. Drittens: Es funktioniert die nächsten zehn Jahre perfekt und ohne jede Art Ausfall. Das Gleiche erwartet der Benutzer von seinem Computer, und wenn sich seine Erwartung nicht erfüllt, ist er frustriert. Er versteht auch nicht die Sprüche von Computerexperten wie: „Wenn Gott gewollt hätte, dass Computer die ganze Zeit funktionieren, dann hätte er nicht die Reset-Taste erfunden!“

Mangels einer anderen Definition von „Zuverlässigkeit“ benutze ich diese: Ein Gerät gilt als verlässlich, wenn 99 Prozent aller Besitzer während der Lebenszeit des Geräts nie irgendwelche Ausfälle zu beklagen haben. Nach dieser Definition ist so gut wie kein Computer zuverlässig, anders als die meisten Fernseher, I-Pods, Digitalkameras, Camcorder und so weiter. Techies tolerieren es, wenn ein Computer ein- oder zweimal pro Jahr abstürzt – normale User nicht.

Privatnutzer sind nicht als Einzige verärgert über die schlechte Zuverlässigkeit von Computern. Gerade für hochtechnische Umgebungen gilt die geringe Zuverlässigkeit von Computern als Problem. Firmen wie Google und Amazon mit ihren Hunderten und Tausenden von Servern leiden jeden Tag unter den vielen Softwarefehlern. Zwar haben sie sich mit der Situation arrangiert, lieber aber wäre ihnen, wenn die Systeme einfach nur liefen. Aktuelle Software jedoch vermag das nicht zu leisten.

Das Grundproblem besteht darin, dass Software Bugs enthält, und je mehr Software es gibt, desto mehr Bugs gibt es. Diverse Studien belegen, dass große Produktivsysteme zwischen einem und zehn Fehler pro tausend Zeilen Code (KLoC) aufweisen. Ein wirklich gut geschriebenes Stück Software kann zwei Bugs pro KLoC im Laufe der Zeit erreichen, aber nicht weniger. Ein Betriebssystem mit vielleicht vier Millionen Codezeilen besitzt somit wahrscheinlich mindestens 8000 Bugs. Nicht alle sind schwerwiegend, aber einige sind es. Eine Studie an der Stanford University hat gezeigt, dass Gerätetreiber – sie machen 70 Prozent des Code eines typisches Betriebssystems aus – drei- bis siebenmal höhere Bug-Raten aufweisen als der Rest des Systems. Dies liegt daran, dass Gerätetreiber zum einen kompliziert sind und zum anderen weniger kontrolliert werden. Viele Leute schauen sich den Scheduler an, aber nur wenige einen Druckertreiber.

Die Lösung: Kleinere Kernel

Code aus dem Kernel, wo er den größten Schaden anrichten kann, heraus in den Userspace zu verlagern, wo er keine Systemabstürze verursacht, behebt das Problem. Genau dem Designprinzip folgt Minix 3, der zweite Nachfolger des Ur-Minix. Das war 1987 zwar als Lehr-Betriebssystem entstanden, hat sich aber dann zu einem sehr zuverlässigen, selbstheilenden System entwickelt. Die Minix-3-Architektur ist bestrebt, so wenig Code wie möglich im Kernelmodus laufen zu lassen. Statt drei oder vier Millionen Zeilen ist der Minix-Kernel nur 5000 Codezeilen lang. Derartig kleine Kernel heißen Microkernel. Sie sind nur für das Low-level-Prozessmanagement, das Scheduling, die Interruptbehandlung sowie den Systemticker zuständig und stellen dem Userspace einige Basisdienste bereit.

Den Löwenanteil des Betriebssystems machen Gerätetreiber und Dienste aus, die alle als normale Userspace-Prozesse mit eingeschränkten Rechten laufen. Sie dürfen keine I/O-Devices oder das Speichermanagement ansprechen, sondern müssen Kerneldienste bemühen. Genauer: Treiber, darunter die für Festplatten und Netzwerk, befinden sich in einer Prozessschicht direkt über dem Kernel und laufen als eigenständige Prozesse unter dem Zugriffschutz der MMU. Sie dürfen keine privilegierten Befehle ausführen und nur auf einen eigenen Speicherbereich zugreifen.

Über dieser Treiberschicht liegt die Serverschicht mit Diensten wie dem File- oder dem Prozess-Server. Die Serverdienste greifen auf die Gerätetreiber und auf die Kerneldienste zu. Um beispielsweise eine Datei zu lesen, sendet ein Benutzerprozess ein Signal an den Fileserver, der den Plattentreiber veranlasst die nötigen Blöcke zu lesen. Sollten sie bereits im Puffer des Dateisystems stehen, kopiert der Kernel die Daten lediglich in den Adressraum des Benutzers.

Neben den gewöhnlichen Serverdiensten gibt es den so genannten Reincarnation-Server. Er ist der Vaterprozess aller Treiber- und Serverprozesse und überwacht ihr Verhalten. Falls einer der Prozesse nicht auf seine Ping-Anfrage antwortet, startet er von der Platte eine neue Instanz – mit Ausnahme des Disk-Treibers, der als Kopie im RAM liegt. Das System ist also so konstruiert, dass sich viele, wenn auch nicht alle, der kritischen Treiber und Dienste automatisch neu starten. Das System läuft bei einem Crash aus Benutzersicht ungestört weiter, es heilt sich selbst.

Als Praxistest haben wir ein Experiment veranstaltet: Einen Fault-Injection-Prozess ließen wir 100 Maschinenbefehle des laufenden Ethernet-Treiber-Binary überschreiben. Passierte nach einigen Sekunden nichts, so verseuchte der Prozess weitere 100 Instruktionen und so weiter. Insgesamt gelangten so 800000 Fehler in jeden der drei Ethernet-Treiber. Sie selbst stürzten dabei 18000-mal ab. Ergebnis: Alle Crashs fing der Reincarnation-Server automatisch ab. Trotz des Einpflanzens von insgesamt 2,4 Millionen fehlerhafter Maschinenbefehle ging das Gesamtsystem nicht ein Mal baden. Dass ein schwerwiegender Fehler in einem Linux- oder Windows-Treiber das ganze System zum Absturz bringt, ist bekannt.

Hat unsere Architektur auch Nachteile? Ja, es gibt Performance-Einbußen. Wir haben das nicht im Detail gemessen. Aber eine Forschungsgruppe in Karlsruhe, sie hat mit L4 ihren eigenen Microkernel entwickelt, hat Messungen durchgeführt. Als einziger Userprozess unter Linux laufend konnte sie den Geschwindigkeitsverlust auf 5 Prozent drücken. Wir glauben, dass wir mit etwas Mühe einen Overhead von Minix ebenfalls bei 5 bis 10 Prozent erreichen könnten. Die Performance hatte für uns bisher keine besondere Priorität, da es sowieso nicht die CPU ist, die Anwender beim Lesen ihrer E-Mails und beim Anschauen von Facebook-Seiten einschränkt. Was wir erreichen wollten, ist ein System, das immer zuverlässig funktioniert.

Wenn Microkernels so zuverlässig sind, warum benutzen nicht alle welche?

Im Grunde tut es ja jeder, die meisten sogar mehrere. Ein Handy zum Beispiel ist ein kleiner, aber sonst voll funktionsfähiger Computer, auf dem mit einiger Wahrscheinlichkeit L4 oder Symbian, ein weiterer Microkernel, läuft. Auch in Cisco-Hochleistungs-Routern arbeitet ein Microkernel. Beim Militär und in der Raumfahrt, wo Verlässlichkeit höchste Priorität genießt, ist Green Hills „Integrity“ weit verbreitet. Pike OS und QNX sind in Industrie- und Embedded-Rechnern häufig eingesetzte Microkernel. Mit anderen Worten: Wenn es wirklich darauf ankommt, dass ein System stets einsatzbereit ist, kommen tendenziell kleine Kernel zum Einsatz. (Mehr zum Thema unter [http://www.cs.vu.nl/~ast/reliable-os/].)

Alles in allem glauben wir, dass sich Normalanwender in erste Linie ein System wünschen, das zu jeder Zeit perfekt funktioniert. Die Einschätzung basiert auf vielen Gesprächen mit technisch weniger versierten Benutzern. Die zeigten wenig Verständnis für unzuverlässigen Systeme. Sie haben zurzeit bloß keine andere Wahl, als sich damit abzufinden. Ich meine, dass Microkernel-Systeme der Ausweg sind. (jk/pkr)