Schlagwort: Kernel

Gestern hat Linus Torvalds Linux 5.16-rc5 freigegeben und den Stand der Entwicklung als »ziemlich normal« bezeichnet, auch wenn rc5 etwas größer sei als gewohnt. Das schreibt Torvalds den kommenden Feiertagen zu, da die Entwickler ihre Patches frühzeitig loswerden möchten. Ein weiterer Effekt der Feiertage ist, dass das Testen sich verlangsamt, weshalb Torvalds vorhat, den Entwicklungszyklus von Linux 5.16 um eine Woche zu verlängern und das stabile Release somit auf Anfang Januar fällt.

Release vermutlich im Januar

Neben den bereits Mitte November mit rc1 genannten Neuerungen unterstützt AMDGPU dann DisplayPort 2.0 und erhält erweiterten den Support für USB4. Das Raspberry Pi Compute Module 4 wird nun ebenfalls in Mainline unterstützt. Der PCIe-Treiber für Apple M1 wurde hinzugefügt, während Microsoft Patches für HyperV gelandet hat, die die Isolation von Virtuellen Maschinen verbessern soll.

2. Patchset für Rust

Gute Nachrichten gibt es auch bei der Anstrengung, die Programmiersprache Rust als zweite Sprache im Kernel zu verankern, auch wenn dies keine direkten Auswirkungen auf Linux 5.16 haben wird. Die Unterstützung für Rust wird vermutlich 2022 im Mainline-Kernel aufgenommen. Bereits im Sommer wurde eine erste Patch-Serie eingebracht, die vor wenigen Tagen von einem zweiten Teil ergänzt wurde.

Projektbetreuer Miguel Ojeda merkte an, dass die Unterstützung noch als experimentell anzusehen sei, allerdings benutze man nicht mehr den Rust-Compiler in der Beta-Version, sondern seit Rust 1.57.0 eine stabile Version. Seiner Meinung nach ist der Zustand der Unterstützung gut genug, »dass die Kernel-Entwickler mit der Arbeit an den Rust-Abstraktionen für die Kernel-Subsysteme beginnen und Treiber und andere Module schreiben können«.

Natürlich wird der Kernel mit seinen über 25 Millionen Zeilen niemals komplett in Rust umgeschrieben, aber die Unterstützung wird hoffentlich dazu führen, dass ein Teil des neuen Codes für den Kernel in Rust geschrieben wird und damit Probleme mit der Speichersicherheit bei C und C++ der Vergangenheit angehören.

Linus Torvalds hat gestern mit Linux 5.14-rc7 den vermutlich letzten Release-Kandidaten zu Linux 5.14 freigegeben. Mit der stabilen Veröffentlichung der nächsten Kernel-Version rechnet Torvalds am nächsten Sonntag, wenn nicht gravierende Ereignisse in der kommenden Woche das verhindern.

Die sind laut Torvalds aber nicht zu erwarten, da alles ruhig verlaufe und sich während der vergangenen Woche viele der Diskussionen unter den Entwicklern bereits um Linux 5.15 drehten. Dessen Zeitfenster für die Einreichung von Patches öffnet sich nach der Veröffentlichung von Linux 5.14 für zwei Wochen, bevor der Zyklus mit Linux 5.15-rc1 von vorne beginnt. Dann dauert es 6 – 10 Wochen, bevor ein neuer Kernel erscheint.

Was bringt Linux 5.14

Wie immer haben Treiber einen großen Anteil der Commits zu einem neuen Kernel. Dazu gehört Unterstützung für Intels kommende hybride Alder Lake P CPUs für mobile Geräte sowie für die AMD GPUs Beige Goby und Yellow Carb. AMD-Grafikkarten sollen dann zudem hot unplugging sauber unterstützen.

Der Raspberry Pi 400 wird unterstützt und die Integration von USB 4 vermeldet weitere Fortschritte. Ext4 erhält eine neue Option und der Code von XFS wird aufgeräumt. Btrfs erhält weiteres Performance-Tuning, während die Kompatibilität von exFAT verbessert wird. Auch F2FS erfährt Verbesserungen. Mehr zu Linux 5.14 heute in einer Woche.

Das ist zumindest die Meinung von Kees Cook vom Google Open Source Security Team, der viel Zeit in die Verbesserung der Sicherheit des Linux-Kernels steckt. Er begründet sein Statement mit der Tatsache, dass die nötigen Bugfix-Releases für den Mainline Kernel annähernd 100 Fixes pro Woche umfassen.

Angst vor Regressionen

