Mit dem Linux-Magazin sprachen Greg Kroah-Hartman und Jonathan Corbet am Rande des Open Source Summit über Maintainer-Probleme, Silos in Subsystemen und die Bugs im Linux-Kernel.
In Lyon begann am Montag der Open Source Summit Europe. Eine der ersten Keynotes hielt dabei Kernel-Entwickler Greg Kroah-Hartman, der noch einmal über die durch Spectre- und Meltdown verursachten Hardwareprobleme sprach (Abbildung 1). Dank der Bugs wisse er nun mehr über die CPU-Interna als er jemals wissen wollte. Der Betreuer des stabilen Kernel gab zudem dem Open-BSD-Projekt im Nachhinein Recht: Das hatte entschieden, Hypterthreading komplett abzuschalten und die Performance-Einbußen akzeptiert. Die Sicherheit über die Performance zu stellen, sei laut Kroah-Hartman im Nachhinein der richtige Weg gewesen.
Abbildung 1: Noch immer treiben die Hardware-Bugs die Kernel-Entwickler um.
Um mit dem Linux-Kernel auf der sicheren Seite zu sein, sollten Admins stets sämtliche Kernel-Patches einspielen. Sich nur an CVEs zu halten, würde in diesem Fall nicht viel helfen: Denn nicht alle Patches erhalten CVEs, zudem gibt es für einige CVEs Folgepatches, die wiederum nicht in den CVEs selbst auftauchen. Nicht zuletzt reparieren Patches sehr häufig Probleme, die erst viel später in CVEs auftauchen. Cherry Picking helfe hier also aus mehreren Gründen nicht weiter. Einige Bugfixes beheben zum Beispiel nicht nur aktuelle Probleme, sondern schließen zugleich auch potenzielle Security-Lücken. Er empfahl, stets die Kernel der großen Distributionen zu verwenden, weil die tatsächlich alle Patches einspielen.
Multithreading suspendiert
Der ungewollte Blick hinter die CPU-Kulissen bringe jedenfalls die typischen Probleme proprietärer Systeme zum Vorschein. Zu denen gehören laut Corbet auch eine Menge seltsam eingebauter Caches. Ob sich die Situation mit Hyperthreading irgendwann wieder ändern werde, lautete eine der Fragen im späteren Interview mit Greg Kroah-Hartman und Jonathan Corbet (Abbildung 2).
Abbildung 2: Auf dem Open Source Summit Europe 2019 in Lyon sprach das Linux-Magazin mit den Kernel-Entwicklern Jonathan Corbet (l.) und Greg Kroah-Hartman (r.)
Corbet betonte insbesondere, dass die Probleme auch deshalb schwer zu beheben seien, weil Process Sharing tief in der Hardware verankert sei. Dennoch gebe es trotz dieser Probleme Bewegung und neue Features, die Multithreading auch in unsicheren Umgebungen sicherer machen wollen. Die Technologie sei kompliziert, das Stichwort lautet Core Scheduling und wird in der Kernel-Community zurzeit diskutiert. Komplett entspannen dürfte sich die Situation aber erst mit einer neuen Generation an Hardware, die dann aber vermutlich wieder neue Probleme mit sich bringe.
Zu viele Bugs
Was die in der Keynote neu vorgestellte Kernel CI angeht, setzen Kroah-Hartman und Corbet durchaus Hoffnungen in sie: das aktuelle System sei sehr zersplittert, die verschiedenen Gruppen hätten sich nun auf eine Idee geeinigt. Ist deren Funktionalität ausgereift, könne man auf das neue System wechseln. Dessen Chancen stehen gut, weil die Idee keine Erfindung der Linux Foundation sei (die lange darauf gedrängt hatte), sondern aus der Entwickler-Community entstanden sei und diese im Rücken habe.
Die diversen Testsysteme werfen aber auch ganz neue Probleme auf, wie Kroah-Hartman in der Keynote erklärte: “Wir finden Bugs nun schneller als wir sie fixen können.” Die Tools zur Bug-Suche würden Layer um Layer tiefer in den Kernel vordringen und zum Teil sehr alte Bugs an die Oberfläche holen. Wie sich das aus dem Ruder gelaufene Verhältnis zwischen Bugs und Fixes wieder umdrehen lasse, darüber denkt die Kernel-Community aktuell noch nach. Neue Tools und Automatisierungen könnten zukünftig dafür sorgen, dass offensichtliche Bugs gar nicht erst im Code landen. An einigen Stellen könnte wohl auch Machine Learning helfen.
Hürdenlauf und Rust
Eine weitere Frage lautete, ob der Kernel sich nicht für weitere Programmiersprachen öffnen müsse, um mehr junge Entwickler anzuziehen. Hier sehen Kroah-Hartman und Corbet kein wirkliches Problem. Jeden Monat würden 200 neue Leute am Kernel mitarbeiten. Die für den Kernel verwendete Sprache C sei für neue Entwickler in der Regel keine echte Hürde. Dennoch könne sich Kroah-Hartman unter bestimmten Voraussetzungen vorstellen, Rust-Module in den Kernel zu integrieren.
Eine tatsächliche Barriere für Neueinsteiger sei hingegen die vorhandene E-Mail-basierte Kommunikationsstruktur und Form der Patchverteilung. Github zu nutzen, würde bei der Größenordnung des Kernelprojekts nicht funktionieren, dennoch sei für neue Entwickler der veraltete Prozess schmerzhaft zu erlernen.
Maintainer-Bürden
Nachwuchsprobleme gebe es weiterhin bei den Maintainern: Die seien überarbeitet und unterbesetzt. Die Bürde der Maintainer betrachten sowohl Jonathan Corbet als auch Greg Kroah-Hartman als Problem, das dringend nach einer Lösung verlangt. Viele Subsysteme hätten nur eine Person, die sich darum kümmert, der Busfaktor sei hier relativ hoch. Zudem seien Maintainer chronisch überarbeitet. Sie werden von ihren Arbeitgebern für das Betreuen der Subsysteme häufig nicht bezahlt, selbst dann, wenn diese von der darin erzeugten Software profitieren.
Als weiteres dringend zu lösendes Problem sehen die Kernel-Entwickler die verschiedenen Workflows in den Subprojekten. Sie erschweren es, systemübergreifend zu kooperieren. Wer seinen Code nach den Regeln für Subsystem A schreibt, muss für Subsystem B wieder umlernen, will er auch dort Code unterbringen. Im Laufe der Jahre seien so viele kleine Silos entstanden. Den Ist-Zustand erstmal zu dokumentieren, ihn ans Licht zu bringen, könnte in Zukunft helfen, diese Subsysteme und ihre Workflows mehr zu vereinheitlichen. Insbesondere Jonathan Corbet dürfte die Arbeit also so bald nicht ausgehen.
