Linux 5.18 kommt als "kleine Revolution"

Inhaltsverzeichnis

In der Nacht von Sonntag auf Montag entließ Linus Torvalds den neuesten Spross 5.18 des Linux-Kernels in die Welt. Der neue Kernel war im Vorfeld als zwar umfangreiches, aber dennoch "nur" als Wartungs-Release gehandelt worden. Beim näheren Blick sind abseits von Treiber-Updates und Bugfixes dennoch einige interessante Neuerungen hinzugekommen, von denen einige richtungsweisend sind und manche sogar recht kontrovers diskutiert werden.

CPU im Abo

Linux 5.18 bietet das nötige Stück Code an, um Intels "Software Defined Silicon" (SDSi) nutzen zu können. SDSi ist ein Mechanismus zum Freischalten von Hardware-Features von zukünftigen Prozessoren des Chip-Herstellers aus Santa Clara. Der neue Linux-Kernel bietet hierfür einfache Operationen an, um einerseits Authentifizierungszertifikate in die CPU zu installieren und andererseits Eigenschaften (Capability) in der Hardware freizuschalten. Die Zertifikate dienen als Schlüssel, um das Freischalten der jeweiligen Hardware-Eigenschaften überhaupt zu ermöglichen. Erst wenn das passende Zertifikat installiert ist, lässt sich die jeweilige Capability aktivieren und nutzen.

Wird zu oft versucht, ein falsches Zertifikat zu installieren, sperrt die Hardware alle weiteren Versuche. Hierzu führt die Hardware einen Zähler, der beim Überschreiten eines Wertes keinen weiteren Versuch mehr zulässt. Erst nach einem Kaltstart kann ein neuer Freischaltanlauf gewagt werden.

Intel versucht, damit einem alten Geschäftsmodell wieder neues Leben einzuhauchen. Im Großrechnerumfeld war und ist es üblich, Systeme zwar Hardware-seitig voll ausgestattet zu liefern. Den nutzbaren Leistungsumfang definieren aber erst die gekauften Lizenzen. Über Microcode-Updates kann so der Mainframe-Hersteller Hardware aktivieren, deaktivieren oder sogar umwidmen. Ähnlich verhält es sich bei SDSi. Sind die passenden Zertifikate, also Lizenzschlüssel installiert, können gewisse Hardware-Bestandteile zugeschaltet und genutzt werden.

Welche Hardware-Eigenschaften das betreffen wird, ist aktuell noch unklar. Ebenso ist nicht ersichtlich, ob Lizenzen dauerhaft vergeben werden, oder ein Abonnementmodell kommen wird. Letzteres könnte mit Modellen liebäugeln, wie sie sich im Automotive-Bereich bereits abzeichnen. So lässt sich etwa ein Hardware-seitig voll ausgestatteter Tesla nur dann vollumfänglich nutzen, wenn die betreffenden Features freigeschaltet sind. Die Freischaltdauer kann an ein Abo geknüpft sein.

Offene Software auf geschlossener Hardware

Dieses Modell brachte die Gemüter der Linux-Community in Wallung. Open-Source soll der Anwenderin und dem Nutzer volle Transparenz und Kontrolle über das System geben. Mit dem Lizenzmodell à la SDSi ist das grundsätzlich immer noch so. Der nutzbare Umfang ist aber dehnbar.

Wer Linux zudem mit Nachhaltigkeit als Grundgedanken auf älterer Hardware nutzt, steht vor neuen Fragen und Herausforderungen. Wie lange können Features bei älteren Prozessoren zugekauft werden? Wie lange können Abos verlängert werden? Das rüttelt am Open-Source-Weltbild und ruft philosophische Debatten auf den Plan.

