Bug im Linux-Kernel: Keine Panik!

Wenn der frische Kernel gleich nach dem Start das System zum Absturz bringt, werden Admins nervös. Denn oft beginnt nun die langwierige Suche nach dem Bug. Ein Erfahrungsbericht.

Artikel von Martin Loschwitz veröffentlicht am 12. April 2016, 12:09 Uhr

Wenn das Kernel-Update fehlschlägt - ein Erfahrungsbericht. (Bild: Screenshot / Hanno Böck)

Es gibt einige Gründe für Admins, ein Kernel-Update durchzuführen. Meist handelt es sich um Sicherheitsupdates, manchmal verspricht ein neuer Kernel auch aktuelle Treiber, die mehr leisten als der Vorgänger. So oder so gilt: Der Vorgang ist eine Standardprozedur, und Admins erwarten, dass alles funktioniert. Entsprechend unruhig werden sie, wenn etwas danebengeht. Wenn zum Beispiel wegen eines Fehlers einzelne - womöglich zentrale - Bauteile des Systems den Dienst verweigern.

Ist der Fehler in einem wichtigen Teil des Kernels, etwa in der Speicherverwaltung, lässt sich unter Umständen das System gezielt zum Absturz bringen. Selbst ein Fehler in einer exotischen Komponente, die nur auf wenigen Systemen aktiv ist, kann so zum Sicherheitsproblem werden: Durch sie lässt sich womöglich eine große Zahl an Systemen gezielt angreifen. Dieser Text berichtet von der Suche nach einem solchen Bug, die sich über mehrere Monate hinzog und nur durch das Zusammenspiel mehrerer Entwickler erfolgreich war.

Die Ausgangssituation

Das Setting ist schnell erklärt: Mehrere aktuelle, sehr leistungsfähige HP-Maschinen (DL380 Gen. 9) und Ubuntu 14.04 bilden die Basis. Openstack betreibt auf ihnen virtuelle Maschinen, im Hintergrund wird die verteilte Speicherlösung Quobyte eingesetzt. Sie ist auf allen beteiligten Hosts als Server wie als Client aktiv. Die Server-Komponente macht aus den einzelnen Festplatten der einzelnen Hosts einen großen, logischen Datenspeicher, der per zentraler Schnittstelle ansprechbar ist. Obendrein steuert Quobyte für die Daten des Netzwerkspeichers automatisch Redundanz bei. Per Treiber für Fuse (Filesystem in Userland) binden die Hosts das Dateisystem aus der Ferne ein. Die virtuellen Festplatten der Openstack-Systeme liegen auf jenem Fuse-Mount.

Weil die genannten HP-Server viel aktuelle Hardware nutzen, fiel schon anfangs die Wahl auf die LTS-Kernel (LTS steht für Long Term Support) von Canonical. Anders als Red Hat und SUSE bietet Canonical einen Weg, um auch auf Systemen mit Langzeit-Unterstützung aktuelle Kernels zu verwenden.

Der Deal ist simpel: Canonical portiert die Kernel der aktuellen Releases auf die jeweils letzte LTS-Version zurück. Für Ubuntu 14.04, die bei Erscheinen dieses Artikels aktuelle LTS-Version von Ubuntu, stehen etwa die Kernels von Ubuntu 14.10, 15.04 und 15.10 als LTS-Kernel zur Verfügung. Beim Erscheinen der nächsten LTS-Version von Ubuntu, also 16.04, fängt das Spiel von vorne an. Für 16.04 wird es dann die Kernel späterer Ubuntu-Versionen geben und für Ubuntu 14.04 wird wenigstens der Kernel von Ubuntu 16.04 als Backport zur Verfügung stehen. Der Support für ältere Kernel auf Ubuntu 14.04 läuft allerdings bald nach der Veröffentlichung von 16.04 aus. Wer sich für die LTS-Kernels auf Ubuntu 14.04 entscheidet, muss zumindest dann zwangsläufig ein Update einspielen.

Insgesamt erscheint die Lösung deutlich eleganter als die anderer Hersteller, die Kernel-Version auf dem Stand von vor mehreren Jahren zu belassen und den Kernel selbst mit schier unendlich vielen Patches aufzupolstern. Beim Erscheinen des LTS-Kernel 4.2 im Februar 2016 fiel die Entscheidung, auf diesen zu setzen. Denn viele Updates versprachen bessere Performance auf mehreren Ebenen des Systems.