Kernel-Log: Stable-Kernel analysiert, Linux ohne Firmware, neue Grafiktreiber

Inhaltsverzeichnis

Einen Tag nach der Freigabe von Linux 2.6.33 in der letzten Februarwoche begann Linus Torvalds mit der Aufnahme der größten Änderungen für Linux 2.6.34. Bislang hat er knapp fünftausend Commits vorgenommen, durch die der Kernel um beinahe zweihundertausend Zeilen gewachsen ist. Neu zum Kernel gestoßen sind unter anderem der Treiber für die Magic Mouse von Apple, eine Python-Scripting-Engine für das Tracing-Subsystem sowie der Virtio-Server vhost_net, der den Overhead beim Datenaustausch mit Gastsystemen via Virtio reduzieren soll.

Das Merge Window ist noch einige Tage offen, dieses Mal aber möglicherweise statt zwei voller Wochen nur 10 oder 12 Tage – das deutete Torvalds an, um die Subsystem-Verwalter zu animieren, ihre Änderungen nicht auf den letzten Drücker einzusenden. Einige bereits für 2.6.34 eingereichte Verbesserungen an SquashFS sowie die Patches zur Aufnahme des Subsystems zum Ansprechen von Helligkeitssensoren (Ambient Light Sensors/ALS) hat Torvalds indes bereits kritisiert (1, 2); sofern er seine Meinung nicht nochmal ändert, dürfte beides frühestens bei 2.6.35 zum Linux-Kernel stoßen.

Torvalds wies zudem die Verwalter der grundlegenden Infrastruktur für Treiber ("Driver Core") und den des Direct Rendering Managers (DRM) nachhaltig darauf hin, dass neue Kernel-Funktionen bei der Kernel-Konfiguration nicht standardmäßig eingeschaltet werden sollten, wenn es dafür keinen triftigen Grund gibt (1, 2). Die DRM-Programmierer änderten daraufhin einige der eingesandten Patches, die Torvalds schließlich am Donnerstag Abend in den Hauptentwicklungszweig aufnahm.

Erst kurz danach bemerkte Torvalds bei einem Test, worauf der DRM-Subsystem-Verwalter in seinem ersten Git-Pull-Request bereits hingewiesen hatte: Eine inkompatible API-Änderung an dem bei Linux 2.6.33 aufgenommenen Nouveau-Treiber für Grafikhardware von Nvidia. Wer den auf dem Kerneltreiber aufsetzenden Nouveau-Treiber für X.org nutzen will, muss diesen sowie die Libdrm daher parallel mit dem Kernel aktualisieren – das erschwert anderen Testern sowie Anwendern den Alltag, denn sie können nicht einfach zwischen Kerneln vor und nach der Aufnahme der API-Änderungen hin- und her wechseln, wenn sie den Nouveau-Treiber für X.org einsetzen.

Torvalds kritisierte das nachhaltig und löste damit eine längere, teils hitzige und noch andauernde Diskussion aus. In der weisen einige Nouveau-Entwickler darauf hin, dass Torvalds doch selbst auf eine zügige Aufnahme gedrängt hatte, obwohl diese und weitere Änderungen an den Schnittstellen zu erwarten gewesen waren – daher ist der Nouveau-Treiber auch als unreifer Staging-Treiber markiert, denn bei richtigen Treibern werden die Schnittstellen zum Userspace normalerweise nur in abwärtskompatibler Weise geändert.

Linux-Stable

Die im vorangegangene Kernel-Log bereits erwähnte Kernel-Version 2.6.32.9 ist nach wie vor der neueste Kernel der Stable-Series. Auch dessen Freigabe-Mail enthielt wie so häufig bei Stable-Kerneln die Empfehlung, auf die neue Version zu wechseln, ohne explizit auf Korrekturen für Sicherheitslücken hinzuweisen.