So wurde der neue Treiber für SDSi im Vorfeld sowohl in der Community, aber auch im Beiträgen in Fachmedien breit behandelt. Beispielsweise bei LWN, das mit dem Blickwinkel der freien Software auf das Thema schaut. The Register fragt hingegen ganz praktisch, was denn SDSi freischalten werde beziehungsweise was hinter einer "Paywall" stehen wird. Eine konkrete Antwort fand das britische IT-Nachrichtenportal jedoch nicht.

Gegen die Aufnahme des SDSi-Treibers in den Kernel spricht technisch gesehen wenig. Die Funktionsweise des Treibers ist sehr einfach, da auch die Schnittstelle in die Hardware sehr simpel ist. Die philosophische Diskussion wiegt schwerer. SDSi befeuert in der Community die Forderung nach Open-Source-Hardware. Freie Software solle auf freie Hardware.

Auch stellt daher mancher die Frage, ob ein SDSi-Treiber im Linux-Kernel überhaupt etwas zu suchen habe. Das Argument ist aber rein theoretischer und philosophischer Natur. Praktisch gesehen würde ein Rauswurf des SDSi-Treibers das Problem auch nicht lösen. Der Treiber ist so einfach, dass ihn jeder Distributor oder Hardware-Vendor in seinen eigenen Kernel aufnehmen könnte.

Wo die Reise mit dem "Nachkaufen" von Hardware-Features hingeht, ist aktuell unklar. Schließlich hält sich Intel bezüglich der zuschaltbaren Eigenschaften bislang bedeckt. Zudem ist unklar, ob andere Hersteller wie AMD nachziehen. Neu ist das Hardware-Lizenz-Thema auch bei Linux nicht. Auf dem IBM-Mainframe System z ist Linux für s390x mit dem Thema auch konfrontiert. Allerdings zielt Intel in die Heimatarchitektur von Linux, welches auf dem i386 entstand. Zudem läuft das Gros der Linux-Systeme auf den von x86 abgeleiteten Prozessoren. Die Open-Source-Szene hat das als Weckruf verstanden. Das Thema wird die Community abseits des SDSi-Treibers noch länger beschäftigen. Ob es tatsächlich neuen Schwung in die Open-Source-Hardware bringt, wird nicht zuletzt davon abhängen, wie Intels Pläne konkret aussehen.

Hardware-Angriffsschutz

Mit Kernel 5.13 verleibte sich Linux die aus Android stammende Control Flow Integrity (CFI) ein. Damit bietet Linux seither einen guten Software-Schutz gegen das Umlenken des Programmflusses bei indirekten Funktionsaufrufen durch das Manipulieren von Zeigerinhalten wie Rücksprungadressen. Das dahinterstehende Konzept ist reichlich komplex und rein software-basiert. Wie wir bereits zu 5.13 berichteten, wäre eine Unterstützung durch Hardware ideal. Durch den Verzicht auf eine spezielle Hardware ist der CFI-Patch jedoch auf jeder Plattform einsetzbar.

In puncto Hardware-Schutz greift Linux 5.18 das Indirect Branch Tracking (IBT) von Intel auf. Im Vergleich zu CFI ist IBT ein einfacherer, theoretisch auch schwächerer Ansatz. Allerdings ist diese Schutzlösung vollständig in Hardware gegossen. Damit ist es wesentlich performanter als CFI.

IBT führt neue CPU-Befehle endbr32 für 32-Bit und endbr64 für 64-Bit ein. Diese Befehle verhalten sich im Rechenwerk des Prozessors identisch zum noop. Sie führen also keinerlei Operation aus, außer Taktzyklen zu verbrauchen. Der Trick des Konzepts ist, dass der Prozessor bei jedem indirekten Funktionsaufruf erwartet, bei jedem Sprungziel auf genau ein endbr32 oder endbr64 zu treffen. Ist das nicht der Fall, löst das eine Exception aus und der vermutlich manipulierte Programmfluss kommt zum Erliegen.