Dies übe Druck auf Linux-Anbieter aus – einschließlich derjenigen, die die zahllosen Produkte unterstützen, auf denen Linux läuft, denn sie müssten ständig entscheiden, welche Patches für sie wichtig seien und dies dann einpflegen. Die ständige Aktualisierung des Kernels stoße vielerorts auf Ablehnung, so Cook, da immer die Gefahr bestehe, gleichzeitig Regressionen einzuführen.

Um die Dringlichkeit der Lage zu verdeutlichen, bezieht sich Cook auf Googles Fuzzing-Tool Syzcaller. das derzeit rund 1.000 mögliche Probleme im Kernel erkennt. Davon werden laut Cook rund 400 im Jahr beseitigt. Die Zahl der erkannten möglichen Probleme erhöhe sich jährlich um rund 100, sodass die Zahl der potenziellen Risiken ständig ansteige.

Denkbare Lösungen

Cook beschreibt in seinem Artikel einige für ihn denkbare Lösungen. Neben einer größeren Zahl von Testern vor einem stabilen Release nennt er die Verbesserung des Linux-Entwicklungs-Workflows als von entscheidender Bedeutung für die Erweiterung der Möglichkeiten aller Beteiligten, einen Beitrag zu leisten. Der E-Mail Arbeitsablauf von Linux sei in die Jahre gekommen, die vorgelagerte Entwicklung von automatisiertem Patch-Tracking, kontinuierlicher Integration, Fuzzing und vermehrten Tests würde den Entwicklungsprozess laut Cook deutlich effizienter machen.

100 Entwickler fehlen

Maintainer müssen neue Reviewer ausgiebig an ihrem Wissen über die einzelnen Sub-Systeme teil haben lassen, denn die Tester von heute seien die Maintainer von morgen. Cook schätzt, dass dem Kernel selbst, den Compilern und den Toolchains derzeit mindestens 100 Entwickler fehlen. Dieses Minus aufzufüllen sei die einzige Lösung, die ein ausgewogenes Maß an Sicherheit zu vernünftigen langfristigen Kosten gewährleisten könne, so Cook. Zudem müsse in der weiteren Entwicklung eine speichersichere Sprache wie Rust im Kernel gefördert werden.

Greg Kroah-Hartman (GKH), die Nummer zwei der Kernel-Entwicklung und üblicherweise ein Meister der leisen Töne fand jetzt harsche Worte für Studierende der Universität vom Minnesota (UMN), die für ein Forschungsprojekt vorsätzlich fehlerhafte Patches, die teilweise auch eine Sicherheitsgefährdung darstellten, an die Kernel-Mailingliste schickten, um die Sicherheit von FLOSS Projekten und hier im Speziellen die des Kernels zu testen.

Absichtlich fehlerhafte Patches

Anfang April erreichte ein Patch für den Autorisierungsmechanismus bei NFSv4 die Entwickler. Dass dieser Patch fehlerhaft und sinnlos war, fiel gleich zwei NFS-Entwicklern auf, woraufhin er abgelehnt wurde. Weitere zuvor eingereichte Patches waren ebenfalls absichtlich fehlerhaft und wurden komplett entfernt. GKH bezeichnete das Verhalten dieser Forschungsgruppe und ihres Professors als »absichtlich böswilliges Verhalten, nicht akzeptabel und völlig unethisch«. Ein anderer Entwickler sieht das ähnlich, wenn er schrieb, akademische Forschung sollte die Zeit von Communities nicht verschwenden.

Keine Einsicht

Aditya Pakki, der den letzten eingereichten Patch zu verantworten hat, reagierte unwirsch auf die Vorwürfe der Entwickler. Er bezeichnete die Vorwürfe als »wilde Anschuldigungen, die an Verleumdung grenzen«. Daraufhin platzte GKH der Kragen und verbat sich jegliche Experimente auf Kosten der Kernel-Entwickler. Als Resultat sperrte GKH alle Einreichungen der @umn.edu-Domain und somit die gesamte University of Minnesota von der Kernel-Entwicklung aus.

Untersuchung eingeleitet

Nachdem diese Sperre weite Kreise zog, liegt nun eine Erklärung der Universität zu dem Vorfall vor. Dort heißt es, die Forschungsreihe sei sofort nach Bekanntwerden der Vorfälle gestoppt worden. Es werde nun überprüft, wie diese Forschungsmethode und der Prozess, durch den diese Forschungsmethode genehmigt wurde, zustande kam, um solche Vorfälle künftig zu verhindern. Die Kernel-Entwickler sollen nach Abschluss der Untersuchung einen Bericht erhalten.