Linux-Kernel-Report: Spectre zeigt, wie man es nicht macht
In der Eröffnungskeynote des Open Source Summit Europe(öffnet im neuen Fenster) , der derzeit in Edinburgh stattfindet, hat der Journalist, Kernel-Entwickler und Chef des Magazins LWN.net, Jonathan Corbet, versucht, in einem sogenannten Kernel-Report Schlüsse aus aktuellen Entwicklungen der Community zu ziehen. Besonderes Augenmerk hat Corbet dabei auf den unterschiedlichen Umgang mit den Sicherheitslücken Meltdown und Spectre gelegt.
Der Umgang mit Meltdown sei demnach wesentlich offener gewesen. Dies habe zu dem Ergebnis geführt, dass zum Disclosure-Termin, also der öffentlichen Bekanntgabe der Lücken, die Patches im Linux-Kernel gegen Meltdown bereits in gutem Zustand gewesen seien. Die Patches haben darüber hinaus auch herstellerübergreifend eine relative Einheitlichkeit aufgewiesen, was Corbet klar als Vorteil benennt.
Im Vergleich dazu habe der zugeknöpfte Umgang mit Spectre hingegen zu Silos und einer stärkeren Fragmentierung geführt. Der Code zum Beheben der Lücke war zur Bekanntgabe der Schwachstelle je nach Distribution sehr unterschiedlich. Letztlich landete keine dieser Varianten direkt im Linux-Kernel, die Community war vielmehr gezwungen, über mehrere Wochen nach der Veröffentlichung an verschiedenen Aspekten zu arbeiten und sich auf ein einheitliches Vorgehen zu verständigen. Bei Entwicklern habe dieses Durcheinander bei Spectre laut Corbet nicht nur zu Frustration, sondern auch zu einem Burnout geführt. Viele Kunden und Projekte seien darüber hinaus zu wenig informiert worden und fühlten sich ausgebootet.
Diese Bestandsaufnahme wird sicher keiner der Beteiligten bestreiten können, ob und inwiefern Hersteller und Linux-Community daraus lernen, muss sich zwar noch zeigen. Erst Ende August kritisierte der Kernel-Maintainer Greg Kroah-Hartman vor allem Intel für sein Vorgehen in Bezug auf die Lücken und die daraus entstandenen Probleme. Zumindest laut Kroah-Hartman zeigen sich hier inzwischen jedoch auch klare Verbesserungen.
Langzeit-Kernel brauchen Ersatz
Ein zweites Thema, das Corbet in seinem Bericht betrachtet, ist die Entwicklung der stabilen Kernel mit Langzeitpflege. Er warf die grundsätzliche Frage in den Raum, wie sinnvoll Langzeitkernel seien und versucht dies an einem Beispiel zu erläutern. So gab es zwischen Kernel 4.9 und 4.9.135 etwa 10.000 Änderungen. Zwischen Kernel 4.9 und 4.19 kamen hingegen rund 136.000 Patches hinzu, also eine mehr als zehnfache Menge an Verbesserungen.
Das macht deutlich: Viele der möglichen Verbesserungen für Langzeitkernel erreichen diese schlicht überhaupt nicht. Eine Lösung für das Problem könnte sein, alte Kernel mit dem entsprechenden Testing eben doch auf neue zu aktualisieren. Ein Problem dabei bleibe aber alte Hardware, die nicht mehr aktualisiert werden kann. Die Idee von Corbet dürfte von einigen Herstellern, insbesondere jenen im Embedded-Bereich, aber als reichlich naiv angesehen werden.
Eine große Rolle in der künftigen Entwicklung des Linux-Kernels weist Corbet dem BPF-Projekt zu. Die hierbei erstellte virtuelle Maschine im Kernel ermöglicht es, Userspace-Code im Kernelspace auszuführen. BPF bringt außerdem einen JIT-Compiler mit und einen Verifier, der den Userspace-Code testet. Vielen Entwicklern seien die Möglichkeiten von BPF noch nicht klar, erklärt Corbet. Es handele sich aber um einen sehr großen technologischen Wechsel für den Kernel. Eben weil es BPF ermögliche, Userspace-Code im Kernel auszuführen und Kernel-Technologien in den Userspace auszulagern, werde die Grenze zwischen Kernel und Userspace künftig wohl durchlässiger. Ein erster Schritt in diese Richtung ist eine völlig neue Firewall-Technik, die auf BPF basiert.
Neuer Code of Conduct beeinflusst Kernel nicht
Nicht zuletzt äußerte sich Corbet natürlich auch zu der Einführung des neuen Code of Conduct. Corbet begleitet die Kernel-Entwicklung und die Linux-Community seit mehr als 20 Jahren sehr eng. In der "guten alten Zeit" habe es demnach eine Menge Dinge in der Kernel-Entwicklung nicht gegeben, darunter Sourecode-Management, automatisiertes Testing und Change-Tracking. All diese Dinge gebe es inzwischen. Die Kernel-Entwicklung sei inzwischen kein wilder Westen mehr, die technischen Probleme seien also längst adressiert.
Corbet gibt sich sicher, dass der Code of Conduct Teil dieser quasi natürlichen Evolution des Kernels ist und die Einführung der Regeln die fortschreitende Entwicklung nicht behindern wird. Beim tatsächlichen Text des Code of Conduct habe lediglich eine Aktualisierung gefehlt und die sei nun da. Er glaube nicht, dass sich mit dem Code of Conduct die Ängste einiger Entwickler erfüllen: Weder werden Leute außerhalb des Kernelprojekts die Kontrolle über das Projekt erhalten noch werde Code akzeptiert, der eigentlich nicht in den Kernel gehöre. Ebenso werde auch der Spaß an der Entwicklung nicht verloren gehen. Es bleibt zu hoffen, dass Corbet mit dieser Prognose recht behält.