Die Neuerungen von Linux 4.15

Inhaltsverzeichnis

Linus Torvalds hat den Linux-Kernel 4.15 freigegeben – nicht wie sonst nach neun oder zehn Entwicklungswochen, sondern erst nach elf. Hauptschuld daran tragen die Sicherheitslücken Meltdown und Spectre, denn zwischen Mitte Dezember und Mitte Januar haben die Kernel-Entwickler mit PTI und Retpoline noch schnell zwei Gegenmaßnahmen integriert, um das Gefahrenpotenzial zu senken. Die neue Linux-Version wartet darüber hinaus aber noch mit zahlreichen anderen Neuerungen auf. Die wichtigsten im Kurzüberblick, bevor der Text auf den folgenden Seiten in die Details geht:

• Durch eine größere Erweiterung des Treibers Amdgpu unterstützt dieser AMDs Vega-Grafikkarten nicht mehr nur rudimentär, sondern ordentlich. Darüber hinaus funktionieren mit vielen Vega-Vorgängern (etwa Radeon-Karten der 400er oder 500er-Serie) jetzt einige Features, die zur Ansteuerung moderner Monitore wichtig sind.

• Der neue Kernel geht ein altbekanntes Problem neu an, durch das viele mit SATA-Datenträgern bestückte Linux-PCs unnötig Strom verbrauchen. Damit versucht der zuständige Entwickler, die Akkulaufzeit von Notebooks spürbar zu verlängern.

• Über Dateien im Sysfs kann man nachsehen, ob der Prozessor gegen Meltdown und Spectre anfällig ist und was der Kernel dagegen tut.

• Zum Schutz vor Meltdown haben die Kernel-Entwickler die Page Table Isolation (PTI) geschaffen. Einige ältere Linux-Versionen erhielten eine ältere Variante der Schutztechnik; damit ausgestattete Kernel können den mit PTI einhergehenden Performance-Verlust aber schlechter ausgleichen.

• Linux 4.15 enthält noch keinen Schutz gegen die erste der beiden Spectre-Varianten: Patches, die diese Lücke abdichten, soll erst 4.16 liefern.

• Gegen die zweite Spectre-Variante bringt Linux eine "Return Trampoline" (Retpoline) genannte Technik mit. Volle Kraft entfaltet sie allerdings erst mit Compiler-Patches, die vielen Distributionen noch fehlen. Vollständig ist der Schutz noch nicht: Es stehen Änderungen zur Diskussion, durch die der Kernel die Spectre-v2-Schutzmaßnahmen besser nutzen kann, die Intel mit neuem Microcode nachrüstet.

• Linux unterstützt jetzt auch die offene Prozessor-Architektur RISC-V

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)

• Die Entwickler haben den Support für AMDs Speicherverschlüsselung verbessert; richtig komplett wird das Ganze aber wahrscheinlich erst mit Linux 4.16.

• Die Entwickler haben endlich ein moderneres Interface geschaffen, um den Verbrauch von Prozessorzeit zu regeln. Das ist für Virtualisierung und Container wichtig.

• Über Kernel Live Patching lassen sich Sicherheitslücken jetzt auch zur Laufzeit beheben, wenn das Änderungen an Datenstrukturen erfordert.

• XFS erhält eine vorerst noch nicht nutzbare Funktion, um das Dateisystem parallel zur normalen Verwendung auch prüfen und nötigenfalls reparieren zu können.

• Der Linux-Kernel 4.15 kann Systeme per Thunderbolt vernetzen. Eine Änderung an Interna des Netzwerksubsystems verspricht ferner ein Performance-Problem zu beseitigen, das mit besonders schneller Netzwerk-Hardware auftritt.

• Unter den Änderungen an Grafiktreibern waren mehrere Verbesserungen zur Ansteuerung von VR-Brillen. Ferner ist jetzt ein Treiber für einen beliebten Raspberry-Pi-Touchscreen dabei. Der Support für den Grafikkern neuerer Intel-Prozessoren gilt nun endlich als alltagstauglich.

• Wie jede neue Kernel-Version bringt auch Linux 4.15 zahlreiche neue und verbesserte Treiber, die die Hardware-Unterstützung verbessern. Neu sind etwa einige Hardware-Monitoring- und Audio-Treiber für AMD-Prozessoren. Intels WLAN-Treiber unterstützt jetzt auch die WLAN-Chips, die in einigen der neuesten Notebooks stecken. Das Open Sound System (OSS), auf das Audio-Treiber früher aufgebaut haben, haben die Kernel-Entwickler indes entfernt.

• In einer zur Dokumentation gestoßenen Stellungnahme sprechen sich einige Kernel-Entwickler deutlich gegen proprietäre Treiber aus.

Die folgenden Seiten liefern Details zu diesen und zahlreichen weiteren Neuerungen von Linux 4.15. Die letzte Seite des Artikels enthält zudem einen kleinen Ausblick auf die Änderungen, die 4.16 bringen dürfte.

Die wichtigsten Neuerungen

ATA-Trick verspricht längere Akkulaufzeit

Linux 4.15 enthält eine kleine Änderung an den ATA-Treibern, mit der ein Entwickler die Akkulaufzeit Millionen moderner Notebooks signifikant verlängern will. Wie stark, hängt vom Notebook ab – bei besseren Notebooks dürfte im Leerlauf aber schnell eine halbe oder ganze Stunde mehr drin sein. Der Ansatz verspricht darüber hinaus auch, die Leerlauf-Leistungsaufnahme von PCs zu reduzieren. Es sind aber noch Feldtests nötig, bis Linux-Distributionen dieses Sparpotenzial automatisch nutzen.

Das Ganze betrifft die meisten der in den letzten sechs bis sieben Jahren verkauften PCs und Notebooks, die einen Intel-Prozessor mit per SATA angesprochenen Datenträgern kombinieren. Standardmäßig nutzt Linux bei diesen kein AHCI Link Power Management (ALPM), obwohl das den Stromverbrauch von SATA-Verbindungen bei Untätigkeit signifikant reduzieren kann. Aber nicht nur das: Wenn alle SATA-Links richtig per ALPM ruhen, können Prozessoren seit der Haswell-Generation (u. a. im Core-i-4000 verbaut) bei Untätigkeit teilweise deutlich tiefer schlafen gehen, weil sich der zugehörige SATA-Controller nicht für Aktivitäten bereithalten muss. Das reduziert die Leerlauf-Leistungsaufnahme abermals, sodass das Aktivieren von ALPM letztlich rund ein oder manchmal sogar zwei Watt spart. Bei sparsamen Notebooks senkt das die Leistungsaufnahme im Leerlauf manchmal um 20 oder 30 Prozent.

Altes Problem rund um ALPM

Diese Problematik ist seit vielen Jahren bekannt und war auch mehrfach Thema in c't. Damit vertraute Anwender aktivieren das von Linux schon länger unterstützte ALPM daher manuell. Manche lassen das Software wie Powertop, TLP und Laptop Mode Tools erledigen, andere stellen über die Dateien /sys/class/scsi_host/host*/link_power_management_policy von max_performance auf die ALPM aktivierenden Modi min_power oder medium_power um.

Von den großen Linux-Distributionen setzt aber keine solch eine Einstellung automatisch, weil beide Modi laut vereinzelten Berichten zu Abstürzen oder Datenverlust führen können. Als Ursache stehen Hard- oder Firmware-Probleme ganz oben auf der Verdächtigenliste, weil beide Modi das ALPM etwas anders konfigurieren als der Windows-Treiber für die Intel Rapid Storage Technology (IRST). Ein Aspekt dabei ist die Konfiguration des zu ALPM gehörenden Device Initiated Power Management (DIPM). Nach mehreren Jahren hat ein Entwickler das Problem im Frühjahr 2015 mit Patches anzugehen versucht, durch die einer der bisher setzbaren Modi die Hardware samt DIPM so konfigurierte, wie es der IRST-Treiber macht. Aber auch damit gab es Berichte über Datenverlust und Abstürze. Das Vorhaben verlief daraufhin im Sande.

Ein an Fedora arbeitender Red-Hat-Entwickler hat die Patches jetzt aufgegriffen und so überarbeitet, dass der Kernel nun mit med_power_with_dipm einen vierten Modus versteht. Dieser konfiguriert die Hardware mit genau den ALPM-Parametern, die auch der IRST-Treiber setzt. Nachdem der Entwickler und einige Fedora-Mitstreiter die neue Betriebsart auf einigen Notebooks erfolgreich ausprobiert haben, flossen die DIPM-Patches jetzt in Linux 4.15 ein.

ALPM liegt allerdings nach wie vor standardmäßig brach, denn man muss den neuen Modus explizit aktivieren. Das derzeit entwickelte Fedora 28 soll ihn aber von Haus aus nutzen, damit es das Sparpotenzial automatisch ausschöpft, ohne dass Anwender in die Konfiguration eingreifen müssen. Genau wie bei den anderen ALPM-Sparmodi kann dadurch die SATA-Performance minimal sinken, denn der Wiederaufbau einer SATA-Verbindung kostet einige Millisekunden; in der Praxis ist der Performance-Verlust aber so gering, dass er nicht spürbar und typischerweise vernachlässigbar ist.

Fedora 28 soll übrigens auch einige andere Stromsparfunktionen standardmäßig scharf schalten, die der Kernel und die meisten Linux-Distributionen derzeit links liegen lassen. Wenn keine größeren Probleme bei diesen Feldtests auftauchen, dürften andere Distributionen vermutlich nachziehen.

Meilenstein beim Treiber Amdgpu

Linux 4.15 bringt endlich ordentliche Unterstützung für AMDs Vega-GPUs, die auf den Ende Juli eingeführten Radeon-Grafikkarten RX Vega 56 und RX Vega 64 sitzen. Die dafür zuständigen Änderungen verbessern auch den Support für die Raven-GPU des im Oktober angekündigten Ryzen Mobile. Damit nicht genug: Auch die Unterstützung für viele andere moderne Radeon-Karten soll dadurch besser werden, denn mit dem neuen Code unterstützt der Treiber einige bislang brach liegende Techniken zur Monitoransteuerung. Darunter befindet sich der Support für HDMI 2.0 und DisplayPort (DP) 1.4, was für 4K- und 5K-Bildschirme wichtig ist; außerdem unterstützt der Treiber bei vielen der neueren Grafikkarten jetzt endlich HDMI- und DP-Audio.

Kernel-Entwickler sagen NEIN!

Zu verdanken sind diese Fortschritte einer DC (Display Core) genannten Serie von Änderungen, die mit über 800 Patches und mehr als 130.000 hinzugefügten Zeilen einen dicken Brocken darstellt. AMD hat diese Patch-Serie anfangs intern mit dem Ziel entwickelt, einige Kernfunktionen des Codes auch bei den Treibern für andere Betriebssysteme zu verwenden. Dazu enthielt der Code eine Abstraktionsschicht.

Im Frühjahr 2016 hat AMD die damals noch DAL (Display Abstraction Layer) genannte Patch-Sammlung dann veröffentlicht mit dem Ziel, sie bald in Linux zu integrieren. Der für die Grafiktreiber zuständige Kernel-Entwickler Dave Airlie und ein weiterer Kernentwickler winkten aber schnell und sehr deutlich ab: Die Patch-Sammlung entsprach ihren Qualitätsansprüchen nicht. Hauptgrund, vereinfacht gesagt: Ihnen gefiel die Abstraktionsschicht zwischen den Kernfunktionen des DC-Codes und dem Atomic-Framework des Kernels nicht, welches als Basis für moderne Kernel-Grafiktreiber gedacht ist. Erschwerend kam hinzu, dass DAL einige Funktionen reimplementierte, die das Atomic-Framework und andere Teile des Kernels bereits enthalten; einige Codeteile boten zudem Features, die besser im treiberunabhängigen Kernel-Code aufgehoben wären, damit auch andere Treiber diese Funktionen nutzen können und nicht reimplementieren müssen.

Airlie & Co. sahen daher viel Code von DAL eher als Ballast an, der Pflege und Weiterentwicklung des Linux-Kernels unnötig verkompliziert hätte. Nach anfänglicher Gegenwehr und vielen Diskussionen haben die AMD-Entwickler das eingesehen und begonnen, die Patch-Sammlung anzupassen, damit sie die gestellten Anforderungen besser erfüllt. Das ist nach 18 Monaten jetzt weitgehend der Fall, wie Airlie im Commit-Kommentar zur DC-Aufnahme erläutert – es gibt aber durchaus noch einiges zu verbessern, wie eine Todo-Liste zeigt.

Vorteile auch für viele ältere Radeon-Karten

Durch die Aufnahme für 4.15 ist der Treiber Amdgpu nun auch mit Vega-Chips in der Lage, Bildschirme anzusteuern – bislang ließ sich die bei Linux 4.12 integrierte Vega-Unterstützung nur zum Rechnen oder Rendern mit Vega-GPUs nutzen.

Der DC-Code unterstützt aber nicht nur die für die Bildschirmausgänge zuständige DCE (Display Controller Engine) von Vega- und Raven-GPUs, sondern auch die der direkten Vorgänger bis hin zum DCE8 (Sea Islands & Kaveri). Amdgpu nutzt DC bei älteren GPUs aber derzeit nur, wenn sie den Treiber durch Angabe des Kernel-Bootparameters amdgpu.dc=1 explizit dazu auffordern. Das ist etwa für Polaris-GPUs interessant, die auf den aktuellen Radeon-RX-Grafikkarten 460 bis 480 und 540 bis 580 sitzen. Durch DC können diese dann nämlich auch Audio via HDMI oder DisplayPort (DP) weiterleiten, was der Treiber bei älteren GPUs auch ohne DC beherrscht. Durch DC unterstützt er zudem Techniken wie DP 1.4, DP Multistream Transport (MST) und HDMI 2.0, die zur ordentlichen Ansteuerung besonders hochauflösender Monitore wichtig oder nötig sind; HDMI 2.0 erlaubt etwa, 4K-Monitore mit 60 Hertz oder mehr anzusteuern, damit der Bildaufbau flüssiger erfolgt als bei 30 Hertz. Der Kernel-Parameter ist aber nur eine Übergangsmaßnahme: Nach Feldtests soll er verschwinden, damit Amdgpu den DC-Code auch bei älteren GPUs automatisch nutzt, damit die erwähnten Features von Haus aus funktionieren.

Beim Einsatz von DC greift Amdgpu nun auch auf die Atomic-Infrastruktur zurück, die Intels Treiber seit 4.12 nutzt; sie macht unter anderem die Monitor-Konfiguration verlässlicher und ermöglicht eine bessere Synchronisation der Bildausgabe, was für Bedienoberflächen von Desktop und Spielen wichtig ist. AMDs DC legt ferner Grundlagen zur Unterstützung von VESA Adaptive-Sync, dessen Implementation bei AMD als Freesync läuft; ähnlich wie Nvidias G-Sync kann diese Technik die Bildwiederholrate von Monitoren dynamisch anpassen, um Verzögerungen und Ruckler in Spielen zu vermeiden.

Stellungnahme gegen Closed-Source-Treiber

In der Kernel-Dokumentation findet sich nun ein Statement, mit dem sich einige Entwickler des Linux-Kernels klar gegen proprietäre Linux-Treiber aussprechen. Ihnen zufolge seien Kernel-Module oder Treiber schädlich und unerwünscht, die Closed-Source-Code enthalten. Solche hätten sich wiederholt als nachteilig für Nutzer, Firmen und das Linux-Ökosystem erwiesen. Firmen, die Closed-Source-Module verteilen, würden ihre Kunden zwingen, zentrale Vorteile von Linux aufzugeben oder andere Anbieter zu wählen. Der Text endet mit einem Appell an Hardware-Hersteller, Linux-Kunden mit quelloffenem Kernel-Code zu unterstützen.

Rund 175 Entwickler haben diese Stellungnahme unterzeichnet, die seit 2008 existiert und mit Rückendeckung der Linux Foundation veröffentlicht wurde. Jetzt floss sie in die Linux-Quellen ein, denn auf den Webseiten der Interessenvereinigung war sie nur schwer zu finden und zog zudem gelegentlich um; außerdem hatten selbst treibende Kräfte den Schreibzugang verloren. Von nun an können Entwickler das Dokument viel leichter unterschreiben: Sie müssen lediglich einen Kernel-Patch einreichen, der ihre Signatur einfügt.

Zu den Unterzeichnern zählt eine Reihe zentraler Linux-Entwickler, darunter Dave Airlie, Jens Axboe, Arnd Bergmann, Mauro Carvalho Chehab, Thomas Gleixner, Takashi Iwai, Greg Kroah-Hartman, Ingo Molnar, Andrew Morton und Theodore Tso. Linus Torvalds ist allerdings nicht dabei.

Endlich modernere CPU-Ressourcenregelung

Der zur Regelung des Ressourcenverbrauchs zuständige Cgroup-Code bringt nun einen Cgroup v2 Controller mit, der die von Prozessen einer Gruppe verwendbare CPU-Zeit limitieren kann. Der floss nach jahrelangen Streitigkeiten um die Frage ein, wie das Cgroup-Interface der zweiten Generation denn Threads handhaben soll. Diese wurden mit dem in Linux 4.14 eingeflossenen Cgroup v2 Thread Support endlich gelöst, auf die der neue CPU-Controller zurückgreift.

Maßnahmen gegen Meltdown und Spectre

Meltdown-Schutz

Gegen die Prozessor-Sicherheitslücke Meltdown konnte man sich bereits schützen, als die Lücke am späten Abend des 3. Januar bekannt wurde. Das war der eigens entwickelten Page Table Isolation (PTI) zu verdanken, die manchmal auch Kernel PTI (KPTI) genannt wird. Mit ihrer Hilfe blendet der Kernel im Adressraum von Prozessen nicht mehr seinen ganzen Speicher ein; vielmehr findet sich dort nur noch ein kleiner Teil davon, der zur Interaktion zwischen Programmen und Kernel unerlässlich ist. Dadurch steigt der Overhead allerdings deutlich, wenn Programme für irgendwelche Aufgaben den Kernel zur Hilfe nehmen. Dieser muss dann zunächst seinen Speicher wieder einblenden, der durch das Versteckspiel auch noch aus den Caches geflogen ist.

Linus Torvalds hatte PTI am Tag vor Silvester in den Hauptentwicklungszweig integriert, aus dem kurz darauf die sechste Vorabversion von Linux 4.15 hervorging. Einige Vorarbeiten waren sogar schon in den Wochen davor eingeflossen, zahlreiche Fehlerkorrekturen folgten in den Wochen danach (1, 2, 3, 4, 5, 6, 7). Die Schutztechnik floss auch in Version 4.14.11 ein, die am 2. Januar erschien.

All das war äußerst ungewöhnlich: PTI ist eine tiefgreifende Änderung, wie sie Torvalds beim Vorbereiten neuer Versionen normalerweise nur in den ersten zwei Entwicklungswochen integriert. Solche großen Umbauten fließen eigentlich auch nie in Stable/Longterm-Kernel zurück – und schon gar nicht innerhalb von lediglich drei Tagen.

Durch diese Aktivitäten wurde rund um Neujahr in Linux-Kreisen schon deutlich, dass die Bekanntgabe einer größeren und schwerwiegenden Lücke kurz bevor stand. Indizien dafür hatte es schon früher gegeben, denn Kernel-Patches mit dem PTI-Vorläufer KAISER (Kernel Address Isolation to have Side-channels Efficiently Removed) hatten an der Meltdown-Entdeckung beteiligte Forscher der TU Graz bereits im Herbst veröffentlicht. Hugh Dickins hat diesen Ansatz dann mit anderen Entwicklern grundlegend überarbeitet, damit er auf mehr Systemen funktioniert und den Qualitätsansprüchen der Kernel-Entwickler genügt. Später entstand unter Federführung von Thomas Gleixner dann eine neue PTI-Implementierung, die den Ansatz von KAISER verwendet, mit dessen Code aber kaum noch etwas gemein hat. Diese floss in 4.15-rc6 und 4.14.11 ein. Dort kann sie den Overhead mithilfe der in neueren Intel-Prozessoren gebotenen "Process-Context Identifiers" (PCID) reduzieren, die der Kernel seit Linux 4.14 zu nutzen weiß.

Auch die am 5. Januar erschienenen Kernel-Versionen 4.9.75 und 4.4.140 enthalten PTI – allerdings nicht die jüngste Implementation, sondern die von Dickins vorangetriebene Variante. Diese haben auch viele Distributionen integriert, die nicht ohnehin schon 4.14 verwendeten. Mit dem älteren PTI erhielten die Kernel auch PCID-Unterstützung – allerdings nur eine rudimentäre. Bei diesen Kerneln kann PCID daher nicht so viel Overhead wett machen, wie es es 4.14.11 und 4.15-rc6 können; der Performance-Einbruch kann daher größer sein.

Besitzer von AMD-Prozessoren brauchen dennoch keinen Geschwindigkeitsverlust fürchten: Linux deaktiviert PTI seit 4.14.12 und 4.15-rc7 automatisch, wenn es Athlon, Epyc, Ryzen & Co. vorfindet, denn die sind von Meltdown alle nicht betroffen. Bei Intel-CPUs hängt der Performance-Einbruch von der Generation ab, zu der der Prozessor gehört: Linux nutzt PCID erst bei CPUs mit Haswell-Innenleben, das beispielsweise in den seit Mitte 2013 verkauften Core-i-4000er-Prozessoren steckt; ältere Prozessoren beherrschen diese Technik nicht oder nur in einer Weise, bei der eine Nutzung keine Vorteile brächte.

PTI funktioniert derzeit nur auf der 64-Bit-x86-Architektur. ARM64-Support soll bei 4.16 folgen. An Patches zur Unterstützung von PTI auf 32-Bit-x86-Systemen wird mittlerweile gearbeitet.

Gegenmaßnahmen für die zweite Spectre-Variante

Gegen Meltdown konnte man sich somit bereits schützen, als die Lücken bekannt wurden. Ein Schutz gegen die zweite der beiden Spectre-Varianten folgte erst am 15. Januar mit Linux 4.15-rc8 (1, 2); später folgten noch Korrekturen und Verbesserungen (u. a. 1).

Der Grund für die späteren Gegenmaßnahmen: Erst rund um das Bekanntwerden von Spectre erhielten die Kernentwickler von Linux konkrete Informationen zur Lücke und möglichen Schutzansätze. Erschwerend kam hinzu, dass Kernel-Entwickler verschiedener Firmen zwei unterschiedliche Techniken zum Spectre-Schutz einreichten.

Der von Intel eingereichte Schutz greift auf die neuen Prozessor-Flags IBRS, STIBP und IBPB zurück, die Microcode-Updates des Unternehmens nachrüsten. Auf diese greifen die Spectre-Gegenmaßnahmen zurück, die Windows und einige Enterprise-Linuxe integriert haben. Auf älteren Prozessoren soll er größeren Overhead haben, auf Skylake (Core i-6000) und neueren CPUs aber nur wenig.

Ein zweiter Ansatz kam von Spectre-Mitentdecker Google: Kernel-Patches für eine Software-Lösung namens "Return Trampoline" (Retpoline). Sie soll weniger Overhead aufweisen und funktioniert auch ohne neuen Microcode; für umfassenden Schutz erfordert sie jedoch angepasste Compiler, mit denen der Kernel und schützenswerte Anwendungen neu übersetzt werden müssen.

Die Kernentwickler von Linux mussten zunächst die Vor- und Nachteile der beiden Ansätze gegeneinander abwägen; einige dabei im Raum stehende Unklarheiten und Fehlinformationen erschwerten diese ohnehin hektische und leicht chaotische Zeit weiter. Zum Ende der zweiten Januarwoche integrierten die Entwickler dann ein überarbeitetes Retpoline. Das blockt einige der Schwachpunkte, die zur zweiten Spectre-Variante gehören. Ein umfassenderer Schutz erfordert aber ein Kompilieren mit einem Compiler mit Retpoline-Support; Patches, die den nachrüsten, zogen am 16. Januar in den Stable-Zweig der GNU Compiler Collection (GCC) 7 ein.

Der Retpoline-Schutz in 4.15-rc8 ist allerdings nur der Anfang der Gegenmaßnahmen. So folgt für manche Prozessoren vielleicht auch noch die Lösung, die auf den neuen Microcode von Intel zurückgreift. Teile dieses Ansatzes sind ohnehin zur Integration vorgesehen oder bereits enthalten: Sie sind für sicheres Virtualisieren wichtig, damit in mit Linux aufgesetzten VMs auch die neuen Microcode-Funktionen zur Verfügung stehen, die Windows und andere als Spectre-Schutz nutzen. Andere Teile der Microcode-Schutztechnik braucht der Kernel-eigene KVM-Hypervisor zum effizienten Schutz vor Spectre 2; ganz unabhängig davon nahmen die Entwickler auch noch einige Änderungen in Linux 4.15 ein, um die KVM-Virtualisierung besser abzusichern. Auch da steht aber noch mehr im Raum.

Wie bei PTI wird auch der Retpoline-Schutz in Stable- und Longterm-Kernel zurückportiert. Er ist in Linux 4.14.14 und 4.9.77 eingeflossen, die am 17. Januar erschienen sind. Im parallel veröffentlichten 4.4.112 ist er aber nicht enthalten.

Spectre-v1-Schutz in Vorbereitung

An Maßnahmen gegen die erste Spectre-Variante schrauben die Entwickler noch. Ähnlich wie Retpoline sind dazu Änderungen bei Kernel und Compilern nötig. Jene für den Kernel werden seit Anfang Januar diskutiert, fließen aber wahrscheinlich nicht mehr in Linux 4.15 ein. Ein Grund für die Trägheit sind Unstimmigkeiten an einigen Stellen. Außerdem ist das ganze aufwendig: Die Entwickler versuchen Codestellen im Kernel zu eliminieren, die gegen die Lücke anfällig sind. Dazu müssen sie den gesamten Kernel-Code nach kritischen Stellen absuchen und auch in Zukunft darauf achten, keine neuen Angriffspunkte einzubauen. Darüber hinaus schrauben die Linux-Entwickler am vom Userspace nutzbaren BPF-Interpreter des Kernels, damit auch darüber ausgeführte Programme keinen Unfug anstellen können.

Aktivieren und Diagnostizieren

Die neuen Schutzmaßnahmen muss man vor dem Kompilieren eines Kernel-Images über die Konfigurationsoptionen CONFIG_PAGE_TABLE_ISOLATION und CONFIG_RETPOLINE explizit einschalten.

Über einige unter /sys/devices/system/cpu/vulnerabilities/ zu findende Dateien kann man mit Linux 4.15 prüfen, welchen Lücken den eingesetzten Prozessor betreffen und wie der Kernel dagegen vorgeht. Genau wie die Beschreibung in den vorherigen Absätzen bezieht sich das aber nur auf den Linux-Kernel. Zum umfassenden Schutz gegen die beiden Spectre-Varianten sind darüber hinaus auch Änderungen und Neukompilieren potenziell anfälliger Userspace-Anwendungen nötig. Für Meltdown ist das unnötig, denn das fängt der Kernel komplett ab.

Die erwähnten Gegenmaßnahmen können sich alle auch auf die Performance auswirken. Wie sehr sich das bemerkbar macht, hängt stark vom Prozessor und der verwendeten Linux-Version ab. Zugleich hat aber auch die Anwendung einen großen Einfluss. Auf rechenlastige, die meiste Zeit im Userspace verbringende Programme zeigt sich meist kein Effekt; Wer Kryptogeld mit der CPU schürft, kann sich also beruhigt zurücklehnen.

Auch auf manche Servern – darunter jene hinter Kernel.org – sollen die Schutztechniken keine größeren Einbußen auslösen. Manche Server-Admins berichten hingegen von Performance-Einbrüchen von bis zu 50 Prozent. Das zeigt, wie sehr die Auswirkungen vom Prozessor, der eingesetzten Software und der Workload des Systems abhängen.

Wie stark der Einfluss der Schutztechniken im Kernel ist, können Admins mit dem Kernel-Boot-Parameter nopti und nospectre_v2 testen, denn die legen die Gegenmaßnahmen lahm. Bei einigen mit Meltdown und Spectre-Schutz versehenen Distributionskerneln funktionieren diese Parameter nicht, weil sie andere Lösungen oder älteren Code verwenden. Die nächsten Wochen dürften hier Vereinheitlichung bringen, nachdem die Kernel-Entwickler jetzt Maßnahmen gegen zwei der drei Lücken integriert haben.

Der Tanz zum Schutz vor Meltdown und Spectre ist damit keineswegs beendet; viele weitere Änderungen werden bereits diskutiert. Dabei geht es nicht nur um Feintuning und noch besseres Abdichten, sondern auch größere Optimierungen. So zirkulieren bereits Patches, um PTI bei vertrauenswürdigen Prozessen deaktivieren zu können und so bei ihnen Performance-Einbußen zu vermeiden.

Storage und Dateisysteme

Fortschritte bei der Grundrenovierung von XFS

Umfangreiche Umbauten am XFS-Code sollen das Dateisystem nicht nur schneller, sondern auch fit für die Anforderungen von heute und morgen machen. Unter den Änderungen sind etwa größere Anpassungen bei der internen Handhabung von Extents. Diese versprechen Wartezeiten und Probleme beim Anfordern von Arbeitsspeicher zu reduzieren, die derzeit manchmal beim Zugriff auf stark fragmentierte Dateien auftreten(u. a. 1).

Erst langfristig bedeutsamer ist ein umfangreicher Satz von Änderungen, durch den sich Dateisystemchecks in Zukunft im Betrieb durchführen lassen sollen (u. a. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12). Dieses Online-Fsck ist aber vorerst inaktiv, denn es ist noch unvollständig: Bei den kommenden Linux-Versionen sollen noch weitere Funktionen folgen, um Dateisysteme prüfen und reparieren zu können, ohne sie aushängen zu müssen. Dieses Feature wird auch "Online Scrub and Repair" genannt und ist eine der Funktionen, die auf den größeren Umbauten aufbauen, die bei Linux 4.8 und 4.9 ihren Anfang nahmen und etwa Support für Copy-on-write (CoW) nachrüsten.

Das in der Vergangenheit schon mehrfach grundlegend überarbeitete XFS bekommt mit diesen Features letztlich die nächste Generalüberholung. Dadurch soll XFS besser mit modernen Dateisystemen wie Btrfs und ZFS konkurrieren können. XFS wird unter anderem bei Red Hat Enterprise Linux (RHEL) standardmäßig eingesetzt; bei Suse Linux Enterprise (SLE) ist es Standard für Datenpartitionen. Die Online-Fsck-Änderungen wurden indes maßgeblich von einem Oracle-Mitarbeiter entwickelt.

Neues bei F2FS, Ext4 und Btrfs

Offenbar vornehmlich für den Einsatz bei Android wurde der Quota-Support im Flash-Friendly File System (F2FS) programmiert (u. a. 1, 2). Zu den weiteren Änderungen am für simple Flash-Datenträger ausgelegten F2FS gehört eine flexiblere Funktion zum Speichern erweiterter Attribute (EAs/Xattr).

Das Ext4-Dateisystem unterstützt die Größenänderung zur Laufzeit (Online Resizing) jetzt auch mit Dateisystemen, die Bigalloc verwenden. Durch diese bei Linux 3.2 eingeführten "Big Allocation Blocks" kann Ext4 die zum Speichern von Daten verwendeten 4K-Blöcke zu bis zu einem MByte großen Einheiten bündeln ("clustern"), um Verwaltungs-Overhead beim Speichern großer Dateien zu reduzieren und die Performance zu verbessern. Weitere Änderungen am Standard-Dateisystem vieler Linux-Distributionen nennt der Kommentar mit den wichtigsten Ext4-Änderungen für 4.15.

Die Kernel-Dokumentation beschreibt jetzt den Einsatz der Dateisystem-eigenen und via fscrypt nutzbaren Verschlüsselungsfunktion, die Ext4 und F2FS bieten.

Man kann beim Mounten eines mit Zlib komprimierenden Btrfs-Volumes jetzt spezifizieren, mit welchem Kompressionsgrad es die Dateien packen soll (u. a. 1, 2). Durch einen Schwung neuer Heuristiken soll das Dateisystem die Kompressionstauglichkeit der gerade verarbeiteten Daten besser vorhersagen können und so besser entscheiden, ob ein Komprimieren überhaupt lohnt (u a. 1, 2, 3, 4). Ein Commit-Kommentar nennt noch einige andere für 4.15 vorgenommenen Btrfs-Änderungen. Darunter ein neues Interface, das für Userspace-Werkzeuge zum Defragmentieren oder Deduplizieren gedacht ist (u. a. 1, 2). Eine Änderung am Readahead-Code verspricht die Leistung von Btrfs in bestimmten Situationen zu verbessern.

Noch mehr rund um Dateisysteme

Durch eine Grundrenovierung mit zahlreichen Verbesserungen unterstützt das verteilte Dateisystem AFS (Andrew File System) nun unter anderem Network Namespace, das für den Einsatz in Containern wichtig ist. Das lange eher stiefmütterlich behandelte Distributed File System nimmt mit diesen Änderungen wieder an Fahrt auf: Die für 4.15 integrierten Patches enthalten mehr Änderungen als die 2014 und 2015 an AFS durchgeführten Umbauten.

Nicolas Pitre hat die Pflege des seit mindestens 2013 verwaisten Compressed ROM File System (cramfs) übernommen, das ähnlich wie Squasfs ein komprimiertes Dateisystem im Arbeitsspeicher bereithält. Laut dem im Embedded-Linux-Bereich aktiven Entwickler eignet sich Cramfs aber besser für Systeme mit wenig Arbeitsspeicher. Er hat nicht nur die Pflege übernommen, sondern auch einige neue Features eingebracht (1, 2, 3).

Weitere Änderungen rund um Dateisystem-Features nennen Kommentare zu den wichtigsten Merge Commits von DLM, Ecryptfs, Fscrypt, Fsnotify, GLF2, NFS, NFSd, Overlayfs und Quota.

Bcache, DM, MD & NVMe

Beim SSD-Caching-Framework Bcache gab es einige Detailänderung, um Fehler zu beseitigen und die Performance zu steigern (u. a. 1, 2). Das ist Michael Lyle zu verdanken, der Pflege und Weiterentwicklung des eine Weile verwaisten Bcache-Codes übernommen hat (1, 2). Er hat auch gleich den Fehler behoben, der beim Bcache-Einsatz unter Linux 4.14 und 4.14.1 zu Datenverlust führt.

Der Kernel kann einen NVMe-Datenträger jetzt über mehrere Controller ansprechen. Das steigert neben der Performance auch die Ausfallsicherheit. Zu verdanken ist das dem Multipath Support im NVMe-Treiber. Effizienten Datenaustausch zwischen Prozessor bzw. Hauptspeicher und NVMe-Controller verspricht der ebenfalls neue Support für SGL (Scatter Gather Lists) im NVMe-PCI-Treiber.

Der bei Linux 4.1 integrierte Cluster-Support im via Mdadm konfigurierten MD-Subsystem gilt jetzt nicht mehr als experimentell (u. a. 1). Außerdem unterstützt der MD-RAID-Cluster-Code neben dem RAID-Level 1 jetzt auch RAID 10 – dieser Modus scheint aber noch nicht voll durchgetestet zu sein, denn er trägt den Statuts "limited support". Ein Merge-Commit-Kommentar nennt einige weitere Änderungen am typischerweise für Software-RAIDs genutzten Subsystem.

Zwischen den Patches am von Logical Device Manager verwendeten Device Mapper (DM) stecke unter anderem Support für DAX im Log-Target.

Noch mehr Neues beim Storage-Support

Unter den Patches an Ceph und RBD (Rados Block Device) war eine Änderung an einer Standardvorgabe, durch die das Storage-Framework jetzt automatisch mehr als 240 Images pro Host unterstützt.

Die Kommentare zu den zwei Commits mit den wesentlichen Änderungen am Block-Layer (1, 2) nennen noch weitere Änderungen an der Storage-Support-Infrastruktur von Linux. Darunter verschiedene Performance-Verbesserungen für Blk-Mq (u. a. 1, 2, 3) und ein ganzer Schwung kleiner Änderungen am Writeback-Code, die ein viel diskutiertes Latenzproblem beheben. Außerdem haben die Entwickler die Unterstützung für den Laptop Mode gestärkt (u. a. 1, 2) und die Cgroup-Integration im Loop-Support verbessert. Auch beim Code des bei Linux 4.12 hinzugestoßenen BFQ-I/O-Scheduler gab es nochmal allerlei Feintuning (u. a. 1, 2).

Unter den Änderungen an der Infrastruktur für NV-DIMMs waren die bei LWN.net näher erläuterten Flags MAP_SYNC und MAP_SHARED_VALIDATE. Mit diesen Kennzeichnungen für mmap() erhalten Anwendungsprogramme mehr Kontrolle über das Cache-Flushing, mit denen sie konsistentes Schreiben von Meta- und Nutzdaten bei guter Performance besser gewährleisten können.

Einige weitere Änderungen rund um Storage-Support finden sich in den Pull-Requests für die Subsysteme Libata, MMC, MTD, SCSI, SCSI Target.

Netzwerk-Support

Netzwerkverbindung via Thunderbolt

Linux bringt jetzt alles mit, um zwei Rechner über ein Thunderbolt-Kabel per Internet Protocol (IP) zu vernetzen. Das gelingt über das von Apple entwickelte Protokoll ThunderboltIP, das den IP-Ethernet-Verkehr über die Thunderbolt-Verbindung tunnelt. Der dafür zuständige Code baut auf einer dazu geschaffenen Infrastruktur auf, die prinzipiell auch andere Protokolle übertragen könnte (u. a. 1, 2).

Beim Verbinden von macOS oder Windows mit Linux wird das für ThunderboltIP zuständige Kernel-Modul automatisch aktiv; zum Verbinden zweier Linux-Systeme muss man das Modul thunderbolt-net auf einem von beiden manuell laden, wie die Dokumentation erläutert. Der Treiber legt automatisch ein Ethernet-Device mit einem Namen wie thunderbolt0 an, das wie eine normale Netzwerkschnittstelle konfiguriert werden will.

Effizientere Vorbereitung für Paketverluste

Geringere Latenzen und höherer Datendurchsatz bei Verbindungen mit hohen Verlustraten – das ist ein Ziel der neuen Datenstruktur für TCP-Pakete, die der Kernel bei Verlust abermals versenden muss. Für diese Retransmit Queue nutzt Linux jetzt einen Red-black Tree. Aufgrund seiner Komplexität hatten die Entwickler einen solchen bislang zu vermeiden versucht. Durch die immer schneller werdenden Netzwerkschnittstellen und somit größer gewordenen Warteschlangen wiegen die Vorteile einer solchen Datenstruktur die Nachteile aber nun eher auf. Das unterstreicht der Entwickler mit Testergebnissen im Commit-Kommentar, laut denen der Datendurchsatz von 284 auf 1805 Mbit/s steige – das Testszenario hatte er aber auch konstruiert, um die Vorteile des Verfahrens zu demonstrieren. Der bei Google arbeitende Entwickler erwähnte die konkrete Motivation für die Umbauten jüngst auf einer Konferenz: Bei 100-Gigabit-Netzen mit großen Round Trip Times (RTT) würden sie schwere Skalierbarkeitsprobleme im TCP-Stack sehen.

Scheduler für SCTP-Verbindungen

Ähnlich wie der Kernel von FreeBSD kann nun auch Linux die Sendereihenfolge der Daten verändern, die zum Verschicken per Stream Control Transmission Protocol (SCTP) bereitliegen. Das gelingt über eine neue Infrastruktur für SCTP Stream Scheduler, die ein IETF-Entwurf definiert, der unter Beteiligung deutscher Entwickler entstand. Der Kernel erhielt auch gleich drei SCTP-Scheduler, die mit verschiedenen Herangehensweisen arbeiten (u. a. 1, 2, 3, 4, 5).

BPF-Verbesserungen zu Hauf

Einen ganzen Schwung von Verbesserungen gab es wieder rund um BPF. Dabei handelt es sich um einen auch eBPF (Enhanced BPF) genannten und aus dem Berkeley Packet Filter (BPF; dieser Tage oft auch als Classic BPF/cBPF bezeichnet) hervorgegangene Virtual Machine, die Programme im Kernel-Kontext ausführen kann. Zahlreiche Subsysteme nutzen BPF mittlerweile für die verschiedensten Aufgaben, etwa um Daten zu filtern, Berechtigungen zu regeln oder größere Datenströme zu analysieren.

Programme, die mit dem auf BPF zurückgreifenden XDP (eXpress Data Path) laufen, können Dank des neuen "Meta Pointer For Direct Access" nun Metadaten im Socket Buffer (SKB) ablegen. Das beschleunigt die weitere Verarbeitung des Pakets, weil eine weitere Paketanalyse an anderer Stelle entfallen kann. BPF-Programme zum Ingress Filtering können dadurch beispielsweise effizienter arbeiten. Einige Hardware-Hersteller arbeiten wohl schon daran, die Metadaten gleich von der Netzwerk-Hardware für XDP bereit zu legen, um den Verarbeitungsweg noch weiter zu optimieren.

Das Netzwerk-Subsystem bringt jetzt eine Userspace-API mit, über die sich die Ausführung von BPF-Programmen an darauf ausgelegte Netzwerkchips delegieren lässt. Letzteres gelang schon vorher – die Programmierschnittstelle vereinfacht aber Verwendung und Fehlerhandhabung.

Einige Design-Aspekte von BPF erläutert jetzt eine FAQ in der Dokumentation von Linux. Zu den im Rahmen des Kernels entwickelten Userspace-Werkzeugen stieß das simple bpftool, mit dem sich BPF-Objekte abfragen und aktualisieren lassen. Das ist etwa für Debugging und Introspektion von BPF-Programmen und Maps gedacht.

Noch mehr Änderungen

Der Kommentar zum Merge-Commit mit den wesentlichsten Änderungen am Netzwerk-Subsystem nennt noch einige weitere Neuerungen. Darunter etwa den neuen Qdisc-Scheduler Credit Based Shaper (CBS) oder Feintuning & Dokumentation für Identifier-locator addressing (ILA) mit IPv6. Außerdem bietet Open vSwitch jetzt Meter Support und unterstützt Network Service Headers (NSH). Darüber hinaus gab es Optimierungen an zahlreichen Stellen des Netzwerk-Subsystems, um die Netzwerk-Performance zu verbessern (u. a. 1, 2, 3, 4, 5).

Die vielen Änderungen unterstreichen, dass sich beim Netzwerk-Support in Linux nach wie vor viel wandelt. Einen tieferen Einblick in diesen Aspekt geben bei LWN.net verfügbare Berichte und Notizen von zwei Konferenzen, auf der zahlreiche Entwickler des Linux-Netzwerk-Codes jüngst zusammengekommen sind. In mehreren Vorträgen und Diskussionen ging es etwa um aktuelle oder in Entwicklung befindliche Einsatzmöglichkeiten von BPF und XDP. Außerdem haben die Entwickler über die Entschlackung einiger Strukturen im Netzwerk-Subsystem von Linux gesprochen, um Overhead zu reduzieren und Performance zu steigern. Das sind aber nur einige von mehreren Dutzend Themen, die in den fünf Tagen auf der Netconf 2017 (Part 2) und Netdev 2.2 zur Sprache kamen. Viele der Präsentationsfolien von der Netdev 2.2 finden sich über die Programmseite der Konferenz.

Sicherheitstechniken & Infrastruktur

AMDs Speicherverschlüsselung: Schritt zwei von drei

Mit einigen aktuellen AMD-Prozessoren kann Linux jetzt den Arbeitsspeicher von Virtual Machines (VMs) so verschlüsseln, dass weder Host noch andere VMs an die Daten herankommen, die VMs in dem von ihnen genutzten Teil des RAMs ablegen (u. a. 1, 2, 3, 4, 5, 6). Das gelingt über AMDs "Secure Encrypted Virtualization" (SEV). Diese Technik baut auf der Speicherverschlüsselungstechnik "Secure Memory Encryption" (SME) auf, die Linux seit Version 4.14 zusammen mit Epyc-Prozessoren oder dem für Business-PCs gedachten Ryzen Pro beherrscht.

Aber: Um SEV einsetzen zu können, muss auch der Hypervisor die Technik unterstützen. Die Patches zum Support von SEV mit dem Linux-eigenen Hypervisor KVM haben den Einzug in 4.15 allerdings verpasst und sollen erst in Linux 4.16 folgen. Einige Eckdaten zu SEV finden sich in Abschnitten, die jüngst zur Dokumentation stießen. Weitere Hintergründe zu AMDs Speicherverschlüsselung erläutern das Kernel-Log zu Linux 4.14 und die dort genannten Quellen.

Prozessor schränkt Zugriff ein

Linux unterstützt jetzt User-Mode Instruction Prevention (UMIP). Zukünftige Intel-Prozessoren sollen damit verhindern können, dass Userspace-Programme einige CPU-Instruktionen verwenden, die vorwiegend für Kernel gedacht sind (1, 2, 3, 4, 5, 6, 7, 8). Die Technik versperrt Anwendungen dadurch den Zugang zu manchen Prozessorinterna, die Angreifern oder Schadsoftware dienlich sein können.

Der KVM-Support für UMPI fehlt allerdings noch, denn auch die dafür zuständigen Änderungen kamen Torvalds zu spät und sollen erst bei 4.16 folgen. Ein weiteres Problem: Aktuelle Versionen von DOSEMU2 und Wine nutzen die von UMIP blockierten Instruktionen auf legitime Weise; eine Emulation fängt das teilweise ab und fordert zum Wechsel auf besser mit UMIP harmonierenden Versionen auf. Unklar ist noch, in welchen Prozessoren sich UMIP finden wird. Indizien sprechen dafür, dass Intel die Technik bei CPUs mit dem Codenamen "Cannon Lake" einführen wird.

Kernel Live Patching wird flexibler

Durch das "Shadow Variables API" sollen sich per Kernel Live Patching (KLP) Sicherheitslücken, die eine Erweiterung der Datenstrukturen erfordern, die die modifizierten Codebereich verwenden, jetzt auch zur Laufzeit beheben lassen. Das gelingt über Schattenfelder, die KLP an die bisherigen Datenstrukturen hängt, die davon abgesehen unverändert bleiben. Über diese Felder erreicht der Code separat abgelegte Schattenvariablen, die zusätzliche Daten aufnehmen. Details hierzu finden sich im Kommentar und der Dokumentationsänderung eines Commits.

Ebenfalls neu sind die "(un)patch callbacks". Damit kann der Kernel Funktionen aufrufen, bevor oder nachdem ein Livepatch angewendet oder revidiert wurde. Dadurch lassen sich auch Assembler-Code anpassen und globale Daten sicher ändern. Weitere Details zu diesem Ansatz liefert der Kommentar und die Dokumentationsänderung eines anderen Commits.

Noch mehr Sicherheit

Der Kernel bringt jetzt ein weiteres Prüfverfahren mit, das Überläufe von Referenzzählern erkennt. Angreifer lösen solche "Reference-Count Overflows" manchmal gezielt aus, um sich darüber zusätzliche Rechte zu verschaffen. Der Kernel bringt schon länger Code mit, um solche Überläufe zu erkennen. Der über die Kernel-Option "REFCOUNT_FULL" aktivierbare Ansatz reduziert aber die Performance signifikant, daher bleibt er bei vielen Kernel-Konfigurationen deaktiviert. Der neue, bislang nur auf 32- und 64-Bit-x86-Prozessoren arbeitende Ansatz hat hingegen einen vernachlässigbaren Overhead. Distributionen dürften sich daher weniger scheuen, ihn standardmäßig zu aktivieren; der neue Ansatz prüft aber in einigen Fällen nicht ganz so genau wie REFCOUNT_FULL. Details hierzu liefern ein Commit-Kommentar und ein LWN.net-Artikel. Das Feature wurde schon in 4.14 integriert, aber aufgrund eines Problems dort nochmal lahmgelegt. Der Fehler wurde jetzt korrigiert und die Funktion daraufhin freigegeben.

Eine ganze Reihe kleinerer Umbauten soll die Gefahr reduzieren, dass Log-Meldungen, Sysfs-Dateien oder andere Stellen per ASLR (Address Space Layout Randomization) zerhackte Speicheradressen verrät, die bei Angriffen auf den Kernel dienlich sein können (u. a. 1, 2, 3, 4, 5, 6, 7, 8).

Über neue Eingriffspunkte für Linux Security Modules (LSM) lassen sich Berechtigungen zur Verwendung von BPF und BPF-Programmen feiner regeln. Ebenfalls neu: Multi Program Support für Cgroup+bpf und ein Cgroup v2 Controller, der den Zugriff auf Devices regeln kann.

Durch Umbauten an den User-Namespaces lassen sich jetzt statt nur 5 bis zu 340 verschiedene Mappings definieren, über die sich User- und Gruppen-IDs von Containern auf IDs des Host abbilden lassen.

Einige weitere Änderungen rund um Sicherheit nennen die Kommentare der Haupt-Git-Merges der Subsysteme Audit, Crypto, Integrity, Security, SELinux.

Infrastruktur-Änderungen

Die Kernel-Entwickler habe weitere Umbauten vorgenommen, um das Jahr-2038-Problem zu vermeiden, das mit 32-Bit-Kernel-Images auftritt.

Einen schnelleren Kernel-Bau verspricht eine Detailänderung an Kbuild, die über Shell-Aufrufe gefüllte Variablen in einem Cache speichert.

Das neue Taint-Flag "TAINT_AUX" ist vornehmlich für Distributoren gedacht, die den Kernel in bestimmten Situationen als "Tainted" (beschmutzt/befleckt) kennzeichnen wollen. Einige Enterprise-Distributoren machen das beispielsweise, sobald man Funktionen oder Kernel-Module verwendet, deren Einsatz der Support-Vertrag nicht abdeckt.

Details zu anderen Neuerungen im Bereich Infrastruktur finden sich in den wichtigsten Commits der Subsysteme Cgroup, Documentation, Kbuild, Kselftest, Locking, Modules, RCU (Core), Scheduler und Timers (1, 2).

Hardware-Unterstützung

Support für offene Prozessor-Architektur

Neben zahlreichen anderen Architekturen unterstützt Linux jetzt RISC-V. Diese offene Prozessorarchitektur wird von einer ganzen Reihe verschiedener Firmen und Institutionen vorangetrieben. Darunter auch Western Digital, das jüngst prognostiziert hat, irgendwann pro Jahr rund "zwei Milliarden RISC-V-Kerne" in Controllern für Festplatten und SSDs auszuliefern.

Noch ist die Linux-Unterstützung für die ISA (Instruction Set Architecture) aber nicht zu viel Nutze, weil zum Praxiseinsatz noch einige Dinge fehlen. Vor allem mangelt es an Treibern für RISC-V-Implementierungen und mit ihnen gebaute Boards; eine Reihe solcher Treiber stecken in der Begutachtungsphase und sollen bei 4.16 folgen, nachdem die dafür nötigen Grundlagen jetzt geschaffen wurden.

Die ISA des RISC-V ist für 32-, 64- und 128-Bit-Prozessoren ausgelegt. Sie ist aber nur im weiteren Sinne verwandt mit dem quelloffenen Befehlssatz OpenRISC, den Linux schon länger unterstützt. Die treibenden Kräfte hinter OpenRISC verfolgen aber etwas andere Ziele als die hinter RISC-V, was einer der Gründe ist, warum Riscv.org und Openrisc.io an einigen Stellen anderen Design-Entscheidungen getroffen haben.

Um die Linux-Unterstützung für OpenRISC ist es indes jüngst etwas ruhiger geworden. Mit 4.15 tat sich mal wieder etwas mehr beim OpenRISC-Code, denn der unterstützt dank SMP-Support jetzt auch Prozessoren mit mehreren Kernen.

Einige Hintergründe zum Stand dieser und anderer offener Prozessor-Architekturen hat LWN.net jüngst im Artikel "Is it time for open processors?" zusammengetragen.

Neue Prozessor-, Audio- und WLAN-Treiber

Der Hardware-Monitoring-Treiber K10temp kann nun auch die Prozessortemperatur von Ryzen und anderen AMD-Prozessoren mit Zen-Architektur auslesen (1, 2).

Die Audio-Treiber des Kernels unterstützen nun endlich den Sound-Chip, der in AMD-APUs der 2016 eingeführten Stoney-Ridge-Generation steckt; zu diesen gehören etwa die A6- und A9-Modelle der Baureihen 9200 und 9400. Außerdem wissen die Audio-Treiber jetzt auch die Audio-Hardware von Raven-Ridge-CPUs anzusprechen, zu denen neben Ryzen 3 2200G und Ryzen 5 2400G auch die im Herbst eingeführte Ryzen-Mobile-CPUs zählen.

Das bei Linux 4.12 auf die Abschussliste gesetzte Open Sound System (OSS) ist jetzt wie angedroht rausgeflogen. Damit verschwindet ein Stück Historie, denn Sound-Treiber haben typischerweise auf OSS aufgesetzt, bevor die Advanced Linux Sound Architecture (ALSA) mit Linux 2.6 zum Standard-Audio-Interface von Linux wurde.

Die Kernel-Entwickler haben zudem den Support für Intel-WLAN-Chips verbessert, die zur Wireless-9000er-Serie gehören. Diese im Herbst letzten Jahres eingeführten 802.11ac-Chips finden sich bislang vor allem in brandneuen Notebook-Modellen mit Core-i-8000-CPUs. Auch die Unterstützung für eine Reihe anderer WLAN-Chips haben Intels Entwickler verbessert, wodurch der Iwlwifi-Treiber letztlich zahlreiche weitere Ausführungen von Intels WLAN-Chips anzusprechen weiß (u. a. 1, 2, 3, 4, 5, 6, 7).

Noch mehr neue und verbesserte Treiber

Der x86-Platform-Code bietet jetzt eine Userspace-Schnittstelle, um einige Hardware-Funktionen aus dem Userspace nutzen zu können, die per WMI (Windows Management Instrumentation) ansprechbar sind und letztlich meist vom SMBIOS ausgeführt werden. Darüber lassen sich etwa Funktionen zum Managen und Überwachen von Servern nutzen. Das gelingt jetzt etwa mit dem Platform-Treiber für Notebooks, Desktops und Servern von Dell, bei dem es größere Umbauten gab, um die Funktionen bereitzustellen (1, 2, 3, 4, 5). Durch sie weiß der Treiber nun auch das WMI-Interface neuerer Dell-Systeme zu nutzen.

Der Kernel unterstützt nun auch das Alps T4 Touchpad, das etwa in den HP-Notebooks-Reihen EliteBook 1000 und Zbook Studio zum Einsatz kommt. Die genannten Änderungen an Treibern sind aber ohnehin nur die Spitze eines Eisbergs von neuen oder um Hardware-Support erweiterten Treibern. Durch diese Änderungen unterstützt Linux 4.15 letztlich rund 750 Geräte oder Geräteklassen mehr als sein Vorgänger; bei über 450 davon handelt es sich um PCI/PCIe- oder USB-Geräte, wie die Datenbanken der Linux Kernel Driver DataBase (LKDDb) zeigen. Letztlich erkennt Linux dadurch jetzt rund 16.500 Geräte oder Geräteklassen, die der Kernel via PCI/PCIe oder USB anspricht.

Details zu Änderungen an Treibern und der sie umgebenden Infrastruktur nennen die wichtigsten Merge-Commits der Subsysteme Char, Driver Core, Fbdev, Input, HID, I2C, RDMA, Hwmon, IPMI, Media, MFD, NTB, Platform, Staging, Sound, TTY und USB.

Blinken zeigt CPU-Auslastung

Zur Hardware-Überwachung und für Bastler kann eine neue Funktion interessant sein, durch die der Kernel die Blinkfrequenz einer LED abhängig von der CPU-Last reduziert oder erhöht.

Nach einigen bereits in Linux 4.14 eingeflossenen Patches gab es noch weitere Änderungen, damit /proc/cpuinfo statt des Standardtakts wieder eine Taktfrequenzangabe liefert, die der Kernel grob aus den letzten Betriebszuständen des Prozessors berechnet. Ähnlich war es schon bis hin zu Linux 4.13, wo die Entwickler auf Ausgabe des Basistakts umgestellt hatten, weil solch ein berechneter Wert "inakkurat" sei – das führte allerdings zu Kritik, woraufhin die Entwickler zurück gerudert sind

Mehr und zugleich weniger schwankende Performance bei AMDs Epyc-Prozessoren verspricht eine Änderung am Scheduler, die Prozesse optimaler auf die verfügbaren CPU-Kerne verteilt.

Linux 4.15 nutzt Intels "Turbo Boost Max Technology 3.0" nun auch bei Skylake-X-Systemen, bei denen sich der Prozessor nicht selbst per HWP (Hardware-managed P-states) um das Hoch- und Heruntertakten kümmert. Das ist laut Commit-Kommentar etwa beim Einsatz eines Core i9-7900x auf dem Asrock x299 wichtig: Dort soll HWP im BIOS-Setup standardmäßig deaktiviert sein, wodurch bislang Performance-Potenzial brach lag.

Unter den Änderungen am PCI-Subsystem waren einige, um die Unterstützung für die Stromspartechnik ASPM (Active State Power Management) zu verbessern, die den Stromverbrauch bei der Kommunikation mit PCIe-Geräten reduziert.

Performance-Monitoring und Tracing

Bei der Kernel-Infrastruktur und den Werkzeugen für Performance-Monitoring und -Analysen mit Perf gab es wieder zahlreiche Verbesserungen, die ein Commit-Kommentar näher erläutert. Darunter beispielsweise eine Änderung, durch die sich Flamegraphs leichter erzeugen lassen. Bei Letzteren handelt es sich um eine grafisch ansprechende und übersichtliche Aufarbeitung, wie viel Zeit in welchen Code-Funktionen verbracht wurde.

Auch beim Tracing-Tool Ftrace gab es einige Änderungen. Durch sie erläutert die zugehörige Dokumentation nun auch, wie man Ftrace innerhalb des Kernels einsetzt.

Änderungen bei ARM & Co.

Bei 4.15 stieß wieder Support für eine Reihe von ARM-SoCs und damit gebauten Boards zum Kernel. Dadurch unterstützt Linux nun etwa den für den Entertainment-Einsatz entworfenen Allwinner R40/V40 oder den für Netzwerk-Hardware ausgelegten Broadcom Hurricane 2. Einer der vielen Merge-Commits des ARM-Subsystems nennt noch zahlreiche weitere jetzt SoCs und Boards, die Linux jetzt unterstützt.

Der ARM64-Code kann jetzt die Scalable Vector Extension (SVE) nutzen (u. a. 1, 2, 3, 4, 5, 6). Dabei handelt es sich um eine Aarch64-Architekturerweiterung, die einen neuen Instruktionssatz mit einer Befehlsstruktur für Vektorlängen von 128 Bit bis 2048 Bit bietet. Man muss also nicht speziell für eine Vektorlänge kompilieren, weil einmal kompilierter Code mit allen Vektorlängen laufen kann. Details zur Technik erläutert ein Blog-Eintrag bei ARM oder eine Datei in der Kernel-Dokumentation.

Einige weitere Änderungen rund um Hardware-nahe Infrastruktur nennen die Kommentare in den wichtigsten Merge-Commits der Codebereiche ACPI, Clock, Devicetree, KVM (1, 2), GPIO, IRQ Core, Power Management (PM), IOMMU, Thermal, VFIO und Xen. Informationen zu den Architektur-spezifischen Änderungen liefern die wichtigsten Merge-Commits am Code für ARC, ARM (Core, DT, SoCs, SoC-Drivers), ARM64 (Core), mk68 (1, 2), MIPS, Powerpc, Parisc, S390 (1, 2), SPARC, x86 (APIC, Cache, Core, Timer). Das sind übrigens nur jene Merges dieser Bereichs, die der Autor aus dem ein oder anderen Grund für erwähnenswert hielt; einige Dutzende andere haben diese Hürde nicht geschafft. Das gleiche gilt auch für andere Aufzählungen dieser Art, die dieser Text enthält.

VR-Unterstützung und Grafiktreiber

Neues für Head-Mounted Displays

Aus Angst vor Zurückweisung durch Linus Torvalds haben die Kernel-Entwickler die DC-Patches unabhängig vom Gros der Änderungen an Grafiktreibern eingereicht. Unter denen waren mehrere Patches von Keith Packard, der seit den 80ern in die Entwicklung von Software zur Nutzung von Grafikhardware für unixoide Betriebssysteme involviert ist. Um solche geht es auch diesmal: Durch die von ihm eingebrachte "DRM_Object Lease Infrastructure" kann der Display-Server die Kontrolle über Teilfunktionen der Grafikhardware an VR-Software überstellen, damit diese die Ressourcen frei und ungestört verwenden kann (u. a. 1, 2, 3, 4).

Letztlich ist der Ansatz somit eine Umgehungsstraße für den X-Server, denn bei der Ansteuerung von der auch Head-mounted Displays (HMD) genannten VR-Brillen ist er mehr im Weg denn Hilfe. Packard hat Ideen und Ziele des Ganzen vor einigen Wochen in einem Vortrag, von dem eine Video-Aufzeichnung und die Präsentationsfolien im Netz stehen, näher erläutert. Weitere Details liefert er in vier Blog-Beiträgen (1, 2, 3, 4).

Unabhängig davon flossen noch einige Änderungen ein, um die Bildschirme in VR-Brillen als "Non-Desktop Displays" zu kennzeichnen. Desktop-Umgebungen können damit erkennen, dass mit diesen Monitoren kein Mehrschirmbetrieb sinnvoll ist, damit die Desktops die Bedienoberfläche nicht dorthin ausdehnen oder dort spiegeln (1, 2, 3).

Amdgpu-Optimierungen für VR-Brillen

Neben dem DC-Code gab es noch zahlreiche weitere Änderungen am Amdgpu-Treiber. Darunter einige von einem Valve-Entwickler entwickelte Patches, die den Einsatz von VR-Brillen mit Radeon-GPUs zu optimieren versprechen. Das soll mit Prioritäten gelingen, mit denen VR-Software die für sie nötigen Berechnungen als wichtiger kennzeichnen kann. Das soll letztlich Ruckler und andere zu Unwohlsein führende Faktoren mit VR-Brillen reduzieren. Konkret haben die Änderungen eine neue Programmierschnittstelle geschaffen, durch die ein Prozess die Prioritäten von Aufgaben ändern kann, die andere Prozesse zur Abarbeitung an den Grafikchip geschickt haben (u. a. 1, 2, 3, 4, 5). Spielentwickler können diese Funktion über die Vulkan-Extension VK_EXT_global_priority nutzen, die Mesa 17.3 mitbringt.

Darüber hinaus hat Amdgpu einen weiteren Codepfad zur Hash-Berechnung bekommen. Er ermöglicht zum Beispiel die effiziente Behandlung von Hardware-Fehlern und -Interrupts, was Speicher- und Prozessorlast erheblich reduziert.

Grundlegende Umbauten gab es auch am Treiber Amdkfd, über den sich moderne Radeon-GPUs für Rechenaufgaben nutzen lassen. AMDs Entwickler hatten diese eine Weile unabhängig weiterentwickelt und den in Linux enthaltenen Code etwas schleifen lassen. Der unabhängig entstandene Code fließt jetzt mehr und mehr in den Kernel ein. Dadurch verschwindet jetzt allerdings der Support für das Rechnen mit GPUs, für die der Radeon-Treiber des Kernels zuständig ist. Das umfasst vornehmlich die Chips der Southern- und Sea-Islands-Generation, die etwa auf den Radeon-HD-Karten 7750 bis 7970 und vielen RX-Karten der 200er- und 300er-Serie sitzen. Anwender sollen auf Amdgpu ausweichen, der diese GPUs betreuen kann; Details hierzu finden sich im Kernel-Log zu Linux 4.13.

Grafiktreiber für Intels Core-i 8000

Bei Intels Grafiktreiber haben die Entwickler den Support der Core-i-8000er-Prozessoren verbessert, die zur Coffee-Lake-Generation zählen. Dadurch unterstützt der Treiber diese seit September in Notebooks und seit Oktober für Desktop-PCs erhältlichen Prozessoren jetzt auch, ohne dass man beim Start den Kernel-Parameter i915.alpha_support=1 angibt.

Der Treiber nutzt jetzt automatisch IPC (Isochronous Priority Control). Die GPU kann dadurch letztlich zur Darstellung aktuell benötigte Bildschirminhalte bevorzugt aus dem Speicher auslesen, was Wartezeiten reduziert, die zu Rucklern führen könnten. Geringeren Overhead beim Speicherzugriff verspricht der Support für Transparent-Huge-Pages in der Speicherverwaltung des i915-Treibers (u. a. 1, 2, 3).

Grundrenovierung bei Nouveau

Die Entwickler des für Nvidia-GPus zuständigen Treibers Nouveau haben den Code zur Speicherverwaltung grundlegend überarbeitet (u. a. 1, 2), damit der Treiber neuere Chips besser abbilden kann. Folgepatches nutzen das, um damit Huge Pages und einige andere Features bei vielen Chips der letzten Jahre zu unterstützten (u. a. 1, 2, 3). Der beim Ansprechen von Nvidias Tegra-GPUs involvierte Treiber Host1x unterstützt nun den als Tegra X2 oder Tegra186 bekannten System-on-Chip (SoC), der unter anderem auf dem Jetson-TX2-Board sitzt.

Treiber für Raspi, EDID-Override, …

Der Kernel bringt jetzt auch einen Bildschimtreiber für das Raspberry Pi 7-inch Touchscreen Panel mit, das die Raspberry-Pi Foundation selbst bewirbt. Der für die Grafik des beliebten Kleinstcomputers zuständige Treiber VC4 bringt jetzt eine Funktion mit, um als Cache verwendete Puffer zu verwerfen, wenn der Arbeitsspeicher knapp wird.

Die Entwickler haben einen zuverlässigeren Weg geschaffen, den Kernel-Grafiktreiber manuell mit EDID-Daten zur korrekten Monitoransteuerung zu versorgen. Das gelingt über den neuen Kernel-Parameter drm.edid_firmware=. Interessant ist das etwa für Situationen, bei denen der Monitor fehlerhafte Informationen liefert oder diese bei einem KVM-Switch hängen bleiben. Der bislang verwendete Parameter drm_kms_helper.edid_firmware= funktioniert aber weiterhin.

Die genannten Neuerungen sind nur einige von 85 Änderungen, die der Maintainer des Direct Rendering Managers (DRM) von Linux in seinem Merge-Kommentar zu den wichtigsten Änderungen bei Grafiktreibern hervorhebt. Allein dieser Merge enthielt fast 1500 der für Linux 4.15 vorgenommenen Änderungen.

Ausblick auf 4.16, Umfang der Änderungen & Changelog

Ausblick auf Linux 4.16

Mit der Freigabe von Linux 4.15 beginnt zugleich die "Merge Window" genannten 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 Linux ein, die in den letzten Wochen zur Aufnahme in 4.16 vorbereitet wurden.

Darunter ist ein Schutz für die erste Spectre-Variante, aber auch Änderungen an den Gegenmaßnahmen für die zweite. Vielleicht integrieren die Entwickler auch noch den 32-Bit-x86-Support für den Meltdown-Schutz PTI. Btrfs soll lernen, bei einem RAID 1 aus SSD und Magnetfestplatte die SSD bei Leseoperationen zu bevorzugen. Außerdem stößt ein VirtualBox-Gasttreiber zum Kernel, der verschiedene VirtualBox-Funktionen ermöglicht – etwa OpenGL-Pass-Through, Seamless Mode oder Copy'n'Paste zwischen Host und -Gast.

Typischerweise beendet Linus Torvalds das Merge Window nach zwei Wochen, indem er die erste Vorabversion der nächsten Kernel-Ausgabe veröffentlicht. Das läutet zugleich die Stabilisierungsphase ein, die meist sieben oder acht Wochen dauert. Linux 4.16 erscheint daher wahrscheinlich in der Nacht auf den 2. oder 9. 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.8	55.503	22.071.048 (20.266.168)	70 Tage	14.552 (13.382)	11.483 files changed,  662.558 insertions(+),  314.177 deletions(-)
Linux 4.9	56.223	22.348.356 (20.520.460)	70 Tage	17.392 (16.214)	11.416 files changed,  713.497 insertions(+),  436.209 deletions(-)
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(-)
¹ 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

Die neue Linux-Version steht wie gewohnt über Kernel.org zum Download bereit. 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 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 Wochen im Rahmen der regulären Systemaktualisierung erhalten. Bei bereits erhältlichen Releases von OpenSuse Leap, Ubuntu und vielen anderen klassisch gewarteten Distributionen wird das nicht passieren: Bei diesen macht der Kernel normalerweise nur einen Versionssprung, wenn man auf ein neues Release der Distribution wechselt.

Mehr Infos

Versionshistorie dieses Artikels

Der obige Text wird zwischen Freigabe der ersten Vorabversion und Fertigstellung von Linux 4.15 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-01-30, 8:30 – v2.0.1: Tippfehler in Statistiktabelle korrigiert; Fehler im Ceph-Abschnitt beseitigt (es funktionieren jetzt nicht bis zu 240 Images pro Host, sondern mehr als 240); im Microcode-Abschnitt den Text verändert, der fälschlicherweise behauptete, IBRS & Co. seien Befehle.
  
• 2018-01-28, 22:30 – v2.0: Textumstellung und Finetuning zum Release von 4.15. Ausblick auf 4.16 hinzugefügt.
  
• 2018-01-24, 06:30 – v1.5: Neuerungen rund um Hardware-Unterstützung erläutert.
  
• 2018-01-22, 08:15 – v1.4.2: Text an einer Stelle leicht angepasst, um den jetzt absehbaren Freigabetermin 29.01. zu erwähnen.
• 2018-01-17, 10:15 – v1.4.1: Text leicht angepasst, nachdem die in Aussicht gestellten Versionen 4.14.14 und 4.9.77 freigegeben wurden.
  
• 2018-01-17, 06:30 – v1.4: Maßnahmen gegen Meltdown und Spectre erläutert.
  
• 2017-12-20, 06:30 – v1.3: Absätze zu Verbesserungen bei Sicherheitstechniken und Infrastruktur eingefügt.
  
• 2017-12-13, 06:30 – v1.2: Änderungen beim Netzwerk-Support erläutert.
  
• 2017-12-06, 06:30 – v1.1: Neuerungen bei Storage-Support und Dateisystemen beschrieben.
  
• 2017-11-27, 06:30 – v1.0: Erste Version, die sich auf die Neuerungen bei Grafiktreibern konzentriert.
  

(thl)