Bugs mit falsch gesetztem Sprungziel tilgt dieser Mechanismus recht zuverlässig. So ist es statistisch doch eher unwahrscheinlich, dass bei einem falsch gesetztem Zeiger genau an dieser Stelle eine dieser CPU-Instruktionen steht. Ein Angreifer hingegen könnte das ganze Konzept dadurch zu Fall bringen, dass er seinem Sprungziel ein endbr32 beziehungsweise endbr64 voranstellt. Sind doch gerade bei bestimmten Overflow-Angriffen mit noop-Befehlen gepflasterte "Gleitwege" (noop-Sleds, Schlitten) doch ohnehin ein praktikables Mittel. Diese Schlitten mit den neuen Instruktionen anzureichern wäre sicherlich ein zumindest theoretisch gangbarer Weg.

IBT bietet damit weniger Schutz als das ausgefeilte CFI. Es ist aber durch den Hardware-Ansatz schneller und auch als zusätzliches Mittel einsetzbar. Bleibt aber grundsätzlich zunächst auf Intel-Prozessoren beschränkt.

Abstellgleis für ReiserFS

ReiserFS war das erste Journaling-Dateisystem für Linux. Hans Reiser und das Team seiner Firma Namesys hoben es Ende der 1990er aus der Taufe. 2001 floss es in Linux 2.4.1 ein und ist seither fester Bestandteil des Kernels. Bis 2006 war es zudem das Standarddateisystem von SuSE Linux.

Nach der Festnahme von Hans Reiser 2006 und den Mordermittlungen gegen ihn wurde es leiser um das Dateisystem. Nachdem er schließlich den Mord an seiner Frau 2008 nach einem mit der Staatsanwaltschaft geschlossenen Deal gestanden hatte, schwand die Anwenderbasis kontinuierlich. Die Firma Namesys wurde eingemottet. Schließlich hatte Edward Shishkin als ehemaliger Namesys-Mitarbeiter ReiserFS als Maintainer übernommen. Die Pflege des ReiserFS-Codes war damit gesichert, was aber den Anwenderschwund nicht aufhalten konnte.

Zusätzlich ist ReiserFS vom Jahr-2038-Problem betroffen. Im Januar 2038 werden die Zeitstempel im Dateisystem überlaufen und so auf den 1. Januar 1970 zurückspringen. Ein Patch ist bislang nicht in Sicht. Das Dateisystem wurde in Linux 5.18 nun als "deprecated" (veraltet) markiert. Es ist zudem vorgesehen, es 2025 aus dem Mainline-Kernel zu streichen.

Neuere Mainline-Kernel werden ReiserFS-Anwender dann nicht mehr nutzen können. Bei den Langzeit-Kerneln der LTS-Reihe sieht dies anders aus. So wird beispielsweise 5.15, welcher ReiserFS enthält, bis zum Ende seiner Laufzeit (aktuell 2028) das Dateisystem weiter enthalten. Auch LTS-Nachfolger bis 2025 werden ReiserFS enthalten, wenn auch mit dem "deprecated"-Marker. Schließlich ist spätestens bis Ende 2037 anzuraten, ReiserFS auf andere Dateisysteme zu migrieren.

Bei anderen Dateisystemen wie bestimmten Versionen von XFS und ext3 gibt es auch Jahr-2038-anfällige Varianten. Hierfür gibt es aber neuere Dateisystemversionen, die das Problem lösen, wenn auch die Dateisysteme migriert werden müssen. Bei ReiserFS ist es aktuell ungewiss, ob aktualisierte und 2038-taugliche Versionen erscheinen werden. Shishkin arbeitet zwar an ReierFS 5, konnte aber bislang keine bedeutenden Fortschritte erzielen. Es ist aktuell davon auszugehen, dass 2025 mit dem Wegfall von ReiserFS eine Ära leise zu Ende geht.

Probleme mit altem C

Der Linux-Kernel ist ein sehr aktives Projekt ist und lässt Innovationen und Neues schnell einfließen. Dennoch verharrt der Linux-Kernel auf alten Standards und Werkzeugen. So bemängeln Kritiker regelmäßig den Einsatz von E-Mails und Mailing-Listen als antiquierten und ineffizienten Kommunikationsweg. Auch die Wahl bei Standards sei nicht mehr zeitgemäß.

Einen solch alten Zopf schneidet Linux 5.18 jetzt ab. Bislang war das Programmieren nach dem C89-Standard in Kernel-Kreisen Pflicht. Wer neuer Standards nutzen wollte, blitzte mit seinen Patches kurzerhand ab. Danach sah es zunächst auch bei einem Patch von Jakob Koschel aus, als dieser auf das Unverständnis von Linus Torvalds stieß. Koschel hatte eine Unsicherheit identifiziert, die auf ein in C89 nicht lösbares Problem zurückzuführen war.

Beim Fix einer USB-Komponente entdeckte Koschel, dass nach dem Durchlauf einer Schleife über eine verkettete Liste der Kopfzeiger der Liste mit ungültigem Inhalt nachfolgenden Code-Teilen fälschlich zur Verfügung stand. Das liegt schlicht daran, dass in C89 die Laufvariable der Schleife außerhalb der Schleife deklariert werden muss und damit auch nach dem Schleifenblock weiterhin sichtbar ist. Ein klassischer "Leak" der Laufvariablen. Beim Zugriff auf die Variable nach der Schleife kommt es zum Bug. Koschel legte das detailliert dar. Kein noch so ausgefeiltes C-Makro des Kernels in C89 kann diese Situation einfangen, was Torvalds schließlich auch einsah.

Neuer C-Standard

Einzige Abhilfe wäre die Möglichkeit Laufvariablen in der Schleife zu deklarieren, wie es aber erst C-Standards seit C99 zulassen. Außerhalb der Schleife ist die Laufvariable dann nicht mehr sichtbar. Ein Bug, wie der von Koschel bearbeitete, wäre dann schon zur Compile-Zeit aufgefallen und erst gar nicht mehr möglich.

Schließlich wagt Linux 5.18 den Standardsprung. Erstmalig in der Geschichte des Kernel wechselt der C-Standard weg von C89 zu C11. Damit ist fortan der Sprachstandard aus dem Jahr 2011 die Grundlage für die Programmierung des Kernels. Was nach einer Formalie aussieht, ist ein kontrolliertes Wagnis.

Ein anderer Sprachstandard heißt ein anderer oder zumindest veränderter Parser im Compiler. Damit wird anderer Code erzeugt, der womöglich das Laufzeitverhalten von Kernelbestandteilen verändern kann. Nicht zuletzt daher hängt der Kernel an seinem alten Werkzeugkoffer. Nicht wehmütige Nostalgie, sondern praktische Stabilität. Dennoch überwiegen beim neuen C-Standard die Vorteile, wie es Jakob Koschel unwiderlegbar beweist. Ein anderer Sprachstandard kann durchaus Bugs verhindern, indem er die gefährlichen Konstruktionen gar nicht erst zulässt.

Fazit

Der Großteil der akzeptierten Commits und Patch-Sets sind Treiber, Bugfixes und Verbesserungen. Was allerdings als umfangreiches Wartungs-Release erwartet wurde, stellt sich doch als eine kleine Revolution heraus. SDSi hat das Potenzial, den Open-Source-Ansatz unter Druck zu bringen. Zeigt SDSi doch eines deutlich: Die Hardware ist proprietär.

Das Ende von ReiserFS scheint besiegelt zu sein. Einmal mehr zeigt Linux damit, nicht zögerlich mit alten Zöpfen zu sein. Auch der mutige Wechsel zu C11 zeigt Reaktionsfähigkeit. Linux 5.18 mausert sich so vom Wartungsrelease zur bescheidenen Revolution.

Der Kernel 5.18 steht unter kernel.org zum Download bereit. Das ChangeLog mit allen Änderungen findet sich auf der kernel.org-Webseite.

(dmk)