Linux 5.5 freigegeben: Wireguard-Fundament und Performance-Verbesserungen

Inhaltsverzeichnis

Zum Start der letzten Arbeitswoche im Januar hat Linus Torvalds die Linux-Version 5.5 freigegeben. Wie jede neue Version der Hauptentwicklungslinie bringt auch die neueste weit über zehntausend Änderungen. Einige rüsten neue Features nach, andere verbessern existierende. Die wichtigsten dieser Verbesserungen im Kurzüberblick, bevor der Text in die Details geht:

• Der neue Kernel bringt endlich Krypto-Funktionen für Wireguard, gegen die sich die Entwickler lange gesperrt haben. Support für die Furore machende VPN-Technik folgt mit an Sicherheit grenzender Wahrscheinlichkeit dann Ende März oder Anfang April erwarteten Kernel

• Linux 5.5 bringt einige Umbauten am Btrfs-Dateisystem mit, die dessen Performance verbessern und Unterstützung für neue RAID-1-Verfahren nachrüsten.

• Linux 5.5 läuft endlich auch auf dem neuesten Raspberry-Pi-Modell – zwar noch unrund, aber das soll sich bald bessern.

• Durch Verbesserungen beim Live Patching wird es leichter, Sicherheitslücken in Kernel-Code zu beheben, der bereits zuvor im Betrieb erheblich modifiziert wurde.

• Ein neuer Load-Balancing-Algorithmus verteilt die Arbeit anders auf die Prozessorkerne und versucht so, mehr Geschwindigkeit herauszuholen.

• Die Virtualisierung mit KVM soll dank Optimierungen an Geschwindigkeit zulegen.

• Der neue Kernel kann weitere Firewall- und Routing-Arbeiten an Netzwerkchips delegieren und hebelt nebenbei auch eine kneifende Namensbeschränkung bei Netzwerkgeräten aus.

• Umbauten bei der BPF Virtual Machine steigern dessen Geschwindigkeit und öffnen weitere Anwendungsgebiete.

• Ein riesiger Haufen neuer und überarbeiteter Treiber verbessert den Hardware-Support signifikant. Durch die Umbauten wird jetzt etwa die neue Radeon RX 5600 unterstützt. Bei den Sunxi-SoCs einiger bekannter Einplatinencomputern lässt sich nun der H.265-Decoder verwenden. Ein Realtek-WLAN-Treiber liefert bessere Performance. Außerdem gab es gleich bei mehreren Treibern kleinere Änderungen, die bei Notebooks auf etwas längere Akkulaufzeiten hoffen lassen. All das ist aber nur die sprichwörtliche Spitze des Eisbergs von Treiberneuerungen.

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)

• Einige Optimierungen am Netzwerkcode versprechen, die Performance in WLANs und bei der Kommunikation mit Virtual Machines (VMs) zu verbessern. Auch Multichannel-Support bei CIFS, das Samba- und Windows-Freigaben ins Dateisystem einhängt, soll die Geschwindigkeit steigern.

• Die Kernel-Entwickler haben einen weiteren Mechanismus integriert, um persistente Speichermodule wie Intels Optane DC Persistent Memory einzubinden.

• Einen Sicherheitsgewinn verspricht eine Infrastruktur, die eine alte x86-Technik zur Hardware-Ansteuerung emuliert.

Die folgenden Seiten liefern zahlreiche weitere Details zu diesen Neuerungen von Linux 5.5 und erläutern darüber hinaus noch zahlreiche weitere. Die letzte Artikelseite enthält zudem einen kleinen Ausblick auf die Änderungen, die Linux 5.6 bringen dürfte, das Ende März oder Anfang April erscheinen dürfte.

Wireguard in Sicht, neue Btrfs-RAID-Modi und Raspi-4-Support

Wireguard-Aufnahme am Horizont

Das für Ende Januar oder Anfang Februar erwartete Linux 5.5 macht den Weg für die VPN-Technik Wireguard frei, die seit rund zwei Jahren viel von sich reden macht. Der Wireguard-Support selbst wird diesem Kernel zwar noch fehlen – er bringt aber eine "Frankenzinc" genannte Krypto-Infrastruktur mit, die eine lange festgefahrene Situation endlich löst und so den Weg zur Aufnahme endlich frei macht.

Wireguard setzt bislang auf ein eigens für diese VPN-Technik entwickeltes Krypto-API namens "Zinc" auf. Zinc missfiel den Betreuern des Krypto-Subsystems von Linux allerdings von Anfang an, daher haben sie dessen Integration schon 2018 abgelehnt – und damit indirekt auch die Integration des eigentlichen Wireguard-Codes geblockt.

Ende September 2019 stellte schließlich ein erfahrener Kernel-Krypto-Entwickler überraschend einen neuen Ansatz vor. Er übernimmt Teile des Codes von Zinc, geht an einigen Stellen aber anders vor, um die die Vorstellungen der Betreuer des Krypto-Subsystems besser zu erfüllen. Durch diesen Mix erhielten die Änderungen etwas scherzhaft eine Bezeichnung, die auf Frankensteins Monster anspielt.

Frankenzinc erwies sich als ein für alle Beteiligten akzeptabler Mittelweg, der allerdings erst kurz vor Beginn der Hauptentwicklungsphase von 5.5 abgenickt wurde – letztlich zu knapp, um auch noch den eigentlichen Wireguard-Code zu begutachten, der ins Netzwerksubsystem muss. Bei diesem mittlerweile durchgeführten Review tauchte nichts Kritisches auf, daher haben die Entwickler ihn bereits zur Aufnahme in die folgende Version bereitgelegt. Damit wird Linux 5.6, das Mitte April kurz vor der Freigabe von Ubuntu 20.04 LTS und Fedora 32 erscheinen dürfte, die VPN-Technik mit an Sicherheit grenzender Wahrscheinlichkeit von Haus aus unterstützen.

Neue RAID-1- und Hash-Algorithmen bei Btrfs

Der Btrfs-Code beherrscht jetzt zwei weitere RAID-1-Varianten. Anders als der bisherige Algorithmus legt er die Daten nicht nur zweimal ab, sondern drei- oder vierfach redundant. Diese "raid1c3" und "raid1c4" genannten Spielarten brauchen daher mindestens drei respektive vier Datenträger. Sie sind zum Ablegen der Metadaten bei Btrfs-Volumes gedacht, die Nutzdaten mit RAID 5 oder 6 speichern: Sie sollen die Chancen auf Datenrettung verbessern, wenn bei einem RAID 5 mehr als ein Datenträger gleichzeitig ausfällt oder bei einem RAID 6 mehr als zwei.

Btrfs stehen fortan drei weitere kryptografische Hash-Funktionen zur Verfügung, die die Absicherung verbessern oder den Prozessor weniger belasten: SHA256, xxhash64 und Blake2b. Letzteres ist ein für 64-Bit-CPUs ausgelegter Algorithmus, den das Krypto-Subsystem ab Linux 5.5 beherrscht; das hat auch das verwandte Blake2s gelernt, das für 8-, 16- und 32-Bit-Plattformen ausgelegt ist. Beide Blake-Varianten sind optimierte Fassungen des Hash-Algorithmus Blake, der beim SHA-3-Wettbewerb im Rennen war, aber den Kürzeren zog.

Wie bei nachträglich eingeführten Dateisystem-Features generell üblich, können ältere Linux-Kernel keine Btrfs-Volumes einbinden, die nur von neueren Versionen unterstützte Features nutzen. Deswegen muss man solche Funktionen mit Dateisystemtools manuell aktivieren oder ihre Verwendung implizit oder explizit beim Formatieren erlauben. Im Falle er neuen RAID- und Hash-Funktionen erfordert das mindestens die Anfang Dezember veröffentlichten Btrfs-Progs 5.4.

Mehr Infos

Dies war ein schrittweise aktualisierter Artikel

Dieser Text wurde mehrfach erweitert, um nach und nach alle wesentlichen Änderungen in Linux 5.5 zu beschreiben. Zur am 27. Januar erfolgten Freigabe dieser Kernel-Version haben wir die Erzählreihenfolge verändert und Abschnitte zu wichtigeren Neuerungen an den Anfang gestellt. Von nun an behält der Text seine jetzige Form. Details zur Versionshistorie des Artikels finden Sie am Artikelende.

USB4-Support in Vorbereitung

Der neue Kernel hat bereits viele Änderungen zur Handhabung von USB4 erhalten (u. a. 1, 2, 3, 4, 5, 6, 7, 8, 9). Der Rest zur Unterstützung des aus Thunderbolt 3 hervorgegangenen Verbindungsstandards soll bei Linux 5.6 folgen. Apropos Thunderbolt 3: Der Software Connection Manager unterstützt die Technik jetzt. Das ist derzeit vor allem für Apple-Systeme wichtig, denn da kann sich die Firmware nicht um das Verbindungsmanagement kümmern, wie das bei PCs typischerweise der Fall ist.

Einige Umbauten an Audio- und USB-Treibern versprechen die Leistungsaufnahme einiger moderner Notebooks ein klein wenig zu senken und so die Akkulaufzeit zu verlängern. Zu diesen Änderungen zählen etwa einige Patches rund um die HDMI-Audio-Codecs-Treiber für AMD-Prozessoren (1, 2, 3, 4). Systeme mit Intels aktuellen Prozessoren profitieren durch einen Anpassung beim XHCI-Treiber .

Raspi-4-Support langsam im Werden

Linux 5.5 bringt endlich Basis-Support für den Raspberry Pi 4 (u. a. 1, 2, 3, 4, 5, 6, 7, 8, 9). Außerdem stieß auch ein Treiber für dessen Gigabit-Ethernet-Controller dazu.

Das ist für Projekte wie Fedora und Debian wichtig, die mit einem oder sehr wenigen Kernel-Images möglichst viele verschiedene Systeme und Einsatzgebiete abdecken wollen – idealerweise ein Kernel-Image pro Architektur, und ohne den Linux-Quellcode dazu groß modifizieren zu müssen.

Ein Treiber für den PCIe-Controller des populären Kleincomputers kam indes zu spät für 5.5, daher ist auch der darüber angebundene USB-Controller vorerst unerreichbar. Das ist einer von mehreren Gründen, warum der offizielle Kernel den neuesten Raspi vorerst deutlich schlechter unterstützt als der heftig modifizierte Linux-Kernel der Raspberry-Pi-Foundation, den Distributionen wie Raspbian mitliefern. Viele der dort vorgenommenen Modifikationen können aber nicht auf die Schnelle in den offiziellen Linux-Kernel umziehen, weil der Code den Qualitätsansprüchen der Kernel.org-Entwickler nicht gerecht wird – vielfach nicht einmal ansatzweise.

Verbesserungen für Qualität und Live-Patching

Live-Patching wird flexibler

Mit Linux 5.5 wird es leichter, einen bereits mit Kernel Live Patching (KLP) zur Laufzeit veränderten Kernel abermals im Betrieb zu modifizieren. Das ist "System State Tracking" zu verdanken, durch das der Kernel selbst Buch über bereits vorgenommene Änderungen führt. Entwickler können mit diesen Informationen komplexere und verwobene Live-Patches erstellen. Das erleichtert es deutlich, Sicherheitslücken in Code-Bereichen zur Laufzeit zu flicken, die bereits ein anderer Live-Patch zuvor modifiziert hat. Das gilt umso mehr, wenn der ältere Live-Patch dazu auch Datenstrukturen in nicht-abwärtskompatibler Weise angepasst hat (u. a. 1, 2, Dokumentation).

Arbeitsverteilung grundrenoviert

Der Prozess-Scheduler nutzt beim Verteilen der Arbeit auf die Prozessorkerne jetzt einen grundlegend neuen Ansatz, der zeitgemäßer vorgeht und die Performance mancher Workloads zu verbessern verspricht (u. a. 1, [2, 3, 4, 5, 6). Der neue Load-Balancing-Code verhält sich allerdings etwas anders, daher ist er in einigen Situationen besser, in manchen aber vielleicht auch schlechter. Daher gab es Befürchtungen, dass der Ansatz nochmal überarbeitet werden muss. Da bislang keine größeren Probleme an die Kernel-Entwickler herangetragen wurden, spricht mittlerweile viel dafür, dass der Code verbleibt, aber in nächster Zeit noch Feintuning erhält.

Der Kernel bietet über den Systemaufruf clone3() jetzt einen zuverlässigeren Weg, um neuen Prozessen eine bestimmte Process ID (PID) zuzuweisen. Das ist vor allem zum Wiederanlaufenlassen von Programmen wichtig, die mit CRIU (Checkpoint/Restore In Userspace) eingefroren wurden. Genau für diesen Einsatzweck ist auch der Time Namespace hilfreich, der bei Linux 5.6 folgen soll und verhindern kann, dass Anwendungen beim Aufwachen einen Zeitsprung bemerken.

Die Kernel-Entwickler haben den Systemaufruf sysctl() entfernt – augenscheinlich nutzt den keiner mehr, da sich darüber einstellbare Konfigurationsoptionen seit vielen Jahren auch via /proc/ setzen lassen.

Kernel-Code durchtesten

Das schon länger in Linux enthaltene Coverage-Testing-Framework "Kcov" ermöglicht Fuzzing-Programmen nun Einblicke in Hintergrund-Threads des Kernels. Das Testprogramm Syzkaller, das schon hunderte sicherheitsrelevante Fehler in Linux und anderen Betriebssystemen aufgespürt hat, konnte durch diese Kcov-Erweiterung eine Reihe von Fehlern im USB-Code von Linux finden, die bereits korrigiert wurden.

Der Linux-Quellcode enthält jetzt das "Kunit" genannte Framework, über das Entwickler ihren Kernel-Code mit Unit Tests auf korrekte Funktion prüfen können. Der End-to-End-Testing ermöglichende Ansatz macht sich User Mode Linux (UML) zunutze, mit dem sich ein Linux-Kernel wie ein normaler Prozess unter einem anderen Linux-Kernel starten lässt (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11). Weitere Details zur Funktionsweise und den Einsatzmöglichkeiten liefern die Kunit-Dokumentation und der "LWN.net-Artikel "A kernel unit-testing framework". Noch weiter in die Tiefe gehen die Vortragsfolien und die Videoaufzeichnung eines im September auf der Linux Plumbers Conference (LPC) 2019 gehaltenen Vortrags:

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Rüsten fürs Jahr-2038 und Kernel anders installieren

Viel Feinschliff erhielten die Änderungen, um das Jahr-2038-Problem (Y2K38) auf 32-Bit-Systemen zu vermeiden (1, 2). Dadurch kann man jetzt auch testweise Systemaufrufe deaktivieren, die bekanntermaßen einen zu kleinen Zeitstempel enthalten. Das führt dann zu Laufzeitfehlern, über die Entwickler zuverlässig die Programme aufspüren können, die noch nicht Jahr-2038-fest sind; diese müssen sie dann anpassen, um die alternativen, in den letzten zwei bis drei Jahren geschaffenen Systemaufrufe zu nutzen, die einen größeren Zeitstempel verstehen.

Dank eines neuen Make-Target kann man einen gebauten Kernel jetzt per make dir-pkg leicht in ein temporäres Verzeichnis installieren. Das ist für Anwender gedacht, die dieses Verzeichnis dann per scp, rsync & Co. auf einen anderen Rechner übertragen wollen, für den der neu gebaute Kernel gedacht ist.

Die Kernel-Dokumentation beschreibt über die neuen "Maintainer Entry Profiles" jetzt Eigenarten, die bei der Entwicklung für einige Subsysteme des Kernels wichtig sein können.

Wie immer gab es viele kleine Performance-Optimierungen am Memory-Management-Code, die wir hier nur anreißen. Ein Entwickler hat etwa eine lediglich vierzeilige Änderung vorgenommen, durch die sich die Zeit zum Kompilieren eines Kernels bei seinem Multicore-System von zirka 2:50 Minuten auf 2:40 reduzierte.

Kleine, nette Verbesserungen bei Analyse- und Messwerkzeugen

Unter zahlreichen Änderungen an der Infrastruktur von Perf und dem Performance-Analyse-Tool selbst war etwa eine Erweiterung von perf diff, durch die das Werkzeug die Standardabweichung mit einer UTF8-Balkengrafik anzeigen kann. Viele weitere Neuerungen bei Perf nennen einige Sub-Git-Merges (1, 2, 3, 4, 5, 6).

Auch bei Ftrace gab es wieder allerlei Neues (1, 2) – darunter etwa Verbesserungen, um Ftrace zuverlässig innerhalb des Kernels nutzen zu können.

Details zu diesen und weitere Änderungen an der allgemeinen Infrastruktur von Linux nennen die wichtigsten Git-Pull-Requests der Bereiche ACPI, Apparmor, Cgroup, Crypto, Device Properties, Documentation, IOMMU, Kbuild, Kgdb, Kselftests, Livepatches, Locking, Modules, Power Management, Printk, RCU (Core), Seccomp, SELinux, Threads, TPM und TTY.

Multichannel-Support bei CIFS und NVMe-SSD-Temperaturen

Performance

Das CIFS-Dateisystem, mit dem sich Verzeichnisfreigaben von Samba- und Windows-Servern einbinden lassen, kann dank Multichannel-Support jetzt mehrere Verbindungen parallel zu Servern aufbauen, um so Performance und/oder Ausfallsicherheit zu verbessern (u. a. 1, 2, 3). Unter den anderen Änderungen am CIFS war Support für den Syscall flock(), mit dem man Advisory Locks bei Dateien setzen kann.

In den Anpassungen am NFS-Client-Code steckt Code, um Kopien von einem NFS-Server auf einen anderen zu veranlassen, bei dem die Server die Daten direkt austauschen (u. a. 1, 2); das entlastet Client-System und Netzwerk, weil es die Übertragung vom Quellserver über den Client zum Zielserver vermeidet. Eigentlich hätte der im Kernel enthaltene NFS-Server-Code (NFSd) erweitert werden sollen, um diese auch "Inter SSC Copy" oder "Server-to-Server Copy Offload" genannte Funktion ebenfalls zu unterstützen – aufgrund eines Missverständnisses blieb der Code allerdings außen vor und soll erst bei 5.6 folgen.

Ext4 nutzt für XFS entstandenen Code

Um Zuverlässigkeit, Performance und Wartbarkeit zu verbessern, nutzt Ext4 jetzt für Direct I/O die bei XFS bereits bewährte Iomap-Infrastruktur, wenn Anwendungen den Datenträger unter Umgehung des Page Cache ansprechen wollen. Die Verwendung des XFS-Codes ist jetzt möglich, denn die XFS-Entwickler haben ihren Iomap-Code separiert, damit andere Dateisysteme diese nutzen können und vergleichbaren Code nicht selbst entwickeln müssen.

Unter den weiteren Änderungen am Ext4-Dateisystem ist die Möglichkeit, die dateisystemeigene Verschlüsselung auch bei Blockgrößen verwenden zu können, die kleiner als eine Arbeitsspeicherseite (Page) sind.

Im bei Linux 5.4 integrierten exFAT-Code gab es einige Aufräumarbeiten; parallel schreitet die Entwicklung und Begutachtung einer neueren Code-Basis zur Unterstützung des Dateisystems von Microsoft weiter voran.

Einige weitere Neuerungen rund um vom Linux-Kernel unterstützte Dateisysteme nennen die Merge-Commits von EROFS, F2FS, Fsverity, GFS2, XFS sowie Ext2/Quota/Reiserfs.

Weiterer Mechanismus für persistente Speichermodule

Der neue Hmem-Treiber bringt einen weiteren Weg, nicht-flüchtige Arbeitsspeichermodule wie Intels Optane DC Persistent Memory zu verwenden. Über den Treiber lassen sich die Speicherbereiche solcher Module ansprechen, wenn das System diese als "High Bandwidth Memory Pool" konfiguriert, wie es bei EFI 2.8 in der ACPI-Spezifikation definiert wurde. Linux nutzt diesen Bereiche dann nicht als RAM, kann sie über den Hmem-Treiber aber gezielt einzelnen Anwendungen zur Verfügung stellen, die sie via DAX (Direct Access) explizit einbinden müssen.

NVMe-SSD-Temperatur, Asynchrones I/O & NVMe-Problem

Der Kernel liest jetzt die Temperatur von NVMe-Datenträgern aus und stellt sie so bereit, dass Programme wie sensors den Wert ausgeben.

IO-Uring erhielt allerlei Feinschliff, um die Performance des jüngst bei Linux 5.1 integrierten IO-Interface für asynchrone Datenträgerzugriffe (AIO) zu verbessern (u. a. 1, 2). Einige der Änderungen rüsten auch weitere Funktionen nach, etwa die Unterstützung des vor allem für Netzwerkübertragungen verwendeten Syscall accept().

Linux 5.5 beseitigt die Ursache für einen I/O-Fehler, durch den bei einigen modernen SSDs der Trim-Vorgang misslingt, der auch als Discard bekannt ist; das war eines der Probleme, die jüngst bei Linux-Experimenten auf dem optimalen PC 2020 der c't aufgetreten sind.

Unter den Umbauten am Btrfs-Code war eine Optimierung am Llseek-Code von Btrfs. Sie verspricht deutliche Performance-Zuwächse in Situationen, wo mehrerer Programme parallel in einer Datei lesen oder schreiben und dabei ständig die Position in der Datei per Fseek anpassen. Ein spezieller Test, mit dem der Entwickler explizit den Gewinn durch den Umbau zeigen will, lief dadurch rund achtzig Prozent schneller ab.

Einige weitere Neuerungen rund um den Storage-Support nennen die Kommentare der wichtigsten Git-Merges bei Ceph, NVDIMM, NFSd, SCSI und UBI/UBIFS/JFFS2.

Firewall-Offloading und Feintuning für WLANs

BPF-Optimierungen verbessern Performance und schaffen neue Einsatzmöglichkeiten

Die von den Entwicklern des Netzwerk-Subsystems vorangetriebene BPF Virtual Machine beherrscht jetzt "BPF Trampolines", über die sich BPF-Programme nahezu ohne Overhead ganz am Anfang oder Ende beliebiger Funktionen (fentry/fexit) einklinken können. Das gelingt durch Verändern des Kernel-Codes zur Laufzeit (Live Patching) und ermöglicht zwei Dinge:

• Eine Instrumentierung für eine Ablaufverfolgung (Tracing), die weniger Overhead ausweist als Kprobes/Kretprobes oder Tracepoints; das verbessert nicht nur die Performance der Analyse, sondern reduziert auch deren Störeinfluss.
• Mit dem BPF ausgeführte Programme können leichter andere BPF-Programme aufrufen; das erleichtert ein effizientes Tracing von BPF-Programmen, die der Kernel im Rahmen von XDP (eXpress Data Path), TC (Traffic Control) oder Control Groups (Cgroups) ausführt.

Der Ansatz beseitigt so einige Engstellen, die Nutzern des BPF bislang in die Quere gekommen sind. Zusammen mit der besseren Performance ermöglicht das neue Einsatzgebiete für BPF-Programme.

Den Trick, den Kernel zur Laufzeit zu modifizieren, nutzen die BPF-Entwickler daher noch in einem anderen Bereich: Sie eliminieren den Retpoline genannten Kniff zum Schutz vor der Prozessorlücke Spectre v2 an einer zentralen Stelle der BPF Virtual Machine. Dadurch können sie dort den Overhead von Retpoline vielfach vermeiden und die Performance der BPF VM weiter verbessern.

Apropos Ablaufverfolgung: Ein mit den Worten "Revolutionize BPF Tracing and BPF C-Programmierung" angepriesener Schwung von Änderung ermöglicht eine effiziente Typ-Überprüfung von Pointern in BPF-Code. Dadurch sollen populärer werdende Analysewerkzeuge wie bpftrace sowie Werkzeuge und Analyseprogramme der BPF Compiler Collection (BCC) zuverlässiger und flotter arbeiten. Details hierzu liefert LWN.net im Artikel "Type checking for BPF tracing".

Optimierungen für WLAN-Durchsatz und Kommunikation mit Virtual Machines (VMs)

Bessere WLAN-Performance verspricht die neue Unterstützung für Airtime-based Queue Limit (AQL) im WLAN-Stack des Kernels. Der Code kann einerseits übermäßige und dadurch störende Datenpufferung ("Bufferbloat") vermeiden, hilft aber auch dabei, das Funkspektrum besser ausnutzen (u. a. 1, 2, 3).

Der neue Multi-Transport-Support für Vsock (VM Sockets) verspricht, die Performance bei Nested Virtualization zu verbessern: Dank dieser Infrastruktur kann ein Betriebssystem in virtuellen Maschinen (VMs) nicht nur über Sockets effizient mit dem Host kommunizieren, sondern zugleich auch mit Betriebssystemen in VMs, die es selbst gestartet hat.

Firewall-Offloading und Umgehung einer Namensbeschränkung

Der Kernel kann Netzwerk-Interfaces jetzt mehrere alternative Bezeichnungen geben. Das gelingt über einen neuen Mechanismus, der auch das Limit von Gerätenamen für Netzwerkschnittstellen auf 16 Zeichen beseitigt, das durch die Vielfältigkeit moderner Netzwerk-Hardware mehr und mehr kneift.

Das für Firewalls und Routing zuständige Netfilter-Subsystem kann ab Linux 5.5 weitere Aufgaben beim Abarbeiten von Flusstabellen (Flow Tables) an Netzwerkchips delegieren, die diese Aufgabe übernehmen können. Das kann den Hauptprozessor entlasten und verbessert vielfach die Performance. Details dazu finden sich in den den Vortragsfolien und der Videoaufzeichnung eines Vortrags, in dem der zuständige Entwickler den Ansatz im September auf der Linux Plumbers Conference 2019 vorgestellt hat.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Verschlüsselte Cluster-Kommunikation

Das für die effiziente Kommunikation in Rechnerverbunden (Clustern) entworfene Protokoll "Transparent Inter-Process Communication" (TIPC) beherrscht nun Authentifizierung und überträgt Daten auf Wunsch verschlüsselt (1, 2). Userspace-Code zur Nutzung dieser Funktion wird Version 5.5 der Netzwerk-Werkzeugsammlung Iproute2 mitbringen.

Nachdem der CIFS/SMB-Dateisystemcode bei Linux 5.4 gelernt hat, Samba- oder Windows-Freigaben als Root-Dateisystem einzuhängen, erhielt der Netzwerk- und Init-Code jetzt Änderungen, um die IP-Konfiguration und alles andere erforderliche zu unterstützen. Das experimentelle Feature funktioniert ähnlich wie beim Einbinden einer NFS-Freigabe als Root-Dateisystem.

Der zuständige Entwickler hat dabei Teile des Codes vom Nfsroot-Support kopiert und leicht angepasst – darunter kurioserweise auch ein paar Zeilen heute vollkommen unzeitgemäß scheinenden Codes, durch die der Kernel bei Problemen mit Cifsroot laut Log-Meldung versucht, ein Root-Dateisystem auf einer Diskette im ersten Laufwerk (/dev/fd0) zu finden.

Detailverbesserungen beim Netzwerksubsystem

Eine ganze Reihe weiterer wichtiger Neuerungen bei der Netzwerk-Unterstützung von Linux nennt der Kommentar des Git-Merges, mit dem das Gros der Änderungen dieses Subsystems zum Kernel stieß. Darunter etwa Unterstützung für Übertragungen mit 400 GBit/s (50 GBit/s pro Lane) im Ethtool-Interface und dem Netzwerktreiber Mlxsw. Außerdem unterstützen die Netzwerktreiber Mvneta (Marvell Armada 370/38x/XP/37xx), SFC (Solarflare SFC9000/SFC9100) und Ice (Intel 800er-Serie) jetzt den Netzwerk-Schnellverarbeitungsweg XDP (eXpress Data Path). Der letztgenannten Treiber rüstet auch gleich Unterstützung für AF_XDP nach, mit dem Userspace-Programme seit Linux 4.18 effizient Netzwerkpakete abgreifen können.

Außerdem gab es eine Änderung am Flow-Code von Open-vSwitch, die den Durchsatz in einem Test-Szenario des zuständigen Entwicklers von 8 MBit/s auf 46 MBit/s zu steigern vermag. Das ist nur eine von vielen Detailoptimierungen im Netzwerkbereich, um die Performance zu verbessern; weitere Änderungen samt Messwerte nennen die Git-Merges zu Patch-Serien wie "Control action percpu counters allocation by netlink flag", "page_pool: API for numa node change handling", "add DMA-sync-for-device capability to page_pool API" und die einzelnen Commits der Serie "net: introduce and use route hint".

HDCP-Support bei AMD und Treiberverbesserungen zum Stromsparen

Radeon: Unterstützung für RX 5600, HDCP und Stromspartechniken

Durch Detailverbesserungen am Treiber Amdgpu läuft die am 21. Januar vorgestellte Radeon RX 5600 mit Linux 5.5. Damit das klappt, muss man das System aber zugleich auch mit aktuellen Firmware-Dateien versorgen. Der neue Kernel unterstützt zudem von Haus aus die Grafikeinheit der jüngst von AMD vorgestellten Ryzen-4000-Prozessoren.

Der für moderne Radeon-Grafikchips zuständige Treiber kann außerdem jetzt die Datenübertragung zum Monitor per HDCP verschlüsseln (1, 2); das gelingt mit GPUs seit der Raven-Ridge-Generation, die etwa in Ryzen-2000G-CPUs steckten Das Ganze ist vorwiegend für Linux-basierte Betriebssysteme wie ChromeOS gedacht, die hochauflösende Videos von Netflix, Amazon & Co. wiedergeben sollen. Diese Systeme hatten daher entsprechende Kernel-Patches teilweise schon integriert und weitere Vorkehrungen getroffen, um HDCP umfassend zu unterstützen. Sie schützen sich oft auch mit UEFI Secure Boot und ähnlichen Techniken vor Modifikationen, damit findige Bastler kopiergeschützte Videodaten nicht schon vor der Übertragung an den Monitor abgreifen.

Geringe Leistungsaufnahme und längere Akkulaufzeit verspricht Unterstützung für PSR (Panel Self-Refresh) im Amdgpu-Treiber, denn durch die Technik kann sich der Grafikchip teilweise schlafen legen, solange sich am dargestellten Bildschirminhalt nichts ändert. Eine geringe Leistungsaufnahme ist auch das Ziel der jetzt unterstützten AMD-Techniken "Dynamic VCN Powergating" bei Raven- und Raven2-Chips sowie BACO (Bus Active, Chip Off) bei den älteren GPUs der Generationen Sea Islands, Tonga, Fiji und Polaris.

Vorbereitungen für Intels dedizierte Grafikchips

Intels Entwickler haben Änderungen beigesteuert, damit ihr Grafiktreiber auch Systeme unterstützt, in denen neben einer Intel-CPU mit integriertem Grafikprozessor ein bei Bedarf zuschaltbarer Grafikprozessor des Herstellers steckt. Derlei gab es bislang nicht, wird aber durch Intels Einstieg in den Markt für dedizierte Grafikchips bald möglich.

Auch an anderen Stellen haben die Entwickler den Support für den "Gen12" genannten Grafikkern verbessert, denn dieser steckt auch in den GPUs von Desktop- und Notebook-Prozessoren der "Tiger Lake"-Reihe, die Intel wohl in der zweiten Jahreshälfte als Nachfolger für Ice Lake einführen will. Intels Mitarbeiter haben ferner Unterstützung für den SoC (System on Chip) "Jasper Lake" nachgerüstet. Wie gewohnt ist der Treiber-Support für diese noch nicht erhältlichen Chips noch unfertig und muss explizit aktiviert werden. Nicht nur beim Konfigurieren des Kernels via DRM_I915_FORCE_PROBE, sondern auch im Betrieb – etwa, indem man beim Booten den Parameter i915.force_probe=* angibt. Diese Tricks reichen den Entwicklern aber noch nicht, daher haben sie jetzt eine weitere Hürde eingeführt, um den vorerst nur für Entwickler gedachten Treibercode noch besser von Anwendern fernzuhalten.

Noch mehr Änderungen bei Grafiktreibern

VMware-Entwickler haben eine Infrastruktur für "Coherent Memory Support" beigesteuert. Diese Technik zu koordinierten Speicherzugriffen kann Performance kosten, ist aber zur korrekten Implementation von OpenGL- und Vulkan-Grafiktreibern in virtuellen Maschinen (VMs) nötig, die per Paravirtualisierung mit dem Wirt interagieren.

Der MSM-Treiber für Qualcomm-GPUs unterstützt jetzt auch den Adreno 510, der in einigen Snapdragon-SoCs sitzt. Zur besserer Unterstützung der Prozessoren dieser Serie stieß zudem ein Treiber Ocmem dazu, der dem Grafiktreiber Arbeitsspeicher bereitstellen kann.

Weitere Neuerungen rund um die Grafiktreiber von Linux umreißt der wichtigste Git-Pull-Request des Direct Rendering Managers (DRM) und seiner Treiber.

Treiber für WLAN, Gaming-Keyboards oder Video-Beschleunigung

Video-Beschleunigung für populären SoC-Prozessoren

Der Video-Beschleunigungstreiber Cedrus kann jetzt auch HEVC/H.265 über die Hardware dekodieren. Dieser maßgeblich über eine viel beachtete Crowdfunding-Kampagne finanzierte Treiber spricht die Cedar genannte Video Processing Unit (VPU) einiger Allwinner-Prozessoren der Sunxi-Reihe an, die sich auf einer Reihe von populären Einplatinencomputern finden. Allerdings kam nicht genug Geld zusammen, damit die Programmierer auch für Support von H.264-Encoding sorgen. Ungewiss ist, ob der Treiber diese und einige andere noch fehlende Features je lernt, denn die zuständigen Entwickler wenden sich jetzt anderen Projekten zu.

Gaming-Keyboard und Netzwerkchips

Die Sondertasten der Logitech-Gaming-Tastaturen G15 und G510 funktionieren jetzt (1, 2); wie man diese ausreizt, erläutert der zuständige Entwickler in seinem Blog. Außerdem unterstützt Linux jetzt Touchpads besser, die die Spezifikationen für "Windows Precision Touchpads" einhalten.

Neu dabei ist auch Support für die Netzwerkfunktion, die Intels Tiger-Lake-Prozessoren bieten sollen. Ferner spricht Linux nun auch Realteks Gigabit-Ethernet-Chip RTL8117 an, der auf einigen Mainboards für die neuesten Desktop-CPUs von AMD und Intel sitzt. Einige Anpassungen am WLAN-Treiber für den Reaktek RTL8723BU versprechen dessen Sendegeschwindigket deutlich zu steigern – der Treiber kommt aber dennoch fürs Erste nicht an die TX-Performance heran, die ein anderer, von Realtek selbst gepflegter Treiber erzielt.

Noch mehr neue und verbesserte Treiber

Die Audio-Treiber für GeForce-Chips beherrschen die Audio-Übertragung per DisplayPort nun auch, wenn der Datenaustausch mit MST (Multi Stream Transport) erfolgt (1, 2, 3). Über einen neuen Mechanismus können Distributionen jetzt besser festlegen, welcher Audio-Treiber standardmäßig für Intel-Chips genutzt wird, für die es mehrere Treiber gibt. Das ist auch aus Stromsparaspekte wichtig, denn einige Treiber arbeiten effizienter. Die Treiber der Google Embedded Controller und die Audio-Funktion einiger System-on-a-Chip-Prozessoren beherrschen jetzt Wake on Voice (WoV), mit dem sich einige der neueren Chromebooks über Sprachkommandos wie "Ok Google" aufwecken und steuern lassen (u. a. 1, 2, 3).

Linux 5.5 unterstützt jetzt auch die Firmware-TPM-Lösung der Zen+-CPUs von AMD. Diese und andere Optimierungen und Erweiterungen beim Hardware-Support, die dieser Text erwähnt, sind indes nur die Spitze des Eisbergs: Allein durch neue und verbesserte Treiber unterstützt Linux 5.5 über 350 Geräte oder Geräteklassen mehr als sein Vorgänger; bei rund 40 davon handelt es sich um PCI/PCIe-Geräte, wie die Datenbanken der Linux Kernel Driver DataBase (LKDDb) zeigen.

Weitere Änderungen in diesem Bereich nennen die Kommentare der wichtigsten Git-Merges aus den Bereichen Character Devices, Drivers Core, HMM, HID, Input (1, 2), RDMA, Hardware Monitoring, Media, MFD, MMC, Platform, Sound, Staging, Thunderbolt, Thermal, TPMd, USB.

Wo der Kernel überall mitspielt

Wo der Linux-Kernel überall wichtig ist und involviert ist, zeigt indes ein simpler Patch im Input-Subsystem, der einen in der Spezifikation für Human Interface Decives (HID) festgelegten Tastencode für einen "Electronic Privacy Screen" Kernel-seitig definiert. Dieser Oberbegriff meint aktive Techniken, die den Bildschirminhalt vor neugierigen Blicken von der Seite schützen sollen. In diese Klasse fällt beispielsweise die seit Linux 5.4 unterstützte PrivacyGuard-Funktion einiger aktueller Thinkpads von Lenovo; HP verbaut in einigen seiner Notebooks eine ähnliche Technik namens SureView.

Durch die Definition des Tastencodes im Kernel können Desktop-Umgebungen nun zuverlässig und Hersteller-übergreifend erkennen, wenn der Anwender die Funktionstaste zum Ein- und Ausschalten der Privacy-Funktion betätigt, und können eine entsprechende Reaktion auslösen. Dadurch müssen Desktop-Umgebungen auch nur diesen einen Keycode lernen, denn falls die Funktionstaste eines Notebooks einen anderen Keycode sendet, kann der Tastaturtreiber das abfangen und stattdessen den jetzt definierten Tastencode an den Desktop schicken.

Weitere Marotten beseitigt

Die Kernel-Entwickler haben außerdem wieder Dutzende Patches integriert, um bekannte Eigenarten oder Marotten (Quirks) von Hardware so abzufangen, dass Anwender nichts davon mitbekommen und alles wie vorgesehen funktioniert. Eine dieser Anpassungen sollte etwa die Sound-Qualität des Lenovo Carbon X1 der sieben Generation verbessern, wo der Bass-Kanal nicht richtig konfiguriert wurde. Mit dem gab es auch beim Acer 8951G ein Problem, das behoben wurde. Auch die Stumm-LED des HP ProBook 645 G4, der Headset-Anschluss von Xiaomi-Laptops oder die integrierten Lautsprecher des Asus UX431FLC sollten jetzt wie vorgesehen funktionieren. Das waren nur Beispiele aus dem Audio-Bereich, aber es gibt auch Patches, die Marotten von Tastaturen, Ein-/Austastern, PCI-Controllern, Netzwerkchips, USB-Controllern und andere Hardware abfangen. Insgesamt hat Linux 5.5 mehrere Dutzend solcher Sonderbehandlungen gelernt (siehe zur Problematik auch den frei abrufbaren c't-Artikel "Kompatibilitätsprobleme beseitigen und Linux besser machen").

Mehr RAM und verkümmernder 32-Bit-x86-Support

Mehr und mehr Qualitätsmängel bei 32-Bit-x86-Unterstützung

Linux mag mit der 32-Bit-x86-Architektur (auch als IA-32, i386, ix86, … bekannt) seinen Siegeszug angetreten haben – die Qualität des für diese Prozessoren zuständigen Kernel-Codes lässt seit einiger Zeit aber massiv nach, weil sich immer weniger Entwickler dafür interessieren. Das lässt sich schon länger beobachten und zeigte sich jüngst wieder in einer Mail des angesehenen Linux-Entwicklers Andy Lutomirski. In der Mail an eine Mailingliste zur Sicherheit von Open-Source-Software umreißt er einige schwerwiegende Fehler, die teilweise eine ganze Weile im 32-Bit-x86-Code von Linux schwelten. Durch sie waren letztlich sowohl Sicherheit als auch korrekte Funktionsweise von 32-Bit-x86-Kerneln nicht sichergestellt.

Die Mail verschickte Lutomirski, nachdem er die Ursache einiger solcher Fehler korrigiert hatte; diese Änderung floss nicht nur in Linux 5.5 ein, sondern wurde auch in mehrere Stable- und Longterm-Kernel zurückportiert. Die Anpassung soll die gefundene Probleme indes nur "weitgehend" beseitigen – Lutomirski äußert zudem den Verdacht, dass noch mindestens ein weiterer Fehler zurückblieb.

Den vielen Anwendern, die auf einem 64-Bit-x86-Prozessor eine 32-Bit-x86-Linux-Distribution nutzen, rät Lutomirski zum Wechsel auf einen 64-Bit-x86-Kernel – solche sind durch große Verbreitung bei Entwicklern, Testfarmen (CI/Continuous Integration) und Anwendern besser getestet, daher fallen Fehler eher auf. Lutomirski wendet sich zudem an all jene, die 32-Bit-x86-Linux aktiv unterstützen: Sie sollen damit entweder aufhören oder sich bei Entwicklung und Qualitätssicherung im offiziellen Linux-Kernel engagieren.

Ob oder wo das Gehör findet, bleibt abzuwarten. Bei Hardware-Herstellern, die eine der Hauptstützen der Kernel-Entwicklung darstellen, kommt 32-Bit-x86-Linux schließlich nur noch sehr selten zum Einsatz, daher dürfte deren Motivation gering ausfallen. Linux-Distributionen sind normalerweise eine weitere große Stütze – aber alle großen haben den Support für die 32-Bit-x86-Architektur bereits eingestellt oder lassen ihn auslaufen, wenn man von Debian GNU/Linux und openSUSE Tumbleweed absieht. Ähnlich wie beim Support für bereits seit Jahren exotische Prozessorarchitekturen müssen am Ende wohl Freiwillige mit genug Motivation versuchen, die Fahne hochzuhalten.

Bis zu 128 Pebibyte Arbeitsspeicher

Bei neu konfigurierten 64-Bit-x86-Kernel-Images ist das seit Linux 4.14 unterstützte 5-Level-Paging jetzt standardmäßig aktiv. Diese Technik erweitert den Adressraum für Virtual Memory von 48 auf 57 Bit, wodurch die Menge des adressierbaren Arbeitsspeichers um das 512-fache wächst:

von 256 Tebibyte auf 131.072 Tebibyte (128 Pebibyte).

Intel hat Unterstützung für so große Adressräume in einige seiner jüngsten Prozessoren eingebaut, weil sich abzeichnete, dass die bisherige Grenze bei einigen Kunden bald kneifen würde. Die 128 Pebibyte sollten hier auf absehbare Zeit genug Spielraum verschaffen – ähnlich, wie es die 256 Tebibyte taten, die 2003 bei der Einführung der ersten x86-64-Prozessoren mehr als ausreichend erschienen.

Performance für KVM und Emulation für mehr Sicherheit

Wie jüngst üblich enthält auch 5.5 Optimierungen an verschiedenen Stellen, um den Overhead der Spectre-v2-Schutztechnik Retpoline zu reduzieren und so die Geschwindigkeit zu steigern. Bei 5.5 soll davon etwa die Performance bei der Virtualisierung mit KVM (Kernel Virtual Machine) profitieren (u. a. 1, 2, 3, 4).

Einen Sicherheitsgewinn verspricht eine Emulationschicht des Systemaufrufs iopl() auf x86-Systemen, den Userspace-Anwendungen nutzen können, um via IO-Ports mit Hardware zu interagieren (u. a. 1, 2, 3). Ohne diese Schicht können böswillige Anwendungen die Verarbeitung von Interrupts ein- und ausschalten und so das System ins Straucheln bringen. Details zu Gefahren und einen Lösungsansatz erläutert der LWN-net-Artikel "Emulated iopl()".

Unterstützung für neue und uralte Systeme

Neben dem eingangs bereits erwähnten Support für den Raspberry Pi 4 hat Linux auch den Umgang mit einer Reihe weiterer Prozessoren und Single Board Computer (SBC) mit ARM-Kernen gelernt. Dadurch unterstützt Linux jetzt etwa den Freescale S32V234, den Rockchip RK3308, das NanoPi Duo2 (Allwinner) und eine Reihe von Boards mit NXP-Prozessoren.

Linux läuft jetzt auch auf Prozessoren der MIPS Loongson-3A Revision 4 (R4). Apropos MIPS: Einige Entwickler haben Support für SGI Octane/Octane2 Workstations(IP30) nachgerüstet, die vor rund zwei Jahrzehnten produziert wurden.

Fehler abfangen, aber nicht zu viel warnen

Der x86-Code von Linux kann den Zufallszahlengenerator jetzt mit einer Saat (Seed) in Gang bringen, die der Kernel via UEFI erhält. Außerdem prüft der x86-Code jetzt, ob via RDRAND vom Prozessor angeforderte Zufallszahlen allem Anschein nach valide sind; das soll gegen Fehler helfen, wie sie Mitte 2019 bei einigen Prozessoren von AMD bekannt wurden. Apropos AMD: Die Entwickler haben einige Anpassungen im Treiber für MCEs (Machine-check Exceptions) vorgenommen, um ein Problem zu beseitigen, durch das Linux auf vielen Boards mit AMDs neuem Threadripper nur bei Angabe von mce=off startete.

Der Kernel warnt in seinem Protokollausgaben nicht mehr so deutlich, wenn sich der Prozessor drosselt, um sich vor Überhitzung zu schützen. Dazu haben sich die Kernel-Entwickler unter anderem entschlossen, weil dies "Throttling" bei modernen Notebooks deutlich häufiger vorkommt – unter anderem, weil deren Kühlsysteme teilweise nicht mehr für längere Volllast ausgelegt sein sollen.

Der RISC-V-Code von Linux beherrscht jetzt auch den "nommu" genannten Betrieb, was den Einsatz auf Prozessoren ohne Memory Management Unit (MMU) ermöglicht.

Unter den Änderungen am Code zum Betrieb unter Microsofts Hypervisor Hyper-V war Support zum Wechsel in den Ruhezustand (Hibernation).

Bei PCI/PCIe-Geräten lässt sich jetzt via Sysfs (/sys/…) steuern, ob oder wie weit sie die Stromspartechnik ASPM verwenden.

Details zu diesen und weitere Neuerungen rund um den Architektur-Support finden sich in den wichtigsten Kommentaren der wichtigstes Git-Merges der Subsysteme ARC, ARM, ARM64 (1, 2), Armsoc (Defconfig, Driver, DT, Fixes, Platform), Devicetree/DT, EDAC, EFI, KVM, M68K, MIPS, PCI, Power, RAS/Reliability, Availability and Serviceability (1, 2), RISC-V, S390 (1, 2), x86 (ASM, Boot, CPU, Microcode, MM), XEN und Xtensa.

Ausblick und Statistik zu jüngsten Linux-Versionen

Ausblick auf Linux 5.6

Mit der Freigabe von Linux 5.5 beginnt zugleich die "Merge Window" genannte Phase, in der Linus Torvalds das Gros der Änderungen für den Nachfolger integriert. In den nächsten Tagen fließen daher viele tausend Änderungen in den Hauptentwicklungszweig von Linux ein, die Entwickler in den letzten Wochen zur Aufnahme in 5.6 vorbereitet und gesammelt haben. Darunter wie bereits erwähnt Support für den PCIe-Controller des Raspberry Pi 4, Wireguard und USB4.

Darüber hinaus liegt aber noch einiges andere bereit. Btrfs soll etwa eine Infrastruktur für "Async Discard" erhalten, um Datenträger per Trim & Co. über nicht mehr genutzte Speicherbereiche informieren zu können, ohne dabei die Performance groß zu beeinflussen. Nachdem Linus Torvalds erst bei Linux 5.4 am Zufallszahlengenerator herumgedoktert hat, geht es dort erneut zu Werke: Die Entwickler wollen eine lang bekannte Eigenart beim Zugriff via /dev/random ein für allemal aus der Welt schaffen. Ganz sicher ist es noch nicht, aber vielleicht fließt auch der bessere Code für Microsofts exFAT-Dateisystem in den Kernel ein – dieser Schritt zeichnete sich schon am Horizont ab, als bekanntermaßen schlechter exFAT-Support in Linux 5.4 einging.

Linus Torvalds beendet das Merge Window typischerweise nach zwei Wochen, indem er die erste Vorabversion einer neuen Kernel-Version veröffentlicht. Das läutet zugleich die Stabilisierungsphase ein, die derzeit fast immer sieben oder acht Wochen dauert. Linux 5.6 erscheint daher mit ziemlicher Sicherheit am 29. März oder 6. April.

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.20	62.481	25.955.520 (23.776.585)	63 Tage	14.995 (13.844)	11402 files changed,  685.027 insertions(+),  317.959 deletions(-)
Linux 5.0	63.135	26.203.035 (23.933.016)	70 Tage	13.921 (12.808)	12.100 files changed, 579.084 insertions(+), 331.570 deletions(-)
Linux 5.1	63.873	26.459.776 (24.141.004)	63 Tage	14.160 (13.034)	11.977 files changed,  545.423 insertions(+),  288.683 deletions(-)
Linux 5.2	64.587	26.552.127 (24.175.296)	63 Tage	15.089 (14.024)	30.888 files changed,  624.857 insertions(+),  532.510 deletions(-)
Linux 5.3	65.261	27.141.312 (24.708.822)	70 Tage	15.784 (14.605)	13.983 files changed,  1.189.832insertions(+),  600.665 deletions(-)
Linux 5.4	65.701	27.538.212 (25.059.661)	70 Tage	15.725 (14.619)	12.800 files changed,  821.993 insertions(+),  435.081 deletions(-)
Linux 5.5	66.493	27.854.754 (25.313.538)	63 Tage	15.497 (14.350)	11.780 files changed,  607.843 insertions(+),  291.305 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

Den neuen Linux-Kernel herunterladen und einrichten

In den ersten Stunden nach der Freigabe steht die neue Linux-Version nur über einen Git-Checkout des "Mainline" genannten Hauptenwicklerzweigs von Linux bereit; die Download-Möglichkeit über die Frontseite von Kernel.org folgt meist erst, wenn sich die Büros in Europa richtig füllen und jemand die Archive signiert hat.

Auf Kernel.org findet sich auch eine Anleitung, wie Sie die Authentizität und die Unversehrtheit des Quelltextes von Linux prüfen; dort gibt es auch ein Skript, das eine Version herunterlädt und diese Aufgaben durchführt.

Fedora und Rolling-Release-Distributionen wie Arch Linux, Gentoo und OpenSuse Tumbleweed erhalten die neue Linux-Version in den nächsten Tagen und Wochen im Rahmen der regulären Systemaktualisierung. Bei bereits erhältlichen oder kurz vor der Veröffentlichung stehende Releases von Debian, OpenSuse Leap, Ubuntu und den meisten anderen klassisch gewarteten Distributionen macht der Kernel normalerweise keine größeren Versionssprünge; deutlich neuere Linux-Versionen erhält man dort meist nur beim Wechsel auf eine neuere Version der Distribution.

Einzelne Distributionen werden den neuen Kernel über Backports-Repositories zur einfachen Installation anbieten. In der Regel sind solche aber standardmäßig inaktiv, weil dort andere Pflegerichtlinien gelten; Sicherheitskorrekturen beispielsweise gibt es dort meist zeitnah, werden aber vielfach nicht garantiert.

Bei vielen populären Distributionen wird man die neue Linux-Versionen auch über Kernel-Pakete aus Repositories nachrüsten können, die Fans oder Entwickler pflegen. Anwender sollten sich bewusst sein, dass sie über solche Angebote den zentralen Baustein ihrer Distribution austauschen. Wer solche Repositories verwendet, sollte deren Machern daher ähnlich trauen wie seinem Distributor, denn über darin liegende Pakete lassen sich kinderleicht Hintertüren einschleusen. Nach dem Einbinden solcher Repositories obliegt es zudem den Machern dieser Depots, die ausgetauschten Pakete fortan mit Sicherheitskorrekturen zu versorgen. Das vorübergehende oder dauerhafte Aktivieren solcher Repositories kann zudem zu Abhängigkeitsproblemen bei späteren Updates der Distribution führen. Da zentrale Software ausgetauscht wird, kann es zudem leicht zu Instabilitäten kommen; im dümmsten Fall startet das ganze System nicht mehr.

Wer die neue Linux-Version eigenhändig kompilieren und einrichten will, findet Hinweise dazu im c't-Artikel "Linux-Kernel maßgeschneidert". Das darin beschriebene Make-Target make localmodconfig erzeugt weitgehend automatisch eine recht gut auf das jeweilige System zugeschnittene Kernel-Konfiguration, mit der Sie in wenigen Minuten eine neue Linux-Version einrichten können.

Allerlei weitere Informationen zu Linux liefern der erste, zweite, dritte, vierte und fünfte Teil einer c't-FAQ-Reihe mit "Basiswissen zum Linux-Kernel".

Mehr Infos

Versionshistorie dieses Artikels

• 2020-01-27, 08:30 – v2.0: Text anlässlich der Freigabe von 5.5 umgestellt und am Anfang einen Kurzüberblick eingefügt. Ferner auf Seite 3 die Änderungen im Bereich Infrastruktur erläutert, die bis zu diesem Zeitpunkt noch außen vor geblieben waren.
  
• 2020-01-22, 06:30 – v1.4: Neue und verbesserte Treiber umrissen.
• 2020-01-15, 06:30 – v1.3: Verbesserungen rund um Architektur-Code beleuchtet.
  
• 2020-01-09, 06:30 – v1.2: Änderungen beim Netzwerkcode erläutert.
  
• 2019-12-17, 06:30 – v1.1: Neuerungen bei Dateisystemen und Storage-Support beschrieben.
  
• 2019-12-09, 07:20 – v1.0: Anlässlich der ersten Vorabversion von Linux 5.5 die Highlights dieser Kernel-Version kurz angerissen.

Der Newsticker von heise online wird alle größeren Erweiterungen dieses Kernel-Logs erwähnen, auf die außerdem auch der Twitter-Account @kernellog hinweist.

(thl)