Linux 4.18 freigegeben: Raspi-3-Support und Vorboten neuer Firewall-Technik Update

Linux-Kernel 4.18

Trends & News | Kernel-Log

Highlights von Linux 4.18 sind Support für USB 3.2, Anfänge eines neuen Firewall-Ansatzes, neue Grafiktreiber und Verbesserungen zur Live-Migration von VMs.

Linus Torvalds hat Sonntagnacht den Linux-Kernel 4.18 freigegeben, der wieder über dreizehntausend Änderungen bringt. Einige rüsten neue Features oder Treiber nach, andere verbessern existierende. Die wichtigsten Neuerungen im Kurzüberblick:

  • Linux 4.18 bringt erste Teile des Bpfilter, einer neuen Paketfiltertechnik für Firewalls. Aber keine Sorge, Sie brauchen nicht um Ihr Iptables- oder Nftables/nft-Know-how fürchten: Bpfilter ersetzt lediglich den Unterbau im Kernel, auf den das altbekannte Iptables und sein designierter Nachfolger aufbauen.
  • Unter den Bpfilter-Vorboten ist auch eine Neuerung, die mittel- und langfristig womöglich größere Bedeutung bekommt: Eine Infrastruktur, um im Rahmen der Linux-Quellen entwickelte Helferprogramme in Kernel-Module zu verpacken, die der Kernel wie ein normaler Userspace-Prozess mit geringeren Privilegien ausführt. Das verhilft dem eher monolithischen Linux-Kernel letztlich zu einer Infrastruktur, die prinzipiell eine Modularisierung in der Art von Microkerneln ermöglicht.
Der Intel-AMD-Kombiprozessor mit Vega-M-Grafik. (Bild: Intel)
  • Der Amdgpu-Treiber unterstützt nun auch den Grafikprozessor AMD Radeon RX Vega M, der auf Intel-AMD-Kombiprozessoren der Core-i-8000er-Familie sitzt.
  • Linux 4.18 ist die erste Kernel-Version von Kernel.org, die von Haus aus den Raspberry Pi 3B und den 3B+ halbwegs ordentlich unterstützt.
  • Zu Linux stößt ein Treiber für moderne Grafikeinheiten von Broadcom, um die sich immer wieder Gerüchte ranken, sie seien für zukünftige Raspis vorgesehen.
  • Neu dabei sind Grundlagen zum Support des Qualcomm-Prozessors Snapdragon 845, der in einigen mit Windows ausgelieferten ARM-Notebooks steckt. Das hat Linus Torvalds interessiert 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 von Linux ordentlich unterstützt werden.
  • Linux 4.18 unterstützt bereits eine neue und wohl performantere Generation von AMDs derzeit leistungsstärksten Grafikchips.
  • Erstmals dabei sind auch Grafik- und Soundtreiber, die für eine noch junge Virtualisierungs-Betriebsart von Xen gedacht sind.
  • Linux beherrscht jetzt die mit USB 3.2 definierte Dual-Lane-Übertragung, die die maximale Datentransferrate von USB-C-Verbindungen auf 20 GBit/s verdoppelt.
  • Eine Reihe kleiner Umbauten verbessert den Schutz vor der Prozessorsicherheitslücke Spectre v1. Die Entwickler haben zudem den Spectre-v4-Schutz für AMD-Prozessoren optimiert. Außerdem bringt Linux jetzt auch endlich Maßnahmen mit, um von Spectre v1 und v2 betroffene 32-Bit-ARM-CPUs vor dem Ausnutzen dieser Lücken zu schützen; schwelende Probleme bei der Interaktion mit dem zuständigen Subsysteme-Betreuer sind der Grund, warum der offizielle Kernel erst jetzt schützt, obwohl Gegenmaßnahmen schon seit Monaten verfügbar sind.
  • In Containern definierte Anwender dürfen jetzt eigenständig Dateisysteme mit FUSE mounten, wenn sie im Container Root-Rechte haben.
  • Nach mehreren Entwicklungsjahren unterstützt der Kernel nun auch Restartable Sequences, mit denen Programmierer von Anwendungen den Locking-Overhead reduzieren können.
  • Der Linux-Kernel 4.18 bringt zwei Netzwerktechniken, mit denen Anwendungsentwickler Overhead vermeiden und so die Netzwerkperformance steigern können.

Dies war ein schrittweise aktualisierter Artikel

Dieser Text wurde mehrfach erweitert, um nach und nach alle wesentlichen Änderungen Linux 4.18 zu beschreiben. Zur jüngst erfolgten Freigabe dieser Kernel-Version haben wir die Abschnitte umsortiert 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.

  • Feintuning bei der Stauvermeidung soll WLANs beschleunigen. Ferner kann der Kernel die TLS-Verschlüsselung jetzt an Netzwerkchips delegieren.
  • Ein als Device-Mapper-Target implementierter Schreib-Cache ist für Systeme gedacht, bei denen Admins störende Wartezeiten beim Speichern von Daten tunlichst vermeiden wollen.
  • Ein neuer Netzwerktreiber verspricht, die Live-Migration von VMs zu erleichtern, die Teilfunktionen des im Wirtssystem steckenden Netzwerkchips nutzen.
  • Google-Entwickler haben den Code zu Verschlüsselung innerhalb von Dateisystemen erweitert, damit er auch den umstrittenen und seit 4.17 prinzipiell unterstützten Speck-Algorithmus nutzen kann. Laut den Programmierern wollte Google diesen Ansatz bei billigen Android-Geräten nutzen, hat den Plan aber zwischenzeitlich verworfen. Kurz vor Fertigstellung von 4.18 haben einige Entwickler daher noch diskutiert, den Support für das von der NSA entwickelte Speck samt der neuen Fscrypt-Erweiterungen wieder zu entfernen. Dazu ist es aber nicht gekommen.
  • Dank Rauswurf des vor allem beim High Performance Computing (HPC) eingesetzten Cluster-Dateisystems Lustre ist Linux 4.18 kleiner als sein Vorgänger; solch eine Schrumpfkur passiert erst das vierte Mal in der Entwicklungsgeschichte und war jüngst erst bei 4.17 der Fall.
  • Statt der gewohnten neun Wochen hat die Entwicklung diesmal zehn gedauert. Hauptschuld daran sind eine Reihe kleinerer Probleme, die Torvalds noch angegangen sehen wollte, daher hat er die Extra-Woche spendiert. Dem üblichen Rhythmus folgend dürfte Linux 4.19 daher Mitte Oktober erscheinen. Sofern Torvalds seine Andeutungen wahr macht, folgt zum Jahreswechsel dann Linux 5.0.

Die folgenden Artikelseiten liefern zahlreiche Details zu diesen und zahlreichen weiteren Neuerungen von Linux 4.18. Die letzte Artikelseite liefert zudem einen Ausblick auf Änderungen, die 4.19 bringen dürfte.

Der neue Linux-Kernel bringt erste Teile einer neuen Paket-Filter-Technik für Firewalls: Bpfilter. Admins brauchen sich allerdings nicht um ihr Iptables- oder Nftables/nft-Know-how zu sorgen, denn Bpfilter soll lediglich den Unterbau ersetzen, den das altbekannte Iptables und sein designierter Nachfolger nutzen. Das soll beide deutlich schneller machen. Noch liegt dieses Ziel aber in weiter Ferne, denn bei 4.18 wurden nur Teile des dazu nötigen Fundaments gelegt.

Der Clou von Bpfilter: Die Entscheidung über die Handhabung von Netzwerkpaketen erfolgt durch lokal erzeugten Programmcode, den der Kernel mit dem BPF ausführt. Dabei handelt es sich um eine prozessbasierte Virtual Machine, die allerdings simpler gestrickt ist als jene von .NET oder Java. Die VM ist auch als eBPF bekannt, da sie in den letzten Jahren aus dem Berkeley Packet Filter (BPF) hervorgegangen ist; mit ihm hat der aktuelle und an zahlreichen Stellen des Kernels genutzte BPF aber kaum noch etwas gemein.

Der BPF-Programmcode zum Filtern der Netzwerkpakete wird bei Bpfilter für die jeweiligen Anforderungen maßgeschneidert. Das reduziert Verzweigungen im Code und verspricht, Overhead zu vermeiden. Damit der Prozessor den BPF-Code möglichst schnell ausführt, übersetzt der Kernel ihn auf gängigen Prozessor-Architekturen noch per Just-in-Time (JIT) in Maschinenbefehle. Darüber hinaus kann Bpfilter den Netzwerkverkehr schon beim eXpress Data Path (XDP) abgreifen; der BPF-Code verarbeitet die Pakete dann schon kurz nach Empfang durch die Netzwerk-Hardware, bevor der mächtigere und daher trägere Netzwerkstack von Linux übernimmt.

Durch diese und andere Vorteile verspricht der neue Ansatz, effizienter zu arbeiten als der Iptables- und Nftables-Code im Netfilter-Subsystem. Der ist zwar in C geschrieben, aber als universeller und flexibler Paket-Filter ausgelegt. Beim Abarbeiten des Regelsatzes muss der Code daher auch auf Eventualitäten gefasst sein, die lokal verwendete Regeln gar nicht nutzen. Das macht den Codepfad komplex, schließlich bietet Netfilter immens viele Möglichkeiten, von denen Firewalls meist nur einen Bruchteil nutzen.

Der Umstieg auf Bpfilter ist aber noch Zukunftsmusik, denn in 4.18 flossen lediglich Vorarbeiten ein. Sie schaffen eine Infrastruktur, mit der der Kernel den Filtercode lokal erzeugen soll. Das erfordert einen komplexen Übersetzungsvorgang, daher wollen die Entwickler die dazu nötigen Funktionen nicht im Code sehen, der mit Kernel-Rechten ausgeführt wird. Da es um eine sehr sicherheitskritische Kernel-Funktion geht, wollen sie die Aufgabe aber auch nicht an Werkzeuge delegieren, die unabhängig vom Kernel entwickelt werden und als normale Anwendungen laufen.

Dieses Dilemma gehen die Programmierer mit einer in 4.18 eingeflossenen Erweiterung am User Mode Helper (UMH) und Module-Code an. Sie schaffen einen Zwischenweg, mit dem sich im Rahmen der Kernel-Quellen entwickelte Userspace-Software in autark arbeitende Kernel-Module packen lassen. Bei Bpfilter soll das Modul ein Programm enthalten, das den Bpfilter-Code erzeugt, kompiliert und dabei über Pipes mit dem Kernel interagiert. Das Programm läuft dabei unabhängig vom Userland der verwendeten Linux-Distribution, zugleich aber auch ohne Kernel-Privilegien – es kann daher abstürzen oder abgeschossen werden, ohne dass es den Kernel sonderlich juckt.

Mit diesem Fundament ist auch schon Rumpfcode für Bpfilter in 4.18 eingeflossen, mit dem sich bereits ein Bpfilter.ko genanntes Kernel-Modul erzeugen lässt. Allerdings ist der bislang zu nichts nutze, denn die Entwickler haben die Schnittstellen und den rudimentären Code zurückgestellt, der BPF-Code zum Paketfiltern lokal erzeugt. Diese Funktionen soll bei einer der nächsten Kernel-Versionen folgen, sobald die grundlegende Infrastruktur die gröbsten Fehler abgeschüttelt hat.

Nutzer sollen von Bpfilter nicht viel mitbekommen, denn Letzterer lässt sich über die Programmierschnittstellen ansprechen, die klassische Filterwerkzeuge wie iptables oder das Nftables-Tool nft bereits nutzen, wenn sie mit dem Iptables- oder Nftables-Code im Netfilter-Subsystem des Kernels interagieren. Die derzeit im Umlauf befindlichen Programme sollten daher auch mit Bpfilter funktionieren.

Der Bpfilter steckt zwar noch in den Kinderschuhen, verspricht laut ersten Messungen eines Entwicklers aber deutlich schneller zu arbeiten als die Iptables- und Nftables-Infrastruktur des Linux-Kernels. (Bild: Quentin Monnet auf netronome.com )

Frühen Messungen zufolge soll Bpfilter im Betrieb deutlich bessere Performance erzielen. Noch mehr Geschwindigkeit versprechen derzeit eher exotische Netzwerk-Chips, die einen BPF-Beschleuniger mitbringen, um BPF-Code direkt auszuführen.

Solche Verbesserungen sind wichtig, damit Firewalls auch den Verkehr von 40G-Netzwerkkarten stemmen, schließlich rauschen dort in der Spitze rund 60 Millionen 64-Byte-Pakete pro Sekunde durch. Das überfordert den älteren Netfilter-Code bei Weitem. Einige weitere Gründe für die Arbeit an Bpfilter nennt der langjährige Linux-Netzwerkcode-Entwickler Thomas Graf im Blog-Beitrag "Why is the kernel community replacing iptables with BPF?"

Es bleibt abzuwarten, ob das mit Bpfilter so klappt, wie die beteiligten Entwickler sich das denken; bis der neue Ansatz den alten vollständig ersetzen kann, müssen die Programmierer noch allerlei Funktionen implementieren, was einige Zeit dauern wird.

Die Erfolgsaussichten des Bpfilter stehen aber ziemlich gut, denn er stammt von zwei langjährigen und angesehenen Netzwerk- und BPF-Entwicklern: Alexei Starovoitov und Daniel Borkmann. Sie hatten die Unterstützung des langjährigen Kernel-Entwicklers David Miller, der den Netzwerk-Code von Linux betreut. Er witzelte bei der Annahme des Bpfilter-Fundaments für 4.18, dass der Wahnsinn jetzt beginnen könne („let the madness begin“). Greg Kroah-Hartman, einer der wichtigsten Linux-Entwickler, legte noch „Ja, das wird lustig“ nach („Yeah, this is going to be fun“).

Der Chef der Linux-News-Webseite LWN.net geht in einem Artikel zum Stand von Bpfilter bei 4.18 noch weiter: Er erwartet, der erweiterte User Mode Helper werde auch bei anderen Entwicklern auf Interesse stoßen, um Aufgaben auszulagern. Das ist wahrscheinlich, denn ähnlich wie bei Microkerneln kann das den Kernel entlasten, die Sicherheit verbessern und die Programmierung vereinfachen; ein zentraler Entwickler liebäugelte schon mit der Idee, Treiber für USB-Geräte mit Userspace-Modulen zu implementieren.

Der LWN.net-Autor führt zugleich aber an, man solle das Ganze bloß nicht Microkernel nennen, sonst würde es Leute womöglich aus der Fassung bringen. Damit spielt er auf eine 1992 in der Frühzeit von Linux geführte Debatte an, in der Minix-Erfinder Andrew S. Tanenbaum und Linux-Vater Linus Torvalds einige teilweise harsche Mails ausgetauscht haben. Auslöser war ein Statement von Tanenbaum, in dem er den monolithischen Linux-Kernel für obsolet erklärte, schließlich hätten Microkernel letztlich schon gewonnen.

Das neue Writecache Target im Device Mapper (DM) ist für Systeme gedacht, bei denen möglichst geringe Latenzen gefragt sind, wenn Datenbanken und ähnlich gelagerte Anwendungen verarbeitete Daten speichern. Um das zu erreichen, bindet das neue DM-Target persistente Speichermodule als Schreib-Cache ein, um die Daten später in weniger zeitkritischen Situationen auf die regulären Datenträger zu überführen; alternativ funktioniert das auch mit SSDs und somit ähnlich wie beim Schreiben mit SSD-Caching-Lösungen wie Bcache und DM-Cache. Die beschleunigen auch das Lesen von häufiger genutzten Daten. Das neue DM-Target implementiert indes bewusst keinen Lese-Cache, schließlich nutzt der Kernel den Arbeitsspeichers ja ohnehin automatisch als solchen.

Eine Optimierung an Btrfs Send/Receive kann die Performance in bestimmten Situationen deutlich verbessern. (Bild: git.kernel.org – 0f96f517dcaa )

Leere Snapshots lassen sich bei Btrfs-Dateisystem jetzt mit einem simplen rmdir selbst ohne Root-Rechte entfernen. Über neue Schnittstellen können unprivilegierte Anwender jetzt Informationen zu Subvolumes abrufen (u. a. 1, 2, 3). Über die neuen Ioctl-Kommandos FS_IOC_FSGETXATTR und FS_IOC_FSSETXATTR lassen sich zudem verschiedene Dateiattribute anpassen. Eine Optimierung an Btrfs Send/Receive hat bei gezielten Tests zu einem dramatischen Performance-Zuwachs geführt: Das Entfernen eines großen Verzeichnisses dauerte statt rund 33 Stunden nur noch 2 Minuten. Das sind nur einige von vielen kleinen Änderungen, die es diesmal beim Btrfs gab.

Die von Ext4 und F2FS zur Verschlüsslung genutzte Fscrypt-Infrastruktur kann Daten nun mit den Algorithmen Speck 128 und 256 verschlüsseln, die Linux seit 4.17 unterstützt und wenig Overhead aufweisenden sollen (u. a. 1, 2). Im begleitenden Kommentar weist der langjährige Kernel-Entwickler Theodore 'tytso' Ts'o darauf hin, dass der von der NSA entwickelte Cipher als umstritten gilt (siehe u. a. Linux-Crypto-Post von Tomer Ashur und Wikipedia).

Der Spec Cipher gilt als umstritten. (Bild: git.kernel.org – fd59ccc53062 )

Laut Tytso sei der Speck-Support aber nur für die schwächsten Android-Geräte gedacht, bei denen die Alternative sonst wäre, Daten gar nicht zu verschlüsseln. In einer anderen Mail hat der bei Google arbeitende Tytso das noch konkretisiert: Der Algorithmus ziele auf "Die nächste Milliarde" von Android-Nutzern, die Google mit Geräten erreichen will, die weit unter 100 US-Dollar kosten.

Die Google-Mitarbeiter, die den Speck-Support bei 4.17 eingebracht hatten, erwähnten indes wenige Tage vor Fertigstellung von 4.18, Google wolle den Algorithmus jetzt doch nicht bei Android einsetzen. Das erwähnten Sie bei der Vorstellung des von ihnen entwickelten HPolyC, das Google stattdessen einsetzen will. Kurz darauf wurde noch vorgeschlagen, Speck samt des Fscrypt-Support wieder zu entfernen. Dazu ist es aber nicht gekommen.

Mit Version 4.18 schrumpft der Quellcode von Linux 4.18. Das allein ist ungewöhnlich, denn es passiert erst das vierte Mal in der Geschichte der modernen Linux-Entwicklung; noch ungewöhnlicher ist allerdings, dass auch 4.17 schon kleiner als sein direkter Vorgänger war.

Dass es zweimal hintereinander passiert, liegt keineswegs an neuen Arbeitsweisen, sondern schlicht und einfach am Zufall: Bei beiden Kernel-Versionen gab es Aufräumarbeiten, bei denen ein Entwickler einen Batzen Quellcode entfernt hat. Bei 4.17 traf es den Support für alte, offenbar von niemand mehr genutzte Prozessorarchitekturen. Bei 4.18 ist es vornehmlich dem Rauswurf des Cluster-Dateisystems Lustre zu verdanken, der die Kernel-Quellen um fast zweihunderttausend Codezeilen erleichtert hat.

Das vor allem beim High Performance Computing (HPC) eingesetzte Lustre hat durchaus noch Nutzer, daher dürfte es nach den Regeln der Linux-Entwicklung eigentlich gar nicht entfernt werden. In diesem Fall geht es aber doch, denn der Code steckte nur im Staging-Zweig, weil er nie die Qualitätsstandards der zuständigen Kernel-Entwickler erfüllt bat.

Staging ist ein vor allem für Treiber gedachter Sonderbereich des Kernels, der Entwickler helfen soll, mangelhaften Code im Rahmen der normalen Linux-Entwicklung auf Vordermann zu bringen. Beim Lustre hat aber aus verschiedenen, bei LWN.net näher erläuterten Gründen in den letzten Jahren nicht geklappt – unter anderem, weil die Lustre-Entwickler ihr Dateisystem auch nach der Aufnahme in den Kernel weitgehend losgelöst davon an anderen Stelle vorantreiben. Kurzfristig ist keine Besserung der Lage in Sicht, daher flog der Code jetzt raus, denn die Staging-Regeln erlauben das als Druckmittel. Der Schritt bringt so in Erinnerung: Im Staging-Zweig enthaltenen Funktionen oder Treiber können jederzeit verschwinden, daher sollte man genau abwägen, ob oder wie weit man sich auf diese verlassen will.

Lustre war nicht der einzige Rauswurf: Auch die Unterstützung für das Netzwerkprotokoll Novell IPX und das darauf aufbauende Netware Core Protocol File System (Ncpfs) mussten weichen. Diese zum Zugriff auf NetWare-Server von Novell genutzten Techniken waren bei Linux 4.16 in den Staging-Zweig verlagert worden, damit potenziell noch vorhandene Anwender den drohenden Rauswurf bemerken und Einspruch erheben konnten. Das hat in den zwei zwischenzeitlich verstrichenen Monaten aber niemand getan. Das zeigt: Wer sicher gehen will, dass von ihm benötigte Alttechniken nicht aus dem Kernel verschwinden, muss ein Auge auf die Linux-Entwicklung halten und regelmäßig testen, um gegebenenfalls rechtzeitig Laut geben zu können.

Unter den Änderungen am F2FS (Flash-Friendly File System) sind einige, die Performance-Probleme rund um das Melden freigewordener Speicherbereiche (Discard/Trim) beheben. Das soll vom Benutzer spürbare Wartezeiten vermeiden, wie sie einige F2FS einsetzende Andorid-Geräte gelegentlich zeigen.

Eine kleine Änderung soll mehr I/O-Operationen pro Sekunde (IOPS) ermöglichen. (Bild: git.kernel.org – e2d1f8a06e )

Zwischen den Patches am ATA-Subsystem ist eine kleine Anpassung, durch die der AHCI-Treiber statt 31 nun die maximal möglichen 32 Queues nutzt, wenn es NCQ-taugliche Datenträger anspricht. Bei Tests, wo die Zahl der Zugriffe (IOPS) den Flaschenhals bildete, konnte das die Performance um zirka drei Prozent verbessern.

Beim XFS gab es weitere Änderungen, um Dateisysteme in Zukunft im Betrieb prüfen und gegebenenfalls sogar reparieren zu können. Umbauten am Code zur Dateisystemvergrößerung legen zudem Grundlagen, durch die XFS letztlich Subvolumens unterstützen soll. Der Weg zu beiden Features ist aber noch weit, wie der XFS-Maintainer in einem der Merge-Commits mit den Erweiterungen betont (1, 2). Beide Features bauen auf den tiefgreifenden Umbauten an XFS auf, die seit Linux 4.8 im Rahmen der normalen Kernel-Entwicklung erfolgen.

Mit zahlreichen Änderungen am Block Layer stießen einige Grundlagen für Bcachefs zum Kernel. Dabei handelt es sich um ein noch junges Dateisystem, das aus der SSD-Caching-Lösung Bcache hervorgegangen ist. Dessen Entwickler arbeitet jetzt auf eine Integration in den offiziellen Kernel hin, nachdem er darüber jüngst auf einer Konferenz mit anderen Dateisystementwicklern gesprochen hat. Diese zeigten sich einer Aufnahme gegenüber nicht abgeneigt, wie LWN.net berichet – wie gewohnt wollen sie den Code aber vorher begutachten.

Einige weitere Änderungen rund um den Support für Storage-Hardware finden sich in den Pull-Requests für die Subsysteme Libnvdimm, MDT und SCSI. Weitere Änderungen an Dateisystemen und Speicherlösungen nennen die Kommentare der wichtigsten Merge-Commits von Ceph, CIFS, Device Mapper, DLM, Ext4, FUSE, GFS2, MD, NFS, NFSd, UDF, UBI & UBIFS und VFS (work.aio).

Der neue Treiber Net-Failover ermöglicht eine von Hypervisor kontrollierte Live-Migration von Virtual Machines (VMs), die Teilfunktionen des im Wirt steckenden Netzwerkchips verwenden (u. a. 1, 2, 3). Die Nutzung einer via SR-IOV bereitgestellten Virtual Function (VF) der NIC im Host bietet Performance-Vorteile – die Assoziation mit echter Hardware blockiert aber den Umzug einer VM zur Laufzeit, sofern der Admin nicht mit einem weiteren Netzwerkinterface sowie Bonding oder Teaming im Gast trickst.

Der Net-Failover-Treiber ermöglicht die Live-Migration von VMs, die Teilfunktionen der Netzwerk-Hardware im Host nutzen. (Bild: git.kernel.org – ba5e4426e80e )

Der neue Treiber ermöglicht die Live-Migration, indem er das VF-Gerät mit einer paravirtualisierten Virtio-Netzwerkschnittstelle des Hypervisors koppelt. Beide verwenden dieselbe MAC-Adresse, aber nur ein Interface wird aktiv genutzt. Beim Umzug wird die VF von der VM getrennt, woraufhin der Treiber automatisch zum Virtio-Interface wechselt. Die Netzwerkkonfiguration im Gast muss dabei nicht angepasst werden; auch Anwendungen sollen davon nichts mitbekommen, wenn man von Aspekten wie einer schlechteren Performance absieht. Dafür kann die VM anschließend auf einen anderen Host umziehen, wo wieder ein VF zugewiesen werden kann.

Das neue "TCP_ZEROCOPY_RECEIVE" ermöglicht Anwendungen, direkt auf empfangene TCP-Datenpakete zuzugreifen. Das erfordert zwar einen eigenen Codepfad in der Anwendung, kann beim Paket-Handling aber einen Kopiervorgang zwischen dem Speicherbereich des Kernels und dem der Anwendung vermeiden. Das erspart Prozessor und Arbeitsspeicher etwas Arbeit, was die Performance verbessert und Ressourcen für andere Aufgaben frei schaufelt. Empfangene Daten per Zerocopy zu erhalten klappt aber nur unter ganz bestimmten Bedingungen (u. a. einer MTU von 4K), die zwei Commit-Kommentare (1, 2) und zwei LWN.net-Artikel näher erläutern (1, 2) – das Ganze ist also etwas für Situationen, in denen Admins und Entwickler einiges an Arbeit zu investieren bereit sind, um die Performance zu steigern. Google macht das und verspricht sich viel davon, wie Notizen und eine Präsentation einer jüngst abgehaltenen Konferenz zeigen; bei seinen Bestrebungen nutzt das Unternehmen eine Library, um Anpassungen in Anwendungen zu vermeiden.

Viel Know-how und Programmierarbeit erfordert auch das neue "AF_XDP". Über dieses Feature können Anwendungen bei der Netzwerk-Schnellstraße XDP (Express Data Path) andocken, die bei Linux 4.8 eingeführt wurde. Sie ist dem normalen Netzwerkstack vorgeschaltet und erledigt einige Dinge (etwa Drop, Forward und Rewrite) direkt selbst. Für komplexere Aufgaben können Programme sich nun über AF_XDP beim XDP einklinken, wie es ähnlich über die Programmierschnittstelle AF_PACKET beim normalen Netzwerkstack funktioniert.

Letztlich soll AF_XDP eine schnellstmögliche Verarbeitung von Netzwerkpaketen ermöglichen, die unter dem Oberbegriff "High Performance Packet Processing" läuft und beispielsweise für flexibel programmierbare Netzwerk-Infrastruktur wichtig ist (Software Defined Networking/SDN). Bislang wird sowas häufiger mit Lösungen wie dem Data Plane Development Kit (DPDK) realisiert, die im Userspace arbeiten und den Kernel komplett ausbooten. Bei AF_XDP hingegen bleibt der Kernel involviert und behält die Oberhand.

Letztlich soll DPDK dadurch auch auf AF_XDP aufbauen können. Das erreicht wohl nicht ganz die bislang mit DPDK mögliche Performance, aber eine ähnliche, die für viele Einsatzzwecke ausreicht. Dafür können DPDK-spezifische Netzwerktreiber im Userspace entfallen; außerdem müssen sich Entwickler nicht mehr selbst um Sicherheitsbelange kümmern, die normalerweise der Kernel für sie erledigt.

AF_XDP bietet bei 4.18 alle wesentlichen Grundfunktionen, allerdings stehen Änderungen zur noch effizienteren Verarbeitung schon zur Aufnahme bereit; darunter Zerocopy-Support für AF_XDP, der schon so gut wie fertig ist. Weitere Details zu AF_XDP erläutern ein Commit mit Dokumentation und Programmierbeispiel, die Kommentare einiger Commits (u. a. 1, 2) und ein Artikel bei LWN.net.

Der Kernel bietet jetzt Eingriffspunkte bei Sockets, um von der BPF Virtual Machine ausgeführte Programme auszuführen, wenn eine Anwendung den Syscall sendmsg() verwendet. Das lässt sich etwa nutzen, um IP-Adressen ausgehender Pakete umzuschreiben.

Programmierer können das neue BPF Type Format (BTF) zum Speichern von Metadaten nutzen, die beschreiben, was die von Programmen angelegte Variablen oder Maps speichern. Dieser Weg lässt sich bei 4.18 nutzen, um in Maps gespeicherte Inhalte in Textform auszugeben (u. a. 1, 2). In Zukunft soll auch das Untersuchungswerkzeug bpftool das vom CTF (Compact C-Type format) abgeleitete Format nutzen können, um Daten übersichtlicher auszugeben; angedacht ist auch, Dwarf-Informationen in BTF zu überführen.

Auch auf 32-Bit-x86-Systemen kann der Kernel jetzt BPF-Code über einen Compiler mit JIT (Just in Time) übersetzen, um BPF-Code nicht indirekt über den BPF-Interpreter, sondern mit nativen Maschinenbefehlen auszuführen.

Selective Acknowledgment (SACK) Compression soll das Versenden von Statuspaketen reduzieren, die Staus in Netzwerken nur noch verschlimmern. (Bild: git.kernel.org – 5d9f4262b7ea )

Bessere WLAN-Performance und weniger Staus in Netzwerken verspricht die neue Selective Acknowledgment (SACK) Compression im TCP-Stack. Durch sie verzögert der Kernel das Senden von SACK-Paketen, um diese dann komprimiert zu verschicken, falls sie denn überhaupt noch nötig sind. SACK-Pakete müssen verschickt werden, wenn ein TCP-Packet außer der Reihe eingeht. Das kann passieren, wenn es sich im Netzwerk gerade staut – gerade dann würden SACK-Pakete aber "Öl ins Feuer gießen", wie der Entwickler im Commit-Kommentar erläutert. Insbesondere bei WLANs, aber keineswegs nur dort soll das ein größeres Problem sein, das die Änderung mildert.

Der Kernel-Code kann die Datenverschlüsselung mit 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 erweitert wurde. Damit das Auslagern funktioniert, muss auch der Netzwerktreiber das Ganze unterstützen; bei 4.18 beherrscht das nur der Treiber mlx5e (1, 2).

Darüber hinaus gab es noch allerlei andere Änderungen am Netzwerkcode, die ein Kommentar zum wichtigsten Merge Commit dieses Subsystems anreißt. Darunter sind unter anderem Support für Shifted Portmap Ranges bei NAT oder Unterstützung für Connlimit (Connection Limit) und Extended ACK Reporting in Nftables.

Der Intel-AMD-Kombiprozessor mit Vega-M-Grafik. (Bild: Intel)

Linux 4.18 unterstützt den Grafikprozessor AMD Radeon RX Vega M (u. a. 1, 2, 3, 4). Das ist die auch als "Kabylake-G" bekannte GPU der Intel-AMD-Kombiprozessoren, die zur Core-i-8000er-Serie gehören. Solche stecken etwa im Notebook Dell XPS 15 2-in-1 (9575) oder dem Mini-PC Intel NUC8I7HVK, die c't beide jüngst getestet hat.

Die meisten Änderungen zum Support des Vega M erfolgten beim Treiber Amdgpu. Der stellt wie gewohnt viele Grundfunktionen zur 3D-Beschleunigung, auf die der OpenGL-Treiber Radeonsi und der Vulkan-Treiber Radv zurückgreifen, die aktuelle Mesa-Versionen mitbringen. Laut Berichten soll die Kabylake-G-Grafik daher mit frisch ausgestatteten Distributionen wie Fedora 28 funktionieren, sofern man diese mit dem neuen Linux und der Firmware für Vega M versorgt.

Der für aktuelle AMD-GPUs zuständige Amdgpu-Treiber unterstützt nun auch eine neue, noch nicht angekündigte Generation der Vega-GPU, die in den Kernel-Quellen unter dem Codenamen "Vega20" läuft (u. a. 1, 2, 3). Auch das im August erwartete Mesa 18.2 wird diese GPU unterstützen. Laut Spekulationen handelt es sich dabei um eine überarbeitete Fassung der Vega10-GPU, die auf AMDs derzeit leistungsfähigster Grafikkarte Radeon RX Vega 64 sitzt. Statt PCIe 3.0 wird der Chip wohl das im Herbst 2017 spezifizierte PCIe 4.0 beherrschen, wenn man den Änderungen am Amdgpu-Treiber des Kernels glauben darf, denn diese bringen Unterstützung für den schnelleren Übertragungsstandard. Gerüchten zufolge soll die GPU nicht mehr in einem 14-Nanometer-Prozess hergestellt werden, sondern mit einer 7-Nanometer-Fertigung.

Ferner gab es auch Anpassungen an Amdgpu, um die Stromsparfunktionen von Vega-GPUs stärker zu nutzen sowie Taktfrequenzen und Spannungsversorgung beeinflussen zu können (u. a. 1). Außerdem kann der Amdgpu-Treiber den Grafikkern der als Ryzen G vermarkteten Raven-Ridge-Prozessoren jetzt abschalten, um Strom zu sparen.

Der das Rechnen mit Radeon-GPUs ermöglichende Treiber Amdkfd beherrscht dank einer Erweiterung an Amdgpu jetzt User Pointer (userptr). Mit dieser seit Linux 3.16 prinzipiell unterstützten Funktion lässt sich ein Kopieren von Daten in den Speicherbereich des Kernels vermeiden, wenn der Grafikchip auf Informationen zugreifen soll, die Userspace-Programme im Arbeitsspeicher hinterlegt haben.

Linux 4.18 unterstützt AMDs GPU Computing Platform "ROCm" jetzt auch auf den aktuellen High-End-GPUs der Vega-Serie. (Bild: rocm.github.io )

Darüber hinaus lässt sich AMDs GPU-Computing-Lösung ROCm jetzt auch mit GPUs der Vega-Generation für allgemeine Berechnungen nutzen (u. a. 1, 2, 3, 4, 5, 6. 7). Vergleichbare Umbauten zur Unterstützung einiger Vorgänger von Vega ist in die vorangegangenen Kernel-Versionen eingeflossen. Das macht es leichter, alle Komponenten zum GPGPU (General-purpose computation on Graphics Processing Units) mit modernen Radeon-GPUs einzurichten. AMD hat aber noch etwas Arbeit vor sich, bis Distributionen alles benötigte von Haus aus mitbringen und automatisch konfigurieren, denn einige für ROCm benötigte Erweiterungen müssen erst noch in offizielle Releases von Software wie LLVM einfließen.

AMD arbeitet indes an einem weiteren und weniger komplexen Weg, der GPGPU mit Radeon-GPUs ermöglicht. Diesen entwickelt und nutzt AMD bislang nur beim AMDVLK-Projekt und dem proprietären Treiberpaket AMDGPU-PRO. Anders als ROCm funktioniert dieser auf Amdgpu aufbauende Ansatz auch, wenn GPU oder Grafiktreiber keine Heterogeneous System Architecture (HSA) beherrschen. Diese Lösung ist daher für den Heimgebrauch vielfach ausreichen, aber eher uninteressant für Einsatzgebiete wie Deep Learning, KI-Anwendungen oder Rechnen auf Servern.

Der Linux-Kernel bringt jetzt den Grafiktreiber V3D mit, der die als VideoCore V (VC5) und VideoCore VI (VC6) bekannten Grafikeinheiten von Broadcom unterstützt. Sie sind die Nachfolger des Broadcom VideoCore IV (VC4), der in den SOCs sitzt, den alle bisher erhältlichen Raspberry-Pi-Modelle verwenden. Mainstream-Distributionen wie Debian oder Fedora unterstützen deren GPU mit VC4 genannten Treibern in Linux-Kernel und Mesa. Diese stammen größtenteils von Eric Anholt, den Broadcom extra zum Schreiben eines quelloffenen Grafiktreiberstacks für Raspis angeheuert hat. Anholt hat auch den jetzt integrierten V3D-Treiber geschrieben. Schon in der Frühphase der Treiberentwicklung hat das zu Gerüchten geführt, zukünftige Raspis würden eine der durch V3D unterstützte VideoCore-Einheit erhalten.

Der neue Grafiktreiber hieß ursprünglich VC5, wurde von Anholt aber in V3D umbenannt, als Unterstützung für VC6 hinzukam. Auf dem Kernel-Grafiktreiber baut ein ebenfalls V3D genannter Mesa-Treiber auf, der 3D-Beschleunigung via OpenGL ermöglicht. Ein Vulkan-Treiber ist noch in Entwicklung. Dieser durchgängig freie Treiberstack unterstützt unter anderem den SOC BCM7251, den Broadcom für den Einsatz in Settop-Boxen zum hochauflösenden Fernsehen ausgelegt hat; er eignet sich auch für den BCM7278, der laut einem Kernel-Entwickler den für UltraHD-Fernseher ausgelegten BCM7445 beerbt.

Volta: GV100-GPU mit 16 GByte HBM2-Speicher (Bild: Martin Fischer )

Der Kernel-Grafiktreiber Nouveau unterstützt jetzt rudimentär die als Volta oder GV100 bekannte GPU, die unter anderem auf der Nvidia-Profigrafikkarte Quadro GV100 sitzt (u. a. 1, 2, 3, 4)

Der für Intels moderne GPUs zuständige Treiber i915 weiß jetzt das Pixelformat NV12 zu handhaben, das unter anderem bei Videoplayern beliebt ist und von Kamerachips gerne zur Datenauslieferung verwendet wird. Darüber hinaus erhielt der HDCP- und DisplayPort-Support des Treibers eine Reihe von Detailverbesserungen und Fehlerkorrekturen. Die Entwickler haben zudem die Unterstützung für die GPU von Intels Icelake-Prozessoren verbessert, die Linux seit 4.17 rudimentär unterstützt; der Code gilt nach wie vor aber als unfertig und nicht produktionsreif.

Darüber hinaus gab es noch eine Menge weiterer Änderungen am Direct Rendering Manager (DRM) und seinen Grafiktreibern, die Kommentare zu zwei Git-Merges nennen (1, 2). Darunter ist beispielsweise Support für Bildschirmausgaben mit einem Seitenverhältnis von 64:27 und 256:135, die HDMI 2.0 definiert.

Linux hat jetzt einen Treiber für ein "Xen PV Display Frontend". Ein als regulären Xen-Gast (in Xen-Jargon eine "DomU") laufender Kernel kann damit ein DRM/KMS-Device bereitstellen, wie es normale Grafiktreiber tun, damit Kernel und Programme darüber Text- oder Bilddaten ausgeben können. Diese Inhalte übergibt der Frontend-Treiber an ein Backend im Betriebssystem, das die Xen-Virtualisierung kontrolliert (die "Dom0"). Dies Backend kann die Bildausgaben des Gastes direkt über die echte Grafik-Hardware ausgeben oder in einem Fenster unter dem Wayland-Compositor Weston darstellen. Der Datenaustausch zwischen Front- und Backend erfolgt dabei mit Paravirtualisierung, um Overhead zu vermeiden.

Der Ansatz ist eine von mehreren neuen Paravirtualisierungstechniken zur Interaktion zwischen Gast und Host, an denen die Xen-Entwickler seit einer Weile verstärkt arbeiten. Diese ist für die Virtualisierungsart PVH gedacht, die Linux seit 3.14 prinzipiell unterstützt und jüngst mit Xen 4.11 weiter in den Fokus gerückt ist. Diese Betriebsart arbeitet ohne Qemu und funktioniert nur mit Betriebssystemen, die PVH beherrschen; bei diesem Modus nutzt Xen sehr stark Paravirtualisierung, macht sich für einige Aufgaben aber Hardware-Virtualisierungstechniken zunutze, um die Performance zu verbessern.

Die Betriebsart PVH arbeitet ohne Qemu und macht sich Hardware-Virtualisierung zu nutze. (Bild: wiki.xen.org )

Neben dem Grafik-Frontend-Treiber für Xen stieß bei 4.18 auch noch ein Frontend-Treiber zum Kernel, den Gäste zur Sound-Ausgabe nutzen können (u. a. 1, 2,3). Einige andere Frontend-Treiber für Xen sind schon in vorangegangene Linux-Versionen eingeflossen.

Der Linux-Kernel unterstützt jetzt die im Herbst 2017 mit USB 3.2 definierte Dual-Lane-Übertragung, die die Transferrate für USB-C-Verbindungen auf 20 GBit/s verdoppelt. Diese SuperSpeed+-Betriebsart verwendet das zweite der Adernpaare von USB-C-Kabel, das eine Übertragung mit 10 GBit/s pro Richtung ermöglicht. USB 3.1 Gen 2 hat lediglich eines der Adernpaare verwendet; das zweite blieb so für den Alternate-Mod frei, um darüber etwa Thunderbolt-3-Hardware oder einen Bildschirm per DisplayPort anzusteuern.

Der Hardware-Monitoring-Treiber K10temp kann jetzt die CPU-Temperatur auch bei AMD-CPUs der Generationen Stoney Ridge and Bristol Ridge ausgeben. Die Treiber für Eingabegeräte unterstützen jetzt den Valve Steam Controller. Einige auch im heise-Forum aktive Entwickler haben Support für Amiga-Komponenten eingebracht. Der nach einem Rauswurf jetzt erneut integrierte Zorro-Treiber etwa unterstützt SCSI-Controller mit NCR53C9x-Chip, die unter anderem bei den SCSI-Adaptern von phase5 zum Einsatz kamen. Der neue Netzwerkteiber Xsurf100 sorgt für Support der Netzwerkkarte X-Surf 100 des deutschen Hardware-Herstellers Individual Computers.

Das sind nur einige Beispiele für den abermals erweiterten Hardware-Support, denn auch bei 4.18 haben die Kernel-Entwickler Dutzende neue Treiber aufgenommen und viele existierende verbessert. Dadurch unterstützt Linux 4.18 über 250 Geräte oder Geräteklassen mehr als sein Vorgänger; bei 42 davon handelt es sich um PCI/PCIe-Geräte, wie die Datenbanken der Linux Kernel Driver DataBase (LKDDb) zeigen. All diese Verbesserungen hier zu erläutern, würde den Rahmen sprengen, daher erwähnt dieser Text nur einige exemplarisch. Viele weitere nennen die Kommentare der wichtigsten Git-Merges in den Subsystemen Backlight, Driver Core, Fbdev, GPIO, HID, Hwmon, I2C, Input, IPMI, LED, Media/V4L, MFD, MMC, Platform, Platform Chrome, RDMA, RTC, Sound, Staging, TTY, USB und Watchdog.

Linux 4.18 ist die erste Kernel-Version, die die Bastelcomputer Raspberry Pi 3B und 3B+ von Haus aus halbwegs ordentlich unterstützt. Das ist unter anderem Patches zu verdanken, die Unterstützung für den im März vorgestellten Raspberry Pi 3B+ nachrüsten (u. a. 1, 2, 3). Dank einer weiteren Änderung weiß der Kernel jetzt auch dessen seit 4.17 prinzipiell unterstützten GPIO-Expander anzusprechen, der auch auf dem Raspberry Pi 3B (ohne Plus) sitzt. Dadurch lassen sich nun die für WLAN, Bluetooth, HDMI-Erkennung und Aktivitäts-LED benötigten GPIOs steuern. Beim LAN78XX-Treiber für den Gigabit-Ethernet-Controller des B+ lauern aber wohl noch mehr Bugs als gewohnt, wie ein an den Änderungen beteiligter Entwickler uns wissen ließ.

Linux 4.18 bringt deutlich bessere Unterstützung für die beiden Varianten des Raspberry Pi 3B.

Diese Fortschritte sind vor allem für Distributionen wie Debian, Fedora & Co. wichtig, die Raspis mit ihren regulären ARM- beziehungsweise ARM64-Kerneln unterstützen wollen. Für Nutzer spezialisierter Raspi-Distributionen wie Raspbian sind die Verbesserungen im offiziellen Linux-Kernel nur relevant, wenn sie einen Mainline-Kernel einsetzen möchten: Diese Distributionen verwenden spezielle für Raspis gebaute Kernel, bei denen die Entwickler zahlreiche Raspi-spezifsche Umbauten und Erweiterungen vorgenommen haben. Die fließen vielfach nur träge in offizielle Linux-Versionen ein, weil die Patches gar nicht eingereicht werden oder die Qualitätsansprüchen der Entwickler um Linus Torvalds nicht erfüllen. Manchmal ist das Missfallen so groß, dass unabhängige Programmierer die von Raspbian & Co. verwendeten Erweiterungen und Treiber verwerfen und von Grund auf neuen Code schreiben, um Komponenten der verschiedenen Raspis zu unterstützen.

Der bessere Raspi-3-Support stieß mit Erweiterungen an den ARM Device Trees zum Kernel, die auch Support für den Steam Link von Valve und die Nintendo NES/SuperNES Classic Edition gebracht haben. Bei einigen dieser und anderer erstmals unterstützter SOCs bedeutet das aber nur, dass der Linux-Kernel jetzt irgendwie mit diesen Plattformen klarkommt; zum Alltagseinsatz fehlen jedoch oftmals Treiber für wichtige oder weniger wichtige Komponenten.

Das gilt auch für den ebenfalls neuen Support für den Qualcomm SDM845, der auch als Snapdragon 845 bekannt ist. Olof Johansson erwähnt beiläufig, dass man damit noch nicht viel machen könne, allerdings werde Support für USB, GPU und andere Komponenten langsam eintrudeln; wenn das so weiter gehe, werde der offizielle Kernel diesen SOC bald ziemlich gut unterstützen. Linus Torvalds wurde da gleich hellhörig und fragte, ob das nicht der SoC einiger mit Windows ausgelieferten Notebooks mit ARM-Prozessor sei. Solche halbwegs leistungsstarken und mit x86-Geräten vergleichbare Notebooks wünscht er sich schon länger, wie er 2014 in einem Interview mit c't verriet.

Linus Torvalds hofft auf Notebooks mit ARM-Prozessoren, die normalen (x86-)Notebook ähneln. (Bild: LKML-Archiv bei lore.kernel.org )

Daraufhin entstand eine Mail-Wechsel, in dem Heiko Stübner anmerkte, auch das mit Rockchip RK3399 ausgestattete Samsung Chromebook Plus dürfte die Wünsche von Torvalds halbwegs erfüllen. Johansson widersprach nicht, erwähnte aber, dass die Situation bei Grafiktreibern beim Snapdragon 845 besser sei, denn für deren Adreno-GPUs gibt es mit Freedreno einen quelloffenen Grafiktreiberstack; bei Geräten mit dem SOC habe er zudem berechtigte Hoffnungen, dass sich Secure Boot ausschalten lasse.

Nach vielen Jahren Entwicklungsarbeit bringt Linux 4.18 erstmals einen Funktionsaufruf für "Restartable Sequences" mit. Der Syscall ist für mit mehreren Threads arbeitende Anwendungen gedacht, die mit möglichst wenig Overhead eine Datenstruktur verändern wollen. Mit den Restartable Sequences gelingt das ohne klassisches Locking, indem der Userspace-Code bei der Ausführung darauf spekuliert, dass ihm kein anderer Thread in die Quere kommt; falls das doch passiert, fängt er nochmal von vorn an.

Der Programmierer kann das Verfahren über den neuen Syscall nutzen. Dieser legt einen von Anwendung und Kernel geteilten Speicherbereich an, bei dem der Kernel die Zugriffe durch seine "Per-CPU"-Funktion sichert. In dem geteilten Speicherbereich hinterlegt der Entwickler eine Sequenz von Instruktionen, die eine CPU-lokale Datenstruktur verändert – zum Beispiel ein Element in eine Linked List einfügt. Die eigentliche Änderung darf erst mit letzten, nicht unterbrechbaren (also "atomaren") Instruktionen dieser Sequenz erfolgen. Während der Ausführung des Programmcodes kann allerdings ein anderer Thread auf dieselbe Datenstruktur zugreifen und so die Restartable Sequence unterbrechen. Wenn das passiert, springt der Kernel in den Abbruch-Teil der Restartable Sequence; das Userspace-Programm muss diesen Fall dann handhaben und kann die Sequenz gegebenenfalls neu starten.

Auszug einiger Testergebnisse des Entwicklers der Restartable Sequences. (Bild: git.kernel.org – d7822b1e24f2 )

Im Idealfall ist so ein Restart der Sequenz aber nicht nötig, sodass die Änderung erfolgt, ohne das der normale Locking-Overhead anfällt. Das kann die Performance in bestimmten Fällen um ein Vielfaches steigern. Das zeigen Messungen des vor allem durch seine Arbeit an LTTng (Linux Trace Toolkit Next Generation) bekannten Entwicklers, der jahrelang auf die Integration der Restartable Sequences hingearbeitet hat. Ihm zufolge läuft ein "Per-CPU statistic counter increment" genannter Micro-Benchmark auf einem 32-Bit-ARM-Prozessor 11 mal schneller, auf einem 64-Bit-x86-System rund 7,7 mal so schnell. Der Commit-Kommentar nennt Testergebnisse spezieller Aufgaben, bei denen sich noch größere Vorteile zeigen; er erwähnt aber auch einen Praxistest von Facebook, bei dem der Gesamtvorteil im einstelligen Prozentbereich lag.

Der Kernel unterstützt Restartable Sequences bislang im Architekturcode für ARM, MIPS, Powerpc und x86. Wie man diesen begrenzten atomaren Kontext für Userspace-Programme verwendet, erläutert ein Kommentar im Kernel-Code. Ein im letzten Herbst veröffentlichter LWN.net-Artikel liefert einige Hintergründe zum Ganzen; nach dessen Publikation wurde die Implementation aber nochmal verändert, wodurch die dort erwähnten "ops vectors" wieder vom Tisch sind.

Der Control Group (Cgroup) Memory Controller bietet jetzt den Parameter memory.min, über den der Admin noch zuverlässiger als bei memory.low sicher stellen kann, dass der Prozessgruppe mindestens die im Parameter festgelegte Arbeitsspeichermenge zur Verfügung steht.

Ftrace kann durch die neuen "trace_marker trigger" Aufgaben ausführen (etwa Histogramme erzeugen), wenn bestimmte Umgebungsbedingungen eintreten.

Neu sind auch die "Power Domain Performance Levels", die das Powermanagement-Subsystem in die Lage versetzen, das Performance/Stromsparniveau des ganzen Systems samt seiner Peripherie-Geräte zu regeln. Diese bei LWN.net näher erläuterte Erweiterung ist unter anderem für SOCs wichtig, bei denen mehrere Komponenten zusammenhängen und daher beispielsweise koordiniert heruntergetaktet oder ausgeschaltet werden müssen, um die Leistungsaufnahme zu reduzieren.

Ferner gab es einige bei LWN.net erläuterte Umbauten (u. a. 1, 2), um 32-Bit-Linux-Kernel Jahr-2038-fest zu machen; abgeschlossen sind diese Arbeiten aber nach wie vor nicht.

Weitere Informationen zu den architekturspezifischen Änderungen nennen die wichtigsten Merge-Commits am Code für ARM (Core, SOC [1, 2], SOC DT, SOC Drivers), ARM64, m68k, m68knommu, microblaze, MIPS, PowerPC, RISC-V, S390, x86 (Boot, Cache, DAX, Debug, Hyperv, RAS). Änderungen rund um die Infrastruktur erwähnen Merge-Commits für ACPI (1, 2), Core RCU, Char, Cgroups, DMA Mapping, Device Tree, Dokumentation, EDAC, EFI, Kbuild (1, 2), Kconfig, KVM (1, 2), Locking Core, PCI, Printk, Perf (1, 2), Power Management (1, 2), IRQ, IOMMU, Scheduler, Selftests, Siginfo, Thermal Core, Thermal Soc, Timer, Trace, VFIO, Vhost. Das sind übrigens nur jene Merges, die der Autor aus dem ein oder anderen Grund für verlinkenswert hielt, weil sie für manche Leser relevante Informationen enthalten. Einige Dutzend andere Merges rund um Architektur oder Infrastruktur haben diese Hürde nicht geschafft. Das gleiche gilt auch für andere Aufzählungen dieser Art, die dieser Text enthält.

Monate nach den Korrekturen für 64-Bit-x86-Systeme schützt jetzt auch der für 32-Bit-ARM-Kerne zuständige Linux-Code vor der ersten (u. a. 1, 2) und zweiten (u. a. 1, 2, 3, 4) Variante der Prozessorsicherheitslücke Spectre, die zu Jahresbeginn publik wurde. So lange hätte es nicht dauern müssen, denn ein ARM-Mitarbeiter hatte bereits in den ersten Wochen des Jahres Patches mit Gegenmaßnahmen veröffentlicht. Einige Distributionen und Hersteller von Embedded-Linuxen haben solche Patches auch integriert. Der zuständigen Subsystembetreuer Russell King hat sie aber erst zurückgewiesen und eine Weile links liegen gelassen, bevor er sie schließlich grundlegend umgeschrieben und jetzt integriert hat. Bei Anwendern von Mainstream-Kerneln trudeln sie daher erst rund sieben Monate nach Bekanntwerden der Lücken ein.

(Bild: Google+-Profilfoto von Russell King )

Die Verzögerung ist offenbar eine Folge von Differenzen mit King. Der war bekanntermaßen lange als ständiger Contractor für ARM tätig und ist in der Maintainers-Datei in den Kernel-Quellen als einziger Betreuer des "ARM Port" verzeichnet – also dem Kerncode zur Unterstützung von 32-Bit-ARM-Prozessorkernen. Ende März, kurz vor der Fertigstellung von Linux 4.16, hat King den Pflegestatus allerdings von "Gewartet" (Maintained) auf "gelegentliche Korrekturen" (Odd Fixes) geändert. Im begleitenden Kommentar betonte King, ARM bezahle ihn seit Anfang des Jahres nicht mehr für die Arbeit am ARM-Port. Die Pflegearbeit habe für ihn nun eine niedrigere Priorität. Der Code bekomme keine kommerzielle Unterstützung und werde fortan durch Freiwillige betreut.

Das ist Kings Sichtweise und Außendarstellung, die dabei geholfen hat, dass ARM ihn zumindest zur Integration des Spectre-Schutzes nochmal als Contractor angeheuert hat. ARM hat den 32-Bit-ARM-Port im Linux-Kernel nämlich keineswegs aufgegeben: Neben den ersten Gegenmaßnahmen haben ARM-Mitarbeiter in den vergangenen Monaten auch noch zahlreiche andere Änderungen für dieses Subsystem eingereicht. Der Status "Maintained" wäre daher in der Maintainers-Datei normalerweise allemal adäquat. Aus Kernel-Kreisen war zu hören, mehrere Entwickler wären auch nicht abgeneigt, King zu unterstützen oder die Betreuung des ARM-Ports ganz zu übernehmen; einer der Kandidaten arbeitet sogar bei ARM. Die Entwickler scheinen aber den offenen Konflikt mit King zu scheuen, der die Betreuung offenbar nicht abgeben will (siehe u. a. 1, 2); er scheint auch nicht daran interessiert zu sein, ein Entwicklerteam zu bilden, dessen Mitglieder sich gemeinsam um den Code kümmern; solch ein Modell wird beim Kerncode für ARM64- und x86-Systeme erfolgreich praktiziert.

Beim Zusammenspiel zwischen King und anderen Entwicklern hakt es schon seit einer ganzen Weile häufiger. (Bild: LKML-Archiv bei lore.kernel.org )

Maintainer-Wechsel erfolgen normalerweise einvernehmlich, daher wird das Problem wohl bleiben, bis irgendwas passiert, das dafür sorgt, dass sich King rührt oder Torvalds einschreitet. Bis dahin bleibt abzuwarten, ob die Differenzen noch weitere Verzögerungen auslösen, wie es sie beim Spectre-Schutz gab. Ohnehin sind die Schwierigkeiten nicht wirklich neu, sondern nur auf einer neuen Stufe angelangt: Entwickler, die in ihrer Freizeit oder bei anderen Firmen am Kernel-Code für 32-Bit-ARM-Kerne arbeiten, haben schon häufiger offen oder hinter vorgehaltener Hand über Probleme mit King geklagt; in den Archiven der Entwicklermailinglisten finden sich allerlei Mails, die Schwierigkeiten bei der Zusammenarbeit mit King zeigen.

Auf die Unterstützung neuer SoCs und Plattformen mit 32-Bit-ARM-Kernen dürfte das Ganze indes keinen sonderlichen Einfluss haben: Den SoC-Support samt der Device Trees betreut das "ARM Sub-Architectures Team", dessen Aushängeschilder Arnd Bergmann (derzeit: Linaro) und Olof Johansson (Facebook) sind.

Der Kernel-Code für 64-Bit-ARM-Kerne ist deutlich weiter, denn der schützt jetzt auch vor der im Mai publik gewordenen Prozessorlücke Spectre v4 (1, 2, 3, 4, 5). Die dafür zuständigen Änderungen stammen von ARM, dessen Mitarbeiter den ARM64-Code selbst betreuen. ARM-Entwickler haben für 4.18 auch eine Optimierung für die 64-Bit-Virtualisierung mit KVM und zahlreiche andere für ARM64 wichtige Änderungen beigesteuert.

Auch bei den Spectre-Gegenmaßnahmen für andere Architekturen gab es Finetuning. Einige der Patches verbessern etwa den Spectre-v4-Schutz bei AMD-Prozessoren (1, 2, 3, 4). Zudem wurden weitere Codestellen gegen Spectre v1 abgesichert.

Der 32-Bit-x86-Code von Linux bringt indes nach wie vor keine Gegenmaßnahmen für Meltdown mit. Dafür zuständige Patches wurden kürzlich erneut zur Begutachtung gestellt. Torvalds zeigte sich dabei offen für die Integration, beklagt aber, dass der Code nur wenig getestet werde, da die meisten Kernel-Entwickler mittlerweile 64-Bit-Linux einsetzen. Sofern sich bei Review und Tests keine größeren Probleme zeigen, dürfte der Schutz dann wohl in 4.19 einziehen.

In einem Container definierte Anwender dürften dort jetzt Dateisysteme per FUSE (Filesystem in Userspace) mounten, wenn sie im Container denn Root-Rechte haben und der Admin das erlaubt (1, 2, 3, 4). Prinzipiell bringt der Kernel jetzt sogar alles Wesentliche mit, damit Root-Anwender eines Containers auch Dateisysteme wie Btrfs, Ext4, FAT oder XFS einhängen könnten; solche werden nicht wie bei FUSE durch Userspace-Programme gehandhabt, sondern durch Kernelcode. Der aber ist vielfach nicht oder nur bedingt gegen mutwillig beschädigte Dateisystemstrukturen abgesichert. Das Einbinden solcher Dateisysteme bleibt daher untersagt. Ein Angreifer könnte sonst womöglich im Container ein Image mit gezielt manipulierten Dateisystemstrukturen per Loop-Mount einhängen, um den Kernel so aus dem Tritt zu bringen, dass der Bösewicht den Host übernehmen kann. Aufgrund ähnlicher Gefahren hängen manche Distributionen auch USB-Sticks nicht automatisch ein, schließlich könnte ein Angreifer auch dessen Dateisystemstrukturen gezielt manipuliert haben. Die Ext4-Entwickler nehmen dieser Tage aber mehr und mehr Änderungen vor, um die Gefahr zu reduzieren. Details zum Ganzen erläutert ein Artikel bei LWN.net.

Weitere Neuerungen rund um Sicherheit nennen die Kommentare in den wichtigsten Git-Merges der Subsysteme AppArmor, Audit, Integrity und Security. Unter den Neuerungen am Crypto-Subsystem war Support für den Kompressionsmechanismus Zstandard (zstd) (u. a. 1), den andere Subsysteme schon länger unterstützen. Neu ist auch eine Implementation der Verschlüsselungsalgorithmen AEGIS (u. a. 1, 2) und MORUS (u. a. 1, 2, 3). Darüber hinaus gab es noch einige Umbauten, um Overflow besser zu erkennen (1, 2).

Mit der Freigabe von Linux 4.18 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 4.19 vorbereitet haben. Darunter beispielsweise Support für den nächsten WLAN-Standard IEEE 802.11ax, der WLAN-Übertragungen um Faktor vier beschleunigen soll. Die dazu nötigen Erweiterungen stammen von Intel-Entwicklern, die auch gleich einen WLAN-Treiber um Unterstützung für einen neue, wohl Intel Wireless-AX 22560 genannte Serie von WLAN-Chips erweitern, die den Funkstandard nutzt.

Unabhängig von Mediatek arbeitende Entwickler wollen einen Treiber beisteuern, der Mediateks WLAN-Chips der Reihen MT76x0U und MT76x2u unterstützt. Linux soll dadurch in Zukunft von Haus aus einige Varianten der USB-WLAN-Sticks AVM FRITZ! AC 430 und 860 verwenden können.

Wie zuvor im Text bereits erwähnt sollen Treiber für den Qualcomm Snapdragon 845 zum Kernel stoßen, der in einigen mit Windows ausgelieferten ARM-Notebook steckt. Darunter auch ein Grafiktreiber für die in diesem SOC verbauten Adreno 630, der auch andere GPUs der A6XX-Familie unterstützt. Außerdem sollen endlich Maßnahmen in den 32-Bit-x86-Code (aka "x86-32") des Kernels einfließen, damit auch er vor der zu Jahresanfang publik gewordenen Prozessorsicherheitslücke "Meltdown" schützt.

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 Wochen dauert; in seltenen Fällen sind es auch mal nur sechs. Linux 4.19 erscheint daher wahrscheinlich am 15. oder 22. Oktober. Sofern Torvalds seine Andeutungen wahr macht, folgt zum Jahreswechsel dann Linux 5.0.

Wohl erst bei einem Nachfolger von 4.19 dürften die jüngst vorgestellten Patches zum Support der VPN-Lösung Wireguard einziehen. Einige Distributionen liefern den jungen Ansatz bereits mit, der bei einigen größeren Firmen bereits im Einsatz sein soll und in Kernel-Kreisen einiges Aufsehen erregt hat.

Der für WireGuard zuständige Netzwerkcode ist dabei vergleichsweise klein, was die Begutachtung durch die Entwickler des Netzwerksubsystems erleichtert. An anderer Stelle wird es dafür schwieriger, denn der Code greift auf eine neue Programmierschnittstelle im Crypto-Subsystem zurück. Die haben die WireGuard-Entwickler eigens für ihre VPN-Lösung geschaffen, weil ihnen das bisherige Crypto-API missfiel. Der Code ist deutlich umfangreicher als der von WireGuard selbst, daher wird das Review mehr Arbeit machen. Außerdem schauen die Entwickler bei Crypto-Code auch doppelt hin.

Ferner sind die Crypto-Subsystem-Entwickler nicht gerade darauf erpicht, eine zweite Programmierschnittstelle betreuen zu müssen. Einige mit der Materie vertraute Kernel-Entwickler sind der Aufnahme aber nicht abgeneigt, weil sich das bisherige API für manche Verwendungszwecke schlecht eignen soll; das neue deckt dafür einige Fälle nicht ab, für die das bisherige API gut passt. Die Entwickler sind bereits dabei, sich und den Code abzustimmen, um alle involvierten Parteien zufrieden zu stellen. Das dürfte auch eine Aussage von Torvalds zu verdanken sein, der sich für Wireguard stark gemacht hat – das ist mehr als ungewöhnlich, denn mischt er sich nicht mit solch positiven und daher Druck erzeugenden Aussagen in die Arbeit der zuständigen Subsystem-Entwickler ein.

Kernel-
Version
Anzahl
Dateien¹
Zeilen
Quelltext
(Ohne
Doku)²
Entwick-
lungs-
zeitraum
Commits
(Ohne
Merges)³
Diffstat⁴
Linux 4.10 57.202 22.839.659
(20.864.595)
70 Tage 14.249
(13.029)
11.913 files changed,
806.420 insertions(+),
312.218 deletions(-)
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(-)
¹ 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)

Den neuen Linux-Kernel herunterladen und einrichten

Die neue Linux-Version steht wie gewohnt über Kernel.org zum Download bereit. Auf Kernel.org finden Sie auch eine Anleitung, wie sie die Archivsignaturen prüfen, bei denen es Ende Juli allerlei Änderungen gab. Seitdem signiert Kernel.org inkrementelle Patches nicht mehr, denn die werden nur noch aus historischen Gründen ("Legacy") erzeugt; Anwendern wird zum Einsatz von Git geraten, bei dem sich die Authentizität von Versions-Tags mit git verify-tag prüfen lässt.

Hinweise zur Einrichtung eines eigenen Kernels finden Sie im Artikel "Linux-Kernel maßgeschneidert". Das darin beschriebene Make-Target make localmodconfig erzeugt weitgehend automatisch eine recht gut auf Ihr System zugeschnittene Kernel-Konfiguration, mit der Sie in wenigen Minuten eine neue Linux-Version einrichten können.

Fedora und Rolling-Release-Distributionen wie Arch Linux, Gentoo und OpenSuse Tumbleweed dürften die neue Linux-Version in den nächsten Tagen und Wochen im Rahmen der regulären Systemaktualisierung erhalten. Bei bereits erhältlichen Releases von OpenSuse Leap, Ubuntu und den meisten anderen klassisch gewarteten Distributionen wird das nicht passieren: Deren Kernel machen in der Regel nur mit neuen Distribution-Releases größere Versionssprünge.

Versionshistorie dieses Artikels

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

  • 2018-08-13, 6:45 – 2.0: Umstellung zum Release: Schnellüberblick am Anfang eingefügt, Seitenreihenfolge geändert, Abschnitt zum wieder rausgeworfenen AIO entfernt und eine wenig Finetuning hier und da.
  • 2018-08-09, 14:15 – 1.5.1: Speck-Diskussionen erwähnt.
  • 2018-08-01, 6:30 – 1.5: Details zu Bpfiler hinzugefügt.
  • 2018-07-25, 6:30 – 1.4: Verbeserungen rund um Treiber beschrieben.
  • 2018-07-18, 6:30 – 1.3: Neuerungen rund um Sicherheit erläutert.
  • 2018-07-11, 19:40 – 1.2.1: Textkorrektur im Raspi-3B-Abschnitt zu Gigabit-Ethernet-Controller, denn den haben nicht wie ursprünglich spezifiziert beide, sondern nur der B+.
  • 2018-07-11, 6:30 – 1.2: Neuerungen rund um Architektur und Infrastruktur beschrieben.
  • 2018-06-29, 16:15 – 1.1.2: Erwähnt, dass Torvalds das neue AIO-Polling-Interface wieder entfernt hat.
  • 2018-06-27, 15:15 – 1.1.1: Nach Entwickler-Feedback noch einen Satz mit zwei Links ergänzt, der den Einsatz von TCP_ZEROCOPY_RECEIVE bei Google erwähnt; außerdem einen Absatz zum Verhältnis zwischen DPDK und AF_XDP ergänzt.
  • 2018-06-27, 06:30 – 1.1: Neuerungen des Netzwerkbereich-Subsystems erläutert; der Bpfilter blieb allerdings außen vor und folgt in einem späteren Update
  • 2018-06-17, 08:30 – 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.

(thl)

Kommentare

Kommentare lesen (364 Beiträge)

Anzeige
Anzeige