Allerdings hat sich Jonathan Corbet, Gründer von Linux Weekly News (LWN) und selbst am Linux-Kernel mitarbeitend, die 96 Änderungen einer Vorabversion von 2.6.32.9 exemplarisch näher angesehen und in einem mittlerweile auch Nichtabonnenten von LWN.net zugänglichen Artikel beschrieben. Gleich zu Beginn weist er darauf hin, das die Analyse sehr viel Arbeit war und es wahrscheinlich sei, dass er einige Dinge übersehen hätte.

Das war auch tatsächlich der Fall, denn Corbet hatte 18 der Änderungen als potenziell Sicherheitslücken beseitigende Korrekturen eingestuft ("Security-related fixes"). Schon der erste Kommentar zum Artikel wies aber darauf hin, dass eine weitere Korrektur auch in diese Kategorie gehört hätte, denn die Lücke lässt sich für einen Angriff nutzen und hat sogar eine CVE-Nummer; die Leser spekulieren in weiteren Kommentaren über einige andere potenziell ausnutzbare, aber nicht als Sicherheitslücke eingestufte Korrekturen.

Das zeigt, dass sich Anwender selbst kompilierter Kernel am besten wirklich einfach updaten, wie es die Freigabe-Mails der Stable-Series empfehlen – ein solches Update dürfte nämlich häufig erheblich weniger Arbeit machen als eine genaue (und möglicherweise fehlerhafte) Analyse der Änderungen. Anwender von Distributionskerneln brauchen sich darum allerdings keine Gedanken machen, denn dort kümmern sich der Distributor um das Bereitstellen von Updates – dabei muss man aber hoffen, dass die Mitarbeiter alle potenziell Sicherheitslücken korrigierende Änderungen auch erkennen und in ihre Kernel einbauen.

Komplett frei

Die Free Software Foundation Latin America (FSFLA) hat Linux-2.6.33-libre veröffentlicht. Zu ihr gehören die erheblich überarbeiteten und dadurch potenziell schneller arbeitenden Libre-Kernel-Deblob-Skripte, die alle Teile im Quellcode von Linux 2.6.33 entfernen, die die FSFLA als unfrei ansieht; wer die Skripte nicht selbst laufen lassen möchte, kann auch ein um Firmwares bereinigtes Archiv von 2.6.33 direkt herunterladen.

Entfernt werden beim Libre-Kernel unter anderem einige mit dem Hauptentwicklungszweig von Linux ausgelieferte Firmware-Dateien, die verschiedene Treiber in die Chips der Geräte laden müssen, um die Hardware in Betrieb zu nehmen. Die Lizenz dieser Dateien erlaubt eine Weiterverbreitung zusammen mit dem Linux-Kernel; da jedoch kein Quellcode beiliegt, werden solche "Binary Large Objects" (Blobs) als unfrei angesehen.

Mit dem Libre-Kernel oder Linux-Distributionen, die solche und ähnliche Firmware-Dateien nicht mitliefern, laufen daher einige Hardware-Komponenten nicht oder nur eingeschränkt. Das kann sogar Hauptprozessoren betreffen, weil diese häufig Fehler enthalten, die durch sogenannte Microcode-Patches behoben oder umgangen werden. Das Mainboard-BIOS spielt solche Microcode-Updates normalerweise vor dem Booten von Betriebssystemen ein. Da viele Anwender das BIOS aber nur selten aktualisieren, haben die Prozessor-Hersteller schon vor vielen Jahren Schnittstellen geschaffen, über die auch Betriebssysteme früh im Boot-Prozess frischen Microcode einspielen können. So lassen sich CPU-Fehlerkorrekturen über die Update-Funktionen moderner Betriebssysteme einfach und schnell weit verteilen. Anwender von Linux-Distributionen, die Microcode-Updates nicht ausliefern, nutzen so die ältere Microcode-Version im Prozessor, die möglicherweise einige CPU-Bugs nicht behebt.

Die Kernel-Entwickler um David Woodhouse arbeiten übrigens schon länger daran, die teilweise enge Verquickungen zwischen Treibern und Firmware zu beseitigen. Einige Distributionen nutzen die Firmware-Dateien des Kernel bereits nicht mehr und liefern statt dessen ein von Woodhouse auf Kernel.org gepflegtes Archiv mit den Firemware-Dateien aus.