Linux 4.19: Schöner starten und bereit für das WLAN von Morgen

Inhaltsverzeichnis

Der zweitwichtigste Linux-Entwickler Greg Kroah-Hartman hat Montagfrüh den Linux-Kernel 4.19 freigegeben, der über vierzehntausend Änderungen bringt. Einige rüsten neue Features oder Treiber nach, andere verbessern existierende. Die wichtigsten Neuerungen im Kurzüberblick:

Netzwerk

Die neue Linux-Version unterstützt den nächsten, auf 802.11ac (WiFi-5) folgenden WLAN-Standard IEEE 802.11ax (WiFi-6), der WLAN-Übertragungen deutlich beschleunigen soll. Außerdem bringt sie auch gleich Treiber für einen Intel-Chip mit, der diesen Standard nutzt.

Eine längere Bündelung von Netzwerkpaketen verspricht, die Netzwerk-Performance zu verbessern – bislang macht sich allerdings nur ein Netzwerktreiber diesen Trick zunutze.

Der Kernel bringt jetzt Treiber für USB-WLAN-Chips von Mediatek mit, durch die Linux 4.19 jetzt unter anderem die USB-WLAN-Sticks AVM FRITZ! AC 430 und 860 von Haus aus unterstützt.

Treiber

Linux 4.19 enthält einige Änderungen, mit denen Linux-Distributionen den Startprozess verschönern können.

Neu dabei ist ein Grafiktreiber für die von Linus Torvalds ersehnten Notebooks mit ARM-Prozessor von Qualcomm.

Eine Reihe von Systemen mit Thunderbolt-Controller, Radeon-GPUs oder Realtek-Netzwerkchips dürften mit dem neuen Kernel sparsamer laufen, was die Akkulaufzeit mancher Notebooks spürbar steigern sollte.

Unter zahlreichen neuen Treibern sind welche für Apple-Tastaturen, Soundkarten von Creative und zwei Drehregler, die Dell und Microsoft als Eingabegeräte in zwei All-in-one-PCs verbauen.

Das Kernel-Log

Die Artikelserie "Die Neuerungen von Linux" beschreibt regelmäßig die Änderungen neuer Linux-Versionen:

• Linux 5.6 (30. März 2020)
• Linux 5.5 (27. Jan. 2020)
• Linux 5.4 (25. Nov. 2019)
• Linux 5.3 (16. Sep. 2019)
• Linux 5.2 (8. Juli 2019)
• Linux 5.1 (6. Mai 2019)
• Linux 5.0 (4. März 2019)
• Linux 4.20 (24. Dez. 2018)

Storage

Mit einem neuen I/O-Controller soll Linux besser sicherstellen können, dass zeitunkritische Wartungsprogramme die Datenträger nicht so stark fordern, dass es wichtige Programme verlangsamt.

Der gängigste SATA-Treiber nutzt in der Standardkonfiguration jetzt das modernere und performantere Kernel-Framework für Datenträgerzugriffe.

Linux bringt ein neues Polling-Interface für die Nutzung von Asynchronous I/O (AIO) mit.

Der Kernel kann nun auch ältere Stände ("Snapshots") von Samba- oder Windows-Freigaben einbinden.

Sicherheit

In Linux 4.19 kann man flexibler festlegen, wie weit der Kernel dem Zufallszahlengenerator des Prozessors trauen darf.

Der Support für den umstrittenen und von der NSA entwickelten Verschlüsselungsalgorithmus Speck ist noch dabei – allerdings deutet vieles darauf hin, dass er bald rausfliegt.

Auch 32-Bit-x86-Linux kann jetzt vor der zu Jahresanfang bekannt gewordenen Prozessorlücke Meltdown schützen; das klappt allerdings nur, wenn auch PAE-Support aktiv ist.

Die Entwickler haben Schutz vor der Prozessorlücke Spectre v4 eingebaut und jenen für Spectre v2 verbessert.

Verschiedenes

Da sich Linus Torvalds eine Auszeit genommen hatte, leitete Greg Kroah-Hartman die zweite Hälfte der 4.19-Entwicklung. Das ist ein Novum, denn bislang stand der Linux-Erfinder immer selbst am Ruder. Dorthin kehrt er jetzt zurück – wie geplant, denn die Auszeit sollte bis zur Fertigstellung von Linux 4.19 dauern.

Ganz kurz vor Verkündung der Auszeit haben Linus Torvalds und Greg Kroah-Hartman einen neuen Verhaltenskodex für Entwickler etabliert. Direkt vor der Freigabe von Linux 4.19 hat Greg Kroah-Hartman allerdings noch einige Detailänderungen vorgenommen, die diesen Code of Conduct betreffen. Mit ihnen stieß ein längeres Dokument zur Auslegung des Kodex zur Dokumentation. Außerdem wurde damit eine Mediatorin eingesetzt und ein Komitee etabliert, das als Ansprechpartner und Durchsetzungsgremium bei Verstößen dient. Das dürfte einige, aber nicht alle Kritiker verstummen lassen; so oder so sind Diskussionen angesetzt, um weiter über den Kodex zu diskutieren.

Linux 4.19 wird ein Longterm-Kernel und damit nicht nur ungefähr drei Monate, sondern mindestens zwei Jahre gepflegt.

Gut möglich, dass Linux 4.19 die letzte Version der Hauptentwicklungslinie ist, deren Versionsnummer mit "4" beginnt: Torvalds hat in diesem Jahr bereits mehrfach durchblicken lassen, über den Sprung auf 5.0 nachzudenken. Auch ohne solche Hinweise wäre so ein Wechsel wahrscheinlich, schließlich steckt hinter diesen Versionssprüngen keine tiefere Bedeutung oder größere neue Funktionen, aber ein bekanntes Muster. Die Sprünge erfolgen nämlich, damit die letzte Zahl der Versionsnummer nicht zu groß wird. So war es schon beim Übergang von 2.6.39 auf 3.0. Bereits da ließ der Linux-Erfinder durchblicken, er wolle die zweite Zahl in Zukunft nicht wieder so groß werden lassen. Er hielt Wort, denn dem Nachfolger von 3.19 verpasste er die Nummer 4.0. Daher ist es gut möglich, dass jetzt wieder ein Sprung ansteht. Weil der aber nicht sicher ist, sprechen die Kernel-Entwickler bislang noch von Versionsnummer 4.20 und 4.21, wenn sie über Änderungen für die nächsten zwei Kernel-Versionen reden, die letztlich vielleicht 5.0 und 5.1 heißen.

Hintergründe

Die folgenden Artikelseiten liefern zahlreiche Details zu diesen und zahlreichen weiteren Neuerungen von Linux 4.19.

Schöner starten, schneller funken & Strom sparen

Linux schöner starten

Linux 4.19 ermöglicht einen ästhetischen Startprozess, indem es harte, durch Auflösungswechsel oder Statusausgaben erzeugte Brüche zu vermeiden versucht. Letztlich sollen Distributionen damit den Bootprozess ähnlich schick und geschmeidig gestalten können, wie es Mac-User seit langem gewöhnt sind; das Ganze dürfte in der Praxis aber mehr dem Windows-Start via UEFI ähneln.

Den schickeren Start ermöglichen Änderungen, durch die das früh beim Booten initialisierte Framebuffer-Subsystem des Kernels nur dann an der Bildschirmkonfiguration dreht oder irgendwas darstellt, wenn es irgendwelche Informationen auszugeben gibt ("deferred console takeover"). Das sollte nur bei Warnungen oder Fehlern der Fall sein, wenn der Kernel mit der Option quiet startet, wie es bei vielen Distributionen seit Jahren der Fall ist. Stattdessen wird weiter das Logo ausgegeben, das das UEFI-BIOS am Ende des Selbsttests angezeigt hat. Während der Grundinitialisierung des Kernels wird schließlich irgendwann der Grafiktreiber des Kernels geladen, der sich im Idealfall ebenfalls ein Ändern der Bildschirmauflösung spart, wenn das UEFI-BIOS diese schon optimal eingestellt hat; das gelingt derzeit aber nur mit dem Intel-Treiber und einem Patch, den erst in den Nachfolger von 4.19 einfließen soll. Am Ende des Boot-Prozesses soll sich dann auch der Anmeldemanager sanft einblenden können.

Wie so ein geschmeidiger Boot-Prozess aussehen kann, zeigt der Entwickler der Änderungen in einem Video: Nach dem Power-on-Self-Test (POST) des BIOS bleibt das Hersteller-Logo während der Initialisierung der Linux-Distribution stehen, an deren Ende das Bild dann fließend zum Anmeldemanager überblendet. Es ist eines von vier Videos, die der Entwickler im Home-Office mit dem eigenen Smartphone aufgenommen hat. Er arbeitet darauf hin, mit diesen und weiteren Änderungen den Boot-Prozess des im Oktober erwarteten Fedora 29 zu verschönern; daher soll sich der Boot-Manager dort in vielen Fällen standardmäßig nicht zeigen, solange man nicht Shift festhält oder Tasten wie Esc oder F8 drückt. Das Ganze klappt aber nur unter bestimmten Bedingungen, denn neben dem UEFI-BIOS muss auch der Grafiktreiber des Kernels mitspielen. So richtig flutschen dürfte es fürs Erste wohl nur mit modernen Intel-Chips, denn beim für sie zuständigen Treiber haben die Entwickler in den vergangenen Jahren bereits allerlei Vorarbeit geleistet, um einen schickeren Boot-Prozess zu ermöglichen.

Support für schnellere WLANs

Linux 4.19 unterstützt den nächsten WLAN-Standard IEEE 802.11ax, der WLAN-Übertragungen um Faktor vier zu beschleunigen verspricht. Die entsprechenden Änderungen haben Intel-Entwickler beigesteuert. Die haben auch gleich ihren WLAN-Treiber Iwlwifi um Support für eine neue Serie von WLAN-Chips erweitert, die den schnelleren Funkstandard beherrscht. Diese Intel Wireless-AX 22560 genannte Modellreihe will Intel offenbar mittelfristig einführen, wann genau, ist allerdings nicht bekannt.

Durch die frühe Integration in Linux steigt die Chance, dass bei der Produkteinführung aktuelle Linux-Distributionen die WLAN-Chips von Haus aus unterstützen. Nachdem Intel jetzt die Grundlagen zur Unterstützung von 802.11ax im WLAN-Stack (mac80211) und dessen Konfigurationsinterface (cfg80211) gelegt hat, ist es für die Programmierer anderer WLAN-Treiber nun deutlich leichter, Support für den neuen WLAN-Standard zu implementieren.

Treiber für AVM FRITZ! AC 430 und 860

Der neue Kernel unterstützt von Haus aus die USB-WLAN-Sticks AVM FRITZ! AC 430 und 860. Das ist den in Linux 4.19 integrierten Treibern für USB-WLAN-Chips von Mediatek zu verdanken, die zu den Reihen MT76x0U und MT76x2U zählen.

Der Treiber ist unabhängig von Mediatek entstanden. Das Unternehmen hatte selbst quelloffene Treiber freigegeben, aber nicht aktiv gepflegt; sie funktionierten daher nur mit ausgewählten, schon bei der Veröffentlichung veralteten Linux-Kerneln. Daher ließen sie sich unter damals aktuellen Linux-Distributionen nicht oder nur mühsam einsetzen. Offenbar wiesen die Herstellertreiber zudem so viele Qualitätsmängel auf, dass die Programmierer lieber komplett neue Treiber geschrieben haben. Diese unterstützen nicht nur die genannten WLAN-Sticks von AVM, sondern auch von anderen Herstellern produzierte WLAN-Adapter, die der Quellcode der Treiber Mt76x0 und Mt76x2 nennt – darunter der XBox-One-Wireless-Adapter, der Devolo-Wifi-ac-Stick sowie Asus USB-AC50, USB-AC51, USB-AC54 & USB-AC55.

Strom sparen mit Thunderbolt und Realtek-Netzwerkchips

So manch Notebook, PC und Server mit einem Gigabit-Netzwerkchip von Realtek wird mit Linux 4.19 sparsamer laufen. Das ist einigen Änderungen zu verdanken (u.a. 1, 2, 3), durch die der für diese Chips zuständige Treiber R8169 die PCIe-Stromspartechnik ASPM (Active State Power Management) jetzt in vielen Systemen standardmäßig aktiviert. Durch diese können der Chip samt seiner PCIe-Anbindung in sparsamere Modi schalten und im Idealfall sogar weitgehend schlafen gehen, wenn es wenig oder nichts zu tun gibt.

Diese kleine Änderung dürfte auf vielen Systemen mehr Stromsparpotenzial frei werden, als normalerweise zu erwarten wäre: Ein an den Änderungen beteiligter Entwickler hat festgestellt, dass die Intel-Prozessoren mancher mit Realtek-NICs bestückten Systeme nur dann in die tieferen und stromsparenden Schlafzustände (die "Package-C-States") wechselt, wenn ASPM im Netzwerktreiber aktiv ist – offenbar, weil alle anderen Komponenten schon tief genug schlafen, sodass nur der Realtek-Treiber das tiefere Schlafen blockiert.

Beim Gaming-Notebook Dell G3 3779 soll das Sparpotenzial durch die Änderungen beispielsweise bei 3 Watt liegen – ein Wert, durch den sich die Akkulaufzeit des Notebooks spürbar verlängern kann. Solche Realtek-Chip sitzen auch auf vielen Mainboards für Desktop-PCs oder Heimserver, daher können die Änderungen auch dort den Stromverbrauch ein wenig senken. Allerdings bergen sie auch die Gefahr von Problemen, denn die Entwickler hatten die Stromspartechnik bislang bewusst links liegen lassen, weil sie hin und wieder Probleme bereitet. Die Entwickler haben einige der Ursachen aber ausgemerzt; womöglich lauern aber noch weitere in Treibern, Firmware oder Hardware. Wer über solche stolpert, sollte die zuständigen Entwickler darüber informieren, damit diese die Macke aus der Welt schaffen oder umgehen können.

Geringeren Stromverbrauch und somit längere Akkulaufzeit verspricht auch eine Änderung am Thunderbolt-Treiber, durch die er jetzt die zur Laufzeit nutzbaren Stromsparfunktionen unterstützt.

Linux 4.19 wird mindestens zwei Jahre gepflegt

Die neue Linux-Version wird kein Stable-, sondern ein Longterm-Kernel. Die Entwickler versorgen ihn daher nicht nur zirka drei Monate mit kleinen und offensichlich ungefährliche Verbesserungen, sondern mindestens zwei Jahre. Das stellte Greg Kroah-Hartman bereits im August klar, kurz bevor die Hauptentwicklungsphase von 4.19 endete.

Zur selben Zeit veröffentlichte der zweitwichtigste Kernel-Entwickler auch einen ausführlichen Blog-Post zur Frage, welche Geräteklasse man am besten mit welcher Kernel-Linie kombiniert. Die Kurzform: Für die meisten Nutzer sei der Kernel der eingesetzten Distribution der richtige. Wenn stattdessen ein Kernel.org-Linux her soll, empfiehlt Kroah-Hartman für Notebooks und Desktop-PCs jeweils den aktuellen Stable-Kernel. Bis dato war das das Linux 4.18, dessen Pflege allerdings in drei bis vier Wochen enden dürfte, jetzt wo Linux 4.19 erschienen ist.

Auch bei neuen Servern rät Kroah-Hartman zum Stable-Kernel. Er selbst nutzt sie auch auf Servern mit älteren Komponenten, wo auch der jeweils neueste Longterm-Kernel in Frage komme – bis dato war das Linux 4.14. Er rät indes nachdrücklich davon ab, Kernel einer älteren Longterm-Reihe (derzeit etwa 4.4 und 4.9) auf Servern einzusetzen, auf denen man Nutzern, Programmen oder virtuellen Maschinen nicht trauen kann. Das begründet er mit Sicherheitsbedenken: Einige in neue Versionen eingepflegte Sicherheitskorrekturen lassen sich nur nicht ordentlich in derart alte Versionen zurückportieren oder würden dort zu wenig getestet.

Neuer Verhaltenskodex für Entwickler

Heiße Debatten um den "Code of Conduct" für Linux

Für allerlei Gesprächsstoff hat ein neuer Verhaltenskodex gesorgt. Diesen hatte Torvalds vollkommen überraschend kurz vor Veröffentlichung der vierten Vorabversion von Linux 4.19 etabliert, indem er den Text des neuen "Code of Conduct" in die Kernel-Dokumentation integriert hat. Dabei hat er zugleich den im März 2015 eingeführten und weit gefassten "Code of Conflict" entfernt, der die Entwickler aufrief, großartig zueinander zu sein. Dieser Text habe "sein implizites Ziel nicht erreicht", heißt es im Commit-Kommentar.

Der Commit mit dem Kodexwechsel wurde von Greg Kroah-Hartman vorbereitet und von Torvalds signiert und eingepflegt, bevor er direkt im Anschluss ganz überraschend eine Auszeit von der Entwicklung auf der Liste der Kernel-Hacker verkündete. Die Änderung hatten die zwei offenbar weitgehend im stillen Kämmerlein ausgeheckt; zu den wenigen Entwicklern, die in einem kleinen Zeitfenster kurzfristig Stellung beziehen konnten, zählten die zehn Mitglieder des Technical Advisory Board (TAB) der Linux Foundation, das der Kodex anfangs als Durchsetzungsgremium nannte.

Einführung ohne vorheriges Review

Der Codex hatte somit keine Begutachtungsphase auf einem öffentlichen Mailverteiler. Ein solches Review durchlaufen nicht nur die größeren, sondern auch die meisten trivialen Änderungen am Linux-Kernel: Das gilt als Eckpfeiler des Entwicklungsprozesses, denn es gibt anderen Programmierern und interessierten Parteien die Chance, vorab Probleme aufzuzeigen.

Die schnelle Integration ohne Review wurde unter anderem von Entwicklern kritisiert, die das Subsystem des Kernels betreuen. Sie sind besonders betroffen: Sie müssen sich beim Begutachten von Patches nicht nur an den Kodex halten, sondern auch auf seine Einhaltung in ihrem Umfeld achten – beispielsweise den Mailverteilern ihres Subsystems. Anfang Oktober haben unter anderem die beiden langjährigen und wichtigen Entwickler James Bottomley (1, 2, 3) und Geert Uytterhoeven (1, 2, 3) einige Änderungen am Text des Kodex vorgeschlagen. Kroah-Hartman, der Torvalds während seiner Auszeit als Leiter der Linux-Entwicklung vertritt, hat dazu nicht näher Stellung bezogen; darüber hinaus sind sich auch die Entwickler nicht einig, ob die vorgeschlagenen Änderungen sinnvoll sind oder nicht.

Anpassungen direkt vor Fertigstellung

Greg Kroah-Hartman hat sich in die Diskussionen zwar nicht eingeschaltet, sich dem Thema zu der Zeit aber bereits gewidmet. Das zeigte sich kurz vor der Freigabe von Linux 4.19, als er sieben Änderungen zur Diskussion stellte, die den Verhaltenskodex betreffen; diese sind dann direkt vor der Veröffentlichung von Linux 4.19 integriert und damit etabliert worden (1, 2, 3, 4, 5, 6, 7).

Durch die Änderungen gibt es etwa neue Ansprechpartner, an die sich Leute wenden können, wenn sie den Kodex verletzt sehen: Diese Aufgabe übernimmt ein "Code of Conduct Committee", das gerade gegründet wird. Derzeit besteht es aus Freiwilligen des Technical Advisory Board (TAB), das anfangs als Ansprechpartner und Durchsetzungsgremium genannt war. Durch die Änderung wird auch eine Mediatorin etabliert, die im Zweifel vermitteln soll. Diesen Job übernimmt Mishi Choudhary. Sie ist Legal Director beim Software Freedom Law Center (SFLC) und hat sich darüber hinaus für Zivilrecht im Internet sowohl in den USA als auch in Indien eingesetzt.

Ferner wurde mit den Änderungen ein längeres Dokument hinzugefügt, das bei der Interpretation und praktische Auslegung des Code of Conduct helfen soll. Dieses Dokument wurde von Linus Torvalds und Dutzenden anderen Entwicklern vorab gesehen und abgenickt, wie die vielen "Acked-by" im Commit-Kommentar zeigen; auch die anderen Änderungen am oder rund um den Verhaltenskodex wurden von einer Reihe von Entwicklern vorab gutgeheißen. Diese Anpassungen scheinen manche Kritiker zufriedenzustellen. Einige Entwickler zeigten sich weiter unzufrieden; darunter der frühere MD-Software-RAID-Maintainer Neil Brown oder Alan Cox, der vor rund fünfzehn Jahren als zweitwichtigster Kernel-Entwickler galt. Wahrscheinlich kommen noch andere Punkte auf, daher dürfte es in den kommenden Wochen noch weitere Diskussionen rund um den Verhaltenskodex geben.

Erste Diskussionen stehen gleich nach der am 22. Oktober erfolgten Freigabe von Linux 4.19 an, denn an dem Tag beginnt der diesjährige Maintainers Summit – das diesmal in Edinburgh stattfindende Treffen, auf dem einige der wichtigsten Kernel-Entwickler zusammenkommen, um mit Torvalds über Aspekte bei der Kernel-Entwicklung zu reden. Die Diskussion zum Code of Conduct steht ganz oben auf der Tagesordnung – genau wie für andere Punkte der Agenda sind allerdings auch für diesen nur 30 Minuten vorgesehen.

Gerüchte um Rückbauforderungen

Nebenbei: Im Rahmen der Diskussionen um den Kodex kursierten Meldungen, Kernel-Entwickler hätten aufgrund des Verhaltenkodex verlangt, dass von ihnen beigesteuerter Code entfernt würde. Tatsächlich hat aber niemand so etwas öffentlich gefordert, der Änderungen zu Linux beigetragen hat. Nach Auffassung von Software Freedom Conservancy und einigen anderen im Open-Source-Bereich tätigen Juristen wären solche Bestrebungen ohnehin nicht mit der GPLv2 durchsetzbar, der Linux untersteht. Außerdem enthält der bei der Kernel-Entwicklung verwendete Prozess sogar eine Regel, damit solche Forderungen in Leere laufen. Wie immer sind das aber nur Regeln und Vorkehrungen, über die im Streitfall letztlich Gerichte entscheiden.

Storage: bessere Datenträger-Regulierung und SMB-Snapshot-Support

Ressourcenverbrauch von Datenträgern anders regulieren

Mit dem neuen I/O-Controller "Blk-Iolatency" sollen Admins besser sicherstellen können, dass Datenträgerzugriffe weniger wichtiger Software (etwa die Systemaktualisierung) die kritischeren Server-Anwendungen nicht zu stark verlangsamen. Der neue Mechanismus soll sogar vor Situationen bewahren können, in denen vernachlässigbare Aufgaben die Systemlast so hoch treiben, dass sich das System komplett festfährt.

Das Ganze soll mit minimalen I/O-Latenzen gelingen, die Admins über den neuen I/O-Controller für Control Croups (Cgroup) festlegen können. Fortan behält der Kernel ein Auge auf die Lese- und Schreibanforderungen des Systems und ermittelt den Durchschnitt der I/O-Operationen, den Programme der mit Cgroups definierten Prozessgruppen erzielen. Sollte dieser Wert den konfigurierten übersteigen, drosselt der Kernel die Operationen von Programmen, die in Cgroups mit weniger hohen Latenzanforderungen stecken; dadurch sollen Ressourcen frei werden, damit die wichtigeren Anwendungen nach Möglichkeit wieder innerhalb der gesetzten Latenz zum Zuge kommen. Notfalls beendet der Controller weniger wichtige Anwendungen sogar, um die Vorgaben zu erreichen. Das Ganze klappt sogar bei indirekt entstehenden Datenträgeroperationen – beispielsweise, wenn eine weniger wichtige Anwendung viel Arbeitsspeicher fordert und das System so verlangsamt, weil es Arbeitsspeicher auslagern muss (Swapping).

Der Ansatz stammt von Facebook-Mitarbeitern. Ihnen zufolge hat sich der Controller in den Rechenzentren des Social-Media-Dienstes bewährt, wo er Abstürze verhindert, Schwankungen in der Antwortzeit reduziert und die Zahl der pro Sekunde erfüllten Aufgaben gesteigert hat. Details zum Ansatz liefert ein LWN.net-Artikel; weitere Hintergründe und Hinweise zum praktischen Einsatz liefern die Dokumentation zum neuen Controller und Commits wie blkcg: add generic throttling mechanism, block: introduce blk-iolatency io controller und block: make iolatency avg_lat exponentially decay.

Snapshots von SMB-Freigaben einhängen

Das zum Einbinden von Samba- oder Windows-Freigaben genutzte CIFS bietet jetzt Snaphot-Unterstützung. In Kombination mit einer neuen Version der Werkzeugsammlung Cifs-Utils lassen sich so mit dem Mount-Parameter "snapshots=" ältere Dateisystemstände schreibgeschützt mounten, sofern der Server solche denn exportiert; aktuelle Samba-Versionen beherrscht das via vfs_shadow_copy2.

Unter den weiteren Änderungen an CIFS waren welche, die ein Bündeln mehrere Anfragen (Compounding) verbessern, was die Abfrage von Dateieigenschaften (Name, Größe, Attribute, …) per statfs() um 40 Prozent verbessern soll. Außerdem lässt sich der CIFS-Support jetzt auch so übersetzen, dass er veraltete und bekanntermaßen unsichere Protokollstandards wie CIFS/SMB 1.0 nicht mehr unterstützt.

Zweiter Versuch: Multiqueue-Support für AHCI & Co.

Beim Erstellen einer neuen Konfiguration zum Bau eines Linux-Kernels wird der Multiqueue-Support im SCSI-Subsystem jetzt standardmäßig aktiviert; das hat auch Auswirkungen auf SATA-Treiber wie AHCI, die auf dem SCSI-Support aufbauen. Durch den Multiqueue-Support können solche Treiber die modernere Infrastruktur des Block-Layers nutzen, die mit mehreren Warteschlangen arbeitet. Dieser Multi-Queue Block IO Queueing Mechanism (Blk-Mq) wurde vor einigen Jahren geschaffen, um das Leistungspotenzial der damals schnellsten PCIe-SSDs ausschöpfen zu können. Aber auch SSDs und Festplatten für Desktop-PCs, Notebooks oder einfache Server können von der moderneren Infrastruktur profitieren; zudem funktionieren modernere Storage-I/O-Scheduler wie das bei Linux 4.12 integrierte BFQ (Budget Fair Queueing) nur mit Datenträgern, bei denen der Treiber die Multiqueue-Unterstützung des Block-Layers nutzt.

Bereits vor rund einem Jahr hatten die Kernel-Entwickler versucht, den Multiqueue-Support im SCSI-Subsystem standardmäßig zu aktivieren. Bei einigen Nutzern führte das aber zu Problemen beim Wechsel in oder aus dem Bereitschaftsmodus (Suspend/Resume); außerdem traten eine Reihe von Performance-Probleme zutage. Die Entwickler haben die Änderungen daher rückgängig gemacht und sind die Schwierigkeiten angegangen, um jetzt einen zweiten Anlauf zu wagen.

Zweiter Versuch: Weiteres API zur Abfrage asynchroner I/O-Operationen

Zu Abfragen des Fortschritts bei Asynchronen I/O (AIO) steht jetzt das neue Polling-Interface IOCB_CMD_POLL bereit. Die verwendete Programmierschnittstelle wurde von einem API abgeleitet, das Red Hat Advanced Server (RHAS) 2.1 und Red Hat Enterprise Linux (RHEL) 3 bereits vor knapp fünfzehn Jahren genutzt haben. Das neue API zur Abfrage entstand im Auftrag von Scylla, deren Entwickler es offenbar bei ihrer NoSQL-Datenbank verwenden wollen. Das bei LWN.net näher erläuterte Interface war vor zwei Monaten bereits für Linux 4.18 integriert worden, flog aber wieder raus, nachdem Torvalds einige problematische Eigenschaften fand; der Programmierer der Erweiterung hat daraufhin einen neuen und noch dazu kompakteren Ansatz entwickelt.

Btrfs, Ext4 & XFS

Unter den wichtigsten Änderungen an Btrfs war eine, durch die sich nun prinzipiell beschreibbare Dateien defragmentieren lassen, solange Anwendungen diese gerade nur lesend geöffnet haben.

Die Ext4-Entwickler planen schon für das nächste Jahrhundert: Sie haben ein für Inode-Zeitstempel verwendetes Datenfeld vergrößert, das sonst im Jahr 2106 an seine Grenze gelangen und überlaufen würde. Zwischen dem Hauptschwung an Ext4-Änderungen stecken zudem zahlreiche Patches, die bislang im Wiki des Dateisystems gepflegte Hintergrundinformationen in die Kernel-Dokumentation überführen; Letzte enthält dadurch jetzt einen umfangreichen und tiefen Einblick in Design und Funktionsweise des Dateisystems.

Unter den wichtigsten Änderungen an XFS (1, 2) waren neben Optimierungen einige weitere Funktionen, um XFS-Dateisysteme zukünftig im Betrieb prüfen und reparieren zu können.

Neues Nur-Lesen-Dateisystem und Aufräumarbeiten

Linux bringt jetzt auch Support für das Enhanced Read-Only File System (EROFS) mit (u.a. Kconfig-Update, Todo-Datei, On-disk layout). Laut den Entwicklern ist es ein leichtgewichtiges Nur-Lesen-Dateisystem, das etwa für Live-CDs oder den Firmware-Speicher von Mobilgeräten gedacht ist. Der von Huawei eingebrachte Dateisystemcode erfüllt allerdings die Qualitätsstandards der Kernel-Entwickler nicht. Er landete daher im Staging-Bereich, der für Code gedacht ist, den jemand im Rahmen der normalen Kernel-Entwicklungsprozesse auf Vordermann gebracht werden soll. Diese Hoffnung geht immer mal wieder nicht auf. Dann fliegt der Code sang- und klanglos wieder raus, denn beim Staging-Bereich gelten Sonderregeln, die das explizit erlauben. Mit anderen Funktionen des Kernels (Dateisystemen, Treibern, …) passiert das nicht, solange Anwender sich darauf verlassen: Das wäre eine Regression, gegen die Linus Torvalds strikt vorgeht, wenn er davon hört.

Über den Modul-Parameter metacopy=on kann man das Overlay-Dateisystem (OVL) jetzt anweisen, sich das Hochkopieren von Dateiinhalten in die oberste Dateisystemschicht zu sparen, wenn lediglich Dateiattribute mit Programmen wie chown oder chmod verändert werden. Das Überlagerungsdateisystem kann mit der standardmäßig inaktive Funktion so Overhead vermeiden, was die Performance verbessert.

Zwischen den Änderungen am Block Layer war auch ein Patch, der Unterstützung für asynchrone Zugriffe auf SCSI-Geräte via BSG-Interface entfernt: Dieser Zugriffsweg weist bekannte Schwachstellen auf und wird offenbar ohnehin von niemandem verwendet, wie ein LWN.net-Artikel zum Thema erläutert.

Einige weitere Änderungen rund um Storage-Support nennen die Commit-Kommentare der wichtigsten Merges bei den Subsystemen ATA, Ceph, Device Mapper (DM), MD, MTD, Libnvdimm (MISC, Memory Failure) und SCSI.

Die wesentlichen Neuerungen bei bislang nicht genannten Kernel-Dateisystemen finden sich in wichtigsten Merge-Commits der Subsysteme F2FS, GFS2, NFS, NFSd, OVL aka OverlayFS und UBI/UBIFS.

Mehr Netzwerk-Performance und Treiber für AVM FRITZ! AC 430 & 860

Bündel länger zusammenhalten, um Performance zu steigern

Sofern der Kernel die Netzwerkpakete gebündelt bei der Netzwerkhardware abruft, kann er diese jetzt länger als solches zusammenhalten, wenn der Netzwerkstack mit der Verarbeitung beginnt. Das verbessert die Netzwerk-Performance, weil es Overhead zu Beginn der Paketverarbeitung vermeidet und Prozessor-Caches besser greifen.

Der für das längere Zusammenhalten der Pakete zuständige Code stammt von einem Solarflare-Mitarbeiter, der den für Netzwerkchips des Unternehmens zuständigen Treiber Sfc auch gleich erweitert hat, damit der das Verfahren nutzt. Andere Treiber verwenden es bislang nicht: Deren Entwickler sind sich noch uneins, ob die Vorteile den Implementierungsaufwand wert sind. Es muss sich daher noch zeigen, ob andere Treiber den Ansatz aufgreifen.

Die Idee hinter der Optimierung ist ohnehin alt, denn die hatte der Entwickler bereits 2016 vorgestellt. Damals fand der Ansatz noch weniger Anklang bei den anderen Entwicklern. Das hat sich unter anderem durch die Maßnahmen gegen die Prozessor-Sicherheitslücke Spectre v2 geändert, denn die haben Overhead mit sich gebracht, den die längere Bündelung wieder deutlich reduziert. Details und Testergebnisse nennt ein Merge-Commit-Kommentar zum neuen Ansatz und der LWN.net-Artikel "Batch processing of network packets".

Verkehrssteuerung gegen DoS-Attacken und lange Latenzen

Kürzere Latenzen bei Internet-Anbindungen sowie eine bessere, störungsfreie Koexistenz von durchsatz- und latzenzsensitiven Übertragungen verspricht "Common Applications Kept Enhanced (CAKE)". Dabei handelt es sich um eine neue Queuing Discipline (Qdisc) zur Steuerung des Netzwerkverkehrs via tc (Traffic Control).

Der neue Netzwerk-Scheduler zielt auf Internet-Provider ab und soll Probleme auf Anwenderseite beseitigen, die durch zu starkes Puffern von Paketen in den Zwischenstationen entstehen; solche Schwierigkeiten sind unter dem Oberbegriff "Bufferbloat" bekannt, gegen das eine Reihe von Entwicklern seit Jahren an vielen Fronten ankämpft. Details zum Ansatz des neuen Scheduling-Verfahrens finden sich in einem Commit-Kommentar zu CAKE, dem LWN.net-Artikel "Let them run CAKE", einer Webseite zu CAKE und einem Paper, das auch Testergebnisse nennt. Die Dokumentation zu CAKE findet sich im Entwicklerzweig von Iproute2, in dem die Version 4.19 vorbereitet wird und wie gewohnt kurz nach Freigabe des Kernels mit eben dieser Versionsnummer erscheinen dürfte.

Ebenfalls neu ist die Qdisc SKB Priority Queue (Skbprio): Dieser Scheduler soll bei der Abwehr von DoS-Attacken helfen, indem er Pakete geringerer Priorität fallen lässt, damit mehr der wichtigeren durchkommen. Die zugehörige Dokumentation steckt im Entwicklerzweig von Iproute2.

Tunnel, Realtime, Bufferbloat, TLS und einiges mehr

Der auf "Virtual Ethernet Tunnel" aufsetzende Treiber Veth hat XDP-Unterstützung erhalten, was Overhead beim Einsatz der Netzwerkschnellstraße reduziert und die Performance steigert. Laut dem Commit-Kommentar zum XDP-Support in Veth haben die Entwickler die Änderung vorgenommen, um Container besser zu vernetzen, XDP-Programme hintereinander zu hängen oder eine interne Netzwerkschnittstelle an eine XDP-Bridge einzuklinken.

Anwendungen können den Kernel nun über die neue setsockopt()-Option SO_TXTIME anweisen, die darüber verschickten Netzwerkpakete nicht möglichst zügig, sondern später innerhalb eines bestimmten Zeitfensters zu verschicken. Das ist vor allem für Realtime-Anwendungen gedacht, damit die den richtigen Moment zum Verschicken nicht mehr selbst anpassen brauchen. Außerdem müssen sie nicht mehr fürchten, dass ihre Pakete womöglich zu spät rausgehen, weil zufällig parallel eine andere Anwendung das Netzwerkinterface stark belastet. Details zum Ganzen finden sich im Merge Commit zu "Scheduled packet Transmission/ETF" und dem LWN.net-Artikel "Time-based packet transmission".

Der Kernel kann das Entschlüsseln von TLS (Transport Layer Security) jetzt an Netzwerkchips delegieren, die diese Aufgabe beherrschen. Das gelingt durch eine Erweiterung der Kernel-eigenen TLS-Unterstützung (Kernel TLS/KTLS), die bei Linux 4.13 eingeführt und jüngst bei 4.17 und 4.18 erweitert wurde. Der Netzwerktreiber muss die Hardware-seitige TLS-Entschlüsselung aber auch beherrschen, was bislang nur bei Mlx5 der Fall ist.

Eine Reihe weiterer Neuerungen nennt der Kommentar des Git-Merges, der den Hauptschwung der Änderungen am Netzwerkstack enthalten hat. Darunter ist etwa noch eine Backup-Port-Funktion im Bridge-Code oder das "Virtual XFRM Interface", das Verbindungen tunnelt und dabei einige Schwierigkeiten von anderen Tunnel-Ansätzen wie Virtual Tunnel Interfaces (VTI) vermeiden soll; XFRM soll etwa zuverlässig sicherstellen, dass über die virtuelle Netzwerkschnittstelle geroutete Pakete zuverlässig fallengelassen werden, falls es mit dem Tunnel irgendwo hakt.

Sicherheit: NSA-Algorithmus, Meltdown-Schutz für 32-Bit-x86 & Spectre v4

Speck noch dabei, Rauswurf aber absehbar

Auch Linux 4.19 unterstützt den umstrittene Speck. Support für diesen von der NSA entwickelten Verschlüsselungsalgorithmus hatten Google-Entwickler zu Linux 4.17 beigesteuert; bei 4.18 rüsteten sie dann noch Speck-Support in Fscrypt nach, weil sie Speck bei Android nutzen wollten. Noch vor Fertigstellung von 4.18 gaben die Entwickler aber überraschend bekannt, dass Google diese Pläne verworfen hat.

Bereits kurz darauf kursierten Patches, um die Speck-Unterstützung wieder komplett zu entfernen. Diese zogen schließlich am 5. September (und damit nach Ende der heißen Entwicklungsphase von 4.19) in "Linux-Next" ein – den Entwicklerzweig, in dem die Programmierer die Änderungen für die jeweils übernächste Version (zu der Zeit also den Nachfolger von 4.19) aufeinander abstimmen.

Manche Patches ziehen nach einer einige Tage dauernden Testphase in linux-next auch noch in den Hauptentwicklungszweig von Linux (und damit die gerade vorbereitete Version, also 4.19) ein, wenn der jeweils zuständige Subsystementwickler das für angebracht hält. Dazu kam es aber nicht – die Patches werden daher wohl in den Nachfolger von 4.19 einfließen, der wahrscheinlich die Versionsnummer 5.0 bekommt und zum Jahreswechsel erscheinen dürfte. Laut Kennzeichnung soll der Patch aber zurückportiert werden. Daher fliegt Speck womöglich beim Stable-Zweig im Rahmen der 4.19.x-Versionspflege doch noch raus.

Meltdown-Schutz für 32-Bit-x86-Systeme – aber nur manche

Linux 4.19 bringt endlich Maßnahmen, mit der für 32-Bit-x86-Prozessoren (aka x86-32) übersetzte Kernel vor der Prozessorsicherheitslücke "Meltdown" schützen können. Für 64-Bit-x86-CPUs (aka x86-64) übersetzte Linux-Kernel können das schon seit Anfang 2018, als die vornehmlich Intel-CPUs betreffende Lücke bekannt wurde. Das ist der Technik Page Table Isolation (PTI) zu verdanken, die zuerst in Linux 4.15 eingeflossen ist.

Ein Kernel-Entwickler hat PTI im Frühjahr auf die x86-32-Architektur portiert und seine Patches dann mehrfach verbessert, weil er selbst oder andere Entwickler beim Begutachten Verbesserungswürdiges gefunden haben. Das ist kein Wunder, denn für PTI waren größere Umbauten am ohnehin schon komplizierten Code zum Speichermanagement nötig. Das ist einer der Gründe, warum es so lange gedauert hat. Ein anderer: Heute dreht sich in der x86-Welt fast alles um 64-Bit-Prozessoren, daher steht der 32-Bit-Support bei Distributoren, Entwicklern und Testern mittlerweile recht weit unten auf der Prioritätenliste. Vermutlich stünde er sogar noch tiefer, wenn er nicht die ersten zwei Jahrzehnte der Linux-Geschichte im Fokus der Entwicklung gestanden hätte. Schließlich ist Linux für solche Prozessoren entstanden und mit ihnen groß geworden.

Besser 64-Bit-Kernel zum Meltdown-Schutz?

Beim PTI für x86-32-Systeme gibt es indes eine Stolperfalle: Erst während der 4.19-Entwicklung fiel auf, dass der Schutz nur bei Kernel-Images funktioniert, die mit Support für PAE übersetzt wurden. 32-Bit-Distributionen, die ausschließlich auf einen Kernel ohne PAE-Support setzen, werden daher auch in Zukunft nicht vor Meltdown schützen können. Anwender von Linux Mint oder Ubuntu brauchen sich darum aber nicht zu sorgen: Bei deren 32-Bit-x86-Kernel ist die Kernel-Bau-Option "CONFIG_HIGHMEM64G" aktiv, die PAE aktiviert. Einige x86-32-Distributionen liefern auch zwei Kernel aus: Einen mit und einen ohne PAE-Support. Wer einen von Meltdown betroffenen Prozessor nutzt und sich vor der Lücke schützen will, sollte daher den mit PAE verwenden und sicherstellen, dass PTI dort aktiv ist.

Auch Anwender, die eine 32-Bit-x86-Distribution auf Systemen mit 64-Bit-x86-Prozessor einsetzen, sollten aufpassen: Anders als 64-Bit-Kernel kann PTI bei 32-Bit-Kerneln keine Process-Context Identifier" (PCID) nutzen. Dabei handelt es sich um eine Funktion, mit der Linux den Overhead von PTI bei Intel-Prozessoren seit der Haswell-Generation (Core-i-4000 und neuer) erheblich reduzieren kann. Für bestmögliche Performance trotz Meltdown-Schutz sollten Anwender daher eine 64-Bit-Distribution nutzen oder ihr 32-Bit-Userland mit einem 64-Bit-Kernel koppeln. Ein 32-Bit-Linux mit PTI weist mit einer deutlichen Warnung auf diesen Aspekt hin; das kann auch unabhängig davon Interessant sein, denn ein 64-Bit-Kernel bietet auch andere Vorteile.

Gegenmaßnahmen für Spectre v4

Der Entwicklerzweig, in dem Torvalds & Co. den Kernel 4.19 vorbereitet haben, war das erste Linux der Kernel.org-Entwickler, das Gegenmaßnahmen für die Prozessorsicherheitslücke Spectre v4 erhielt. Diese hat Linus Torvalds genau zu der Zeit integriert, als die Entdecker und Intel die Lücke bekannt gegeben haben. Bereits kurz darauf haben die Entwickler dann Schutzfunktionen auf Basis des 4.19er-Codes in die Linux-Kernel 4.18.1, 4.17.15, 4.14.63, 4.9.120 und 4.4.148 zurückportiert. Diese erschienen knapp vierundzwanzig Stunden nach Veröffentlichung der Lücke, die auch als Foreshadow oder L1 Terminal Fault (L1TF) bekannt ist.

Bei all diesen und neueren Linux-Versionen kann man das Verhalten der Gegenmaßnahmen über den neuen Kernel-Parameter l1tf= beeinflussen. Standardmäßig nutzt der Kernel einige Schutztechniken, die es in einer Virtual Machine (VM) laufenden Betriebssysteme unmöglich machen, per L1TF die Speicherinhalte des Hosts auszulesen. Diese Maßnahmen reduzieren die Performance manchen Workloads mit VMs aber um 15 bis 50 Prozent. Wer das beim Einsatz vermeiden will, kann die Gegenmaßnahmen über einen Kernel-Parameter lahmlegen – das kann für Systeme interessant sein, bei denen in den VMs garantiert nur vertrauenswürdige Software läuft.

Zu einem noch größeren Performance-Einbruch führt eine weitere Schutzfunktion, die HyperThreading komplett lahmlegt. Diese Gegenmaßnahme ist allerdings standardmäßig inaktiv, denn sie würde auch Systeme treffen, auf denen gar keine VMs laufen. Ohnehin ist sie vornehmlich für Cloud-Anbieter wichtig, deren Kunden eigene Betriebssysteme oder Kernel in den VMs einsetzen können: Ein Nutzer könnte sonst einen Aspekt der Spectre-v4-Problematik nutzen, um Daten von VMs anderer Kunden abzugreifen, die der gleiche CPU-Kern gerade mit HyperThreading parallel ausführt.

Im Rahmen dieser Anpassungen hat der Kernel den Parameter nosmt gelernt, der HyperThreading deaktiviert. Weitere Hintergründe zum Ganzen finden sich in der heise-online-Meldung zum Linux-Schutz vor der Prozessorlücke L1TF und einem Dokument der Linux-Entwickler.

Spectre v2, Performance-Problem-Vermeidung & neue Schutzfunkton

Als Gegenmaßnahme vor der Prozessorsicherheitslücke Spectre v2 unterstützt der Kernel jetzt die Funktion "Enhanced IBRS". Diese soll laut Intel in zukünftigen Intel-CPUs stecken und umfassender schützen als der derzeit typischerweise verwendete Spectre-v2-Schutz Retpoline.

Über den Kernel-Parameter hardened_usercopy= lässt sich jetzt eine intensivere Prüfung der Regionen beim Datenaustausch zwischen Kernel- und Userspace deaktivieren. Linux 4.8 und neuer unterstützen diese Technik, die in bestimmten Stationen einen größeren Performance-Einfluss hat – laut Commit-Kommentar unter anderem bei der Verarbeitung von UDP-Netzwerkpaketen, bei denen der zuständige Entwickler bei einen Test einen Geschwindigkeitsgewinn von acht Prozent erzielen konnte, indem er Hardened Usercopy deaktivierte.

Eine in Linux 4.19 neue Schutzfunktion soll es Angreifern erschweren, Programme durch Tricks dazu zu bringen, in Dateien oder Named Pipes (FIFOs) zu schreiben, die in beschreibbaren Verzeichnissen mit Sticky-Bit liegen. Die Technik ist aus dem "HARDEN_FIFO" genannten Schutz hervorgegangen, den Openwall schon eine Weile nutzt. Der Commit-Kommentar erwähnt die CVE-Bezeichner von acht in den vergangen Jahren bekannt gewordenen Sicherheitslücken, die die neue Maßnahme hätte unterbinden können. Aus Kompatibilitätsgründen ist sie aber standardmäßig inaktiv und muss über die Sysctl protected_fifos und protected_regular eingeschaltet werden.

Einige weitere wichtige Änderungen rund um Sicherheit nennen die Commit-Kommentaren der wichtigsten Merges in den Subsystemen Audit, Crypto, Integrity, Security, SELinux und TPM.

Infrastruktur: Vertrauensfrage, Speicherknappheit & neue Anforderungen

Zufallszahlengeneratoren von CPUs vertrauen oder nicht?

Beim Bau eines Kernel-Images kann man jetzt über eine Option festlegen, ob der Kernel-eigene Zufallszahlengenerator bei der Initialisierung auch Daten einbeziehen darf, die Zufallszahlengeneratoren moderner Hauptprozessoren liefern. Aber egal, wie die CONFIG_RANDOM_TRUST_CPU genannte Option auch gesetzt ist: Über den neuen Kernel-Parameter random.trust_cpu= können Sie diesen Aspekt jetzt auch beim Booten beeinflussen.

Die Änderungen rund um die Initialisierung des Congruential Random Number Generator (CRNG) von Linux entstanden im Rahmen von Diskussionen, die LWN.net im Artikel "Initializing the entropy pool using RDRAND and friends" näher erläutert. Auslöser war die Vorstellung des Patches mit der Build-Option, durch den der Kernel bei der Initialisierung den Zufallszahlengenerator des Hauptprozessors einbeziehen kann: Das vermeidet Wartezeiten beim Booten und soll die Qualität der früh im Startprozess zur Verfügung stehenden Zufallszahlen verbessern. Letzteres klingt nach einem unwichtigen Detailproblem, hat aber gerade im Embedded-Umfeld schon mehrfach zu Schwierigkeiten geführt – etwa weil Zufallszahlen bei der Generierung des OpenSSH-Host-Keys nicht so zufällig waren, wie gedacht. Nach Veröffentlichung des Patches meldeten sich allerdings Stimmen, die den Zufallszahlengenerator von CPUs misstrauen und sich daher gegen eine standardmäßige Einbeziehung über Befehle wie RDRAND aussprachen. Letztlich führte das zur Entwicklung des Patches, der den Boot-Parameter nachrüstet. Durch das Ganze legt für die meisten Anwender in Zukunft der Distributor fest, ob der Kernel den Zufallszahlengeneratoren von CPUs jetzt traut oder nicht.

Bei Speicherknappheit besser reagieren

Beim Memory-Controller für Cgroup v2 kann man über memory.oom.group jetzt festlegen, dass der Out Of Memory (OOM) Killer alle Prozesse einer Control Group als Einheit betrachten soll. Das ist etwa relevant, wenn er bei extremer Speicherknappheit einen oder mehrere Prozesse abzuschießen erwägt, damit sich das System nicht festfährt. Sollte er sich für eine so konfigurierte Gruppe entscheiden, beendet er alle darin enthaltenen Prozesse.

Admins können so erreichen, dass der Kernel zuerst unwichtigere Prozesse schließt, wenn der Arbeitsspeicher zur Neige geht. Die dahinter stehende Änderung war ein Teil größerer und bei LWN.net erläuterter Umbauten, um das Verhalten des seit Jahren immer wieder modifizierten OOM Killers besser steuern zu können. Andere Teile dieser Umbauten mussten aber erstmal außen vor bleiben: Die an diesem Bereich arbeitenden Entwickler sind sich bei einigen der Ansätze noch uneins.

Code anpassen und entfernen, statt Einbindung zu monieren

Linus Torvalds hatte die Nase voll von Compiler-Warnungen zu Codestellen, die als "deprecated" (alt/überholt/missbilligt) gekennzeichnete Funktionen eingebunden haben. Er hat daher die Möglichkeit komplett entfernt, Funktionen so auszuzeichnen. Entwickler sollen stattdessen die Codestellen anpassen, die von ihnen abgekanzelte Funktionen nutzen, um Letztere dann rauszuwerfen. Genau das geht bei Linux vergleichsweise leicht, weil alle wesentlichen Treiber in den Kernel-Quellen stecken und daher an einer Stelle zu finden sind.

Neuerer Compiler erforderlich

Zum Kernel-Bau mit der GNU Compiler Collection (GCC) ist jetzt mindestens die GCC-Version 4.6 erforderlich, die im Frühjahr 2011 erschien. Laut Dokumentation reichte bislang die GCC 3.2 – die Realität hatte diese Angabe aber schon eine Weile überholt, denn mit den Vorgängern vor 4.6 traten Fehler beim Kompilieren auf.

Weitere Neuerungen rund um die Infrastruktur nennen die wichtigsten Commits der Subsysteme ACPI (1, 2), Documentation, Kbuild (1, 2), IDA, Kconfig, Locking, Modules, MMC, RCU, Perf (1, 2), Power Management, (1, 2), Printk, Schedular, Siginfo, Tracing, Timer, Virtio.

Cache-Sperren, Unicode und Pinebook

Linux 4.19 unterstützt die "Cache Pseudo-Locking"-Funktion von Intels "Cache Allocation Technology" (CAT). Anwendungen können darüber einen Teil des Prozessor-Caches für Daten reservieren, damit der Prozessor sie für schnelle Zugriffe dort dauerhaft vorhält. Details hierzu finden sich in den Änderungen an der CAT-Dokumentation (1, 2, 3, 4).

Der Kernel ist jetzt im Unicode-Zeitalter angekommen: Arnd Bergmann hat ein Dutzend in den Quellen enthaltene Dateien in UTF-8 konvertiert, die zuvor in ISO_8859-1 kodierten Text enthielten.

Linux unterstützt jetzt das Raspberry Pi Compute Module samt dessen IO Board.

Ebenfalls neu: Support für das Pinebook, einem mit 64-Bit-ARM-Kern ausgestatteten "Open Source Notebooks" der Macher des Entwicklerboards Pine64.

Weitere Änderungen rund um Architektur-Unterstützung und Support zentraler Systemkomponenten nennen die wichtigsten Commits der Bereiche ARM (SoC, SoC Defconfig, SoC Driver, SoC Device Trees (DT), SoC [nachzügler]), ARM32, ARM64, Clocks, Devicetree, DMA Engine, DMA Mapping, EFI, GPIO, IOMMU, IRQ, I2C, KVM (1, 2), M68k, Mailbox, MFD, Microblaze, MIPS (1, 2), Parisc (1, 2), PCI, Pinctl, PowerPC (1, 2), Power-Suppy, PWM, Regulator, RISC-V (1, 2), Rproc, RTC, SPI, S390 (1, 2), SoC Thermal, x86 (Cache, CPU, Hyper-V, Timers), Xen und Xtensa.

Treiber: Neuer Qualcom-Grafiktreiber & Support für Drehregler von MS und Dell

Grafiktreiber für Qualcomms Notebook-Prozessor

Der Linux-Kernel unterstützt jetzt die Grafikeinheit des Qualcomm-Prozessors Snapdragon 845 (SDM845). Dieser ist unter anderem für einige mit Windows ausgelieferten ARM-Notebooks gedacht, die mit modernen AMD- und Intel-Notebooks zu konkurrieren versuchen. Erste Erweiterungen zum Support dieses SoC (System-on-Chip) waren bereits in Linux 4.18 eingeflossen, was Linus Torvalds interessiert hat aufhorchen lassen: Der Linux-Erfinder hofft schon länger auf Notebooks mit ARM-Prozessoren, die eine halbwegs mit x86-Geräten vergleichbare Leistung liefern und zugleich ordentlich von Linux unterstützt werden.

Das die Mobile Display Sub System (MDSS) genannte Grafik des Snapdragon 845 unterstützt wird, ist zum Einen einigen Erweiterungen zu verdanken, durch die der Kernel-Treiber MSM jetzt auch Qualcomm-Adreno-Grafikprozessoren der 600er-Reihe unterstützt. Dieser Treiber gehört zur Grafiktreiberfamilie Freedreno, zu der auch ein auf dem Kernel-Treiber aufsetzender OpenGL-Treiber in Mesa gehört, mit dem sich die 3D-Beschleunigung nutzen lässt. Dieser wird die Adreno-6xx-GPUs bald unterstützen, denn die dazu nötigen Erweiterungen sind jüngst in den Entwicklerzweig der Grafikbibliothek und 3D-Treibersammlung eingeflossen, aus dem im November oder Dezember die Version 18.3 hervorgehen dürfte.

Zum Anderen ist der Kernel-Support für die Snapdragon-845-GPU einer größeren Erweiterung zu verdanken, durch die der MSM-Treiber auch die anderen Komponenten der Grafikeinheit dieses SoCs unterstützt. Das ist nötig, weil sich Adreno-GPUs mit unterschiedlichen IP-Cores kombinieren lassen, die sich um Ausgabe des Gesamtbildes oder die Ansteuerung von Displays kümmern.

Neben dem Grafiktreiber gab es auch noch andere Verbesserungen, um die Unterstützung für den Snapdragon 845 zu verbessern – darunter etwa ein Soundtreiber für den SDM845.

Stromsparen bei Radeon, Support für Intels Icelake

Manche Systeme mit AMDs Radeon-Grafikprozessoren dürften mit dem neuen Kernel im Leerlauf weniger Strom verbrauchen. Das ist mehreren Schwüngen von Änderungen zu verdanken, durch die AMDs Treiber Amdgpu die zur Laufzeit nutzbaren Stromsparfunktionen bei verschiedenen Radon-GPU-Generationen und Konfigurationsvarianten jetzt besser unterstützt.

Einige Verbesserungen am Treiber Amdkfd sorgen dafür, dass sich AMDs GPGPU-Lösung ROCm nun auch mit Prozessoren der Raven-Generation verwenden lässt.

Nach einigen Vorarbeiten bei vorangegangenen Kernel-Versionen unterstützt Intels Grafiktreiber i915 nun die GPU einer neuen Generation von Mobil- und Desktop-Prozessoren, die den Codenamen Icelake trägt.

Neu dabei ist der "Virtual KMS Driver" Vkms. Er emuliert Geräte, wie sie Kernel-Grafiktreiber für echte GPUs bereitstellen, damit Kernel, X-Server, Wayland Compositor und Anwendungen darüber Bilder ausgeben können. Derzeit ist der Treiber vor allem für Testzwecke ausgelegt; laut einem der Entwickler sind aber Erweiterungen angedacht, um aus der Ferne die Grafikausgaben von Servern abzugreifen, die "Headless" laufen und daher keine Grafikausgabe ermöglichen.

Eine Reihe weitere Neuerungen an Grafiktreibern nennt der Kommentar eines Git-Merges, der den Hauptschwung der Änderungen enthielt, die für 4.19 an Grafiktreibern vorgenommen wurden. Einige weitere Neuerungen nennt der Git-Merge zu den wichtigsten Änderungen am Framebuffer-Support.

Noch mehr neue und verbesserte Treiber

Es gab noch zahlreiche weitere Änderungen und neue Treiber, die den Hardware-Support verbessern. Sie alle hier aufzuzählen würde den Rahmen sprengen, daher hier nur einige exemplarisch.

Apple-Magic-Keyboards lassen sich jetzt nicht mehr nur via USB, sondern nun auch per Bluetooth anbinden. Außerdem unterstützt Linux jetzt auch Magic-Keyboards mit Nummernblock.

Der Kernel weiß jetzt auch die PCIe-Soundkarte Creative Sound Blaster Recon3D anzusprechen.

Dank eines neuen Treibers kann der Kernel jetzt bei den verschiedenen Ausführungen des Rasbperry Pi warnen, wenn die Versorgungsspannung zu weit absinkt ("undervoltage").

Der Treiber Wiimote unterstützt jetzt Nintendo-Wii-Controller der Guitar-Hero-Klasse.

Neu dabei ist auch Support für das Cougar 500k Gaming Keyboard.

Der Kernel hat ein eigenes, GNSS genanntes Subsystem für GPS-Empfänger bekommen, auf den die kurz darauf integrierten Treiber für Empfänger von SiRFstar und U-blox aufbauen.

Das Industrial I/O (IIO) Subsystem bringt jetzt einen Treiber für den Bosch-Sensor BME680 mit, der Temperatur, Luftdruck, Feuchtigkeit und eine Reihe von Gasen überwacht, um die Luftqualität zu prüfen.

Die Eingabegerätetreiber unterstützten jetzt auch die Surface Dial beziehungsweise Totem genannten Drehregler von All-in-One-PCs, die Microsoft beim Surface Studio und Dell beim Canvas 27 einsetzt. Die Entwickler arbeiten aber noch daran, diese Eingabegeräte in Desktop-Oberflächen und Anwendungen sinnvoll zu unterstützten,

Der USB-Typ-C-Support des Kernels kann bei von ihm unterstützten Chips jetzt die Alternate Modes von Typ-C-Anschlüssen konfigurieren. Durch diesen lassen sich neben den USB- beispielsweise auch DisplayPort-Signale über das USB-Typ-C-Kabel transportieren. So lassen sich über ein Kabel etwa USB-Port-Replikatoren anbinden, an denen USB-Eingabegeräte und ein Monitor hängen. Für viele moderne PCs und Notebooks ist der Kernel-seitige Support aber nicht sonderlich von Bedeutung: Alternate Modes funktionieren dort schon seit einer ganzen Weile, weil normalerweise die Firmware alles Wesentliche selbst regelt. Die neuen Kernel-Funktionen sind vorwiegend für Embedded-Hardware gedacht, wo der Kernel diese Aufgaben selbst erledigen muss.

Von Google stammt das neue Framework Gasket (Google ASIC Software, Kernel Extensions, and Tools), das Hardware-Support über einen zweistufigen Treiber ermöglicht: Einige Kernfunktionen zum Hardware-Zugriff erledigt ein simpler Gasket-Treiber, auf den ein Userspace-Treiber aufbaut, der alles andere regelt. Das Ganze bietet so ähnliches wie UIO (Userspace I/O), soll sich aber nicht so gut für einen Einsatzzweck eignen, den Google im Sinn hat. Offenbar geht es um die Anbindung von Beschleuniger-Prozessoren, denn zusammen mit dem Framework stieß ein darauf aufbauender Treiber für einen "Apex" genannten Chip zum Kernel, dessen Einsatzgebiet aber nicht näher erläutert wird. Dieser Treiber und das Gasket-Framework erfüllen indes die Qualitätsansprüche der Kernel-Entwickler nicht, daher landeten beide auch nur im Staging-Bereich, für den Sonderregeln gelten – dort gilt etwa die "Keine Regressionen"-Regel nicht, daher verschwinden Staging-Treiber manchmal oder ändern sich auf inkompatible Weise.

Viele weitere wichtige Neuerungen bei Treibern nennen die Kommentare der wichtigsten Merges bei den Subsystemen Backlight, Char, Driver Core, Input, Human Interface Devices (HID), LEDs, Media, Platform, RDMA, Sound, Staging (1, 2), TTY, USB und Watchdog. Durch diese und zahlreiche andere hier unerwähnte Verbesserungen unterstützt die neue Linux-Version über 400 Geräte oder Geräteklassen mehr als die Vorversion; bei rund 110 davon handelt es sich um PCI/PCIe- oder USB-Geräte, wie die Datenbanken der Linux Kernel Driver DataBase (LKDDb) zeigen. Ähnlich wie bei vorangegangenen Versionen bringt die neue Linux-Version den Hardware-Support so wieder einen signifikanten Schritt vorwärts.

Daten und Zahlen; Artikel-Changelog

Daten und Zahlen zu den jüngsten Versionen des Linux-Kernels

Kernel- Version	Anzahl Dateien¹	Zeilen Quelltext (Ohne Doku)²	Entwick- lungs- zeitraum	Commits (Ohne Merges)³	Diffstat⁴
Linux 4.11	57.994	23.137.402 (21.132.076)	70 Tage	13.891 (12.724)	12.528 files changed,  550.108 insertions(+),  252.364 deletions(-)
Linux 4.12	59.845	24.170.860 (22.125.075)	63 Tage	15.736 (14.570)	12.531 files changed,  1.342.677 insertions(+),  309.204 deletions(-)
Linux 4.13	60.582	24.767.008 (22.698.219)	63 Tage	14.150 (13.006)	10.898 files changed,  878.431 insertions(+),  282.283 deletions(-)
Linux 4.14	61.290	25.041.284 (23.050.486)	70 Tage	14.659 (13.452)	23.388 files changed,  719.862 insertions(+),  445.585 deletions(-)
Linux 4.15	62.303	25.364.802 (23.329.451)	77 Tage	16.223 (14.866)	13.265 files changed,  643.912 insertions(+),  320.289 deletions(-)
Linux 4.16	62.915	25.558.805 (23.495.643)	63 Tage	14.896 (13.630)	12.239 files changed,  1.133.069 insertions(+),  939.066 deletions(-)
Linux 4.17	61.362	25.379.564 (23.314.368)	63 Tage	14.745 (13.541)	14.504 files changed,  777.301 insertions(+),  956.941 deletions(-)
Linux 4.18	61.003	25.280.872 (23.183.236)	70 Tage	14.432 (13.283)	13.141 files changed,  583.336 insertions(+),  682.028 deletions(-)
Linux 4.19	61.734	25.588.455 (23.449.221)	70 Tage	15.204 (14.043)	11,693 files changed,  552.223 insertions(+),  244.235 deletions(-)
¹ git ls-tree -r --name-only HEAD | wc -l ² find . -type f -not -regex '\./\.git/.*' | xargs cat | wc -l; echo "($(find . -name *.[hcS] -not -regex '\./\.git/.*' | xargs cat | wc -l))" ³ git-log --pretty=oneline vx.(y-1)..vx.(y) | wc -l; echo "($(git-log --pretty=oneline --no-merges vx.(y-1)..vx.(y) | wc -l))" ⁴ git diff --shortstat vx.(y-1)..vx.(y)

Mehr Infos

Versionshistorie dieses Artikels

Der obige Text wird zwischen Freigabe der ersten Vorabversion und Fertigstellung von Linux 4.19 mehrfach erweitert, um schrittweise alle wichtigen Änderungen der neuen Kernel-Version zu erläutern. Einmal publizierte Absätze ändern oder erweitern wir nur, falls triftigen Gründe das erfordern. Zur Freigabe des neuen Linux stellen wir den Text allerdings um, damit Informationen zu den wichtigsten Neuerungen am Anfang stehen.

• 2018-10-22, 10:30 – v2.0: Umbau zur Freigabe von Linux 4.19; dabei drei Absätze zu den in letzter Minute erfolgten Änderungen rund um den Verhaltenskodex eingebaut (dritte Seite, Zwischenüberschrift "Anpassungen direkt vor Fertigstellung") und den umgebenden Text etwas darauf abgestimmt. Außerdem erwähnt, dass 4.19 einer Longterm-Kernel wird und das Linus die Entwicklung wieder übernimmt.
  
• 2018-10-17, 06:30 – v1.4: Details zum Code of Conduct und Neuerungen bei Architektur & Infrastruktur hinzugefügt.
  
• 2018-10-08, 06:30 – v1.3: Verbesserungen rund um Sicherheit erwähnt.
  
• 2018-09-24, 06:30 – v1.2: Änderungen bei Treibern erläutert.
  
• 2018-09-11, 06:30 – v1.1: Die wichtigsten Änderungen beim Netzwerksubsystem beschrieben.
  
• 2018-08-27, 06:45 – v1.0: Erste Version, die sich auf die Neuerungen rund um die Datenspeicherung konzentriert.

Der Newsticker von heise online erwähnt alle größeren Texterweiterungen, auf die auch der Twitter-Account @kernellog hinweist.

(thl)