© Christopher Gurovich, 123RF

Der Kernel 5.8 schützt den Kernelspace besser vor problematischen eBPF-Programmen, beschleunigt SELinux, stopft eine Intel-Hardware-Lücke und liefert WPA3-Updates für drei ältere WLAN-Treiber.

Als eine der größten, wenn nicht gar die größte Release in der Kernel-Geschichte bezeichnete Linus Torvalds [1] bereits die erste Vorabversion des Linux-Kernels 5.8, die am 14. Juni 2020 erschien. Vergleichbare Kernel-Versionen in der Vergangenheit waren laut Torvalds mitunter künstlich aufgeblasen: Kernel 4.9 brachte zum Beispiel das neue Greybus-Subsystem mit, zudem war die vorherige Reihe an Release Candidates länger. Kernel 4.12 wiederum konnte zwar die meisten Codezeilen vorweisen, diese bestanden aber lediglich aus haufenweise Registerbeschreibungen für AMD-GPU-Treiber.

Im Kernel 5.8 steckt laut Torvalds hingegen schlicht eine Menge Entwicklungszeit, und die Neuerungen verteilen sich über alle Bereiche. Ein Champion unter den Kerneln sei 5.8 nicht nur aufgrund der Zahl an Commits und neuen Zeilen, präzisiert der Linux-Vater, sondern auch wegen der vielen geänderten Zeilen. Diese verteilen sich ebenfalls über alle Bereiche und stellen laut Torvalds einen Rekord auf.

Kurzum: Die erste Vorabversion von Kernel 5.8 war bereits riesig, das Endergebnis ist es ebenso. Kernel 5.8 erschien offiziell am 2. August 2020 und trägt – Fun Fact – den Codenamen “Kleptomaner Krake” [2].

Schutz vor Kernel-Sonden

Neu ist unter anderem die Möglichkeit, Schutzzonen für bestimmten Kernel-Code zu markieren. Der Hintergrund: Einige eBPF-Tools greifen über die Kernel-interne virtuelle Maschine auf Kprobes und andere sogenannte Kernel-Sonden zu. Diese Probes sind im Kernelspace verankert und sammeln dort Daten. Einige Entwickler befürchten allerdings, dass bei diesen Sammelaktionen (“Instrumentierung”) Probleme entstehen, wenn Kprobes und Co. auf anfälligen oder gar gefährlichen Code treffen [3].

Ein generischer ».noinstr.text«-Ansatz zusammen mit einem »noinstr«-Marker für Funktionen soll diese Instrumentierung nun von bestimmten Codebereichen fernhalten – und damit indirekt auch eBPF-Tools. Die Funktionen »instrumentation_begin()« und »instrumentation_end()« ermöglichen es zugleich, für einen bestimmten Bereich im Code eine Instrumentierung zu erlauben.

Neuer eBPF-Ringpuffer

In Sachen eBPF gibt es ebenfalls Bewegung: Die Entwickler führen einen neuen Ringpuffer [4] ein, der als Alternative zu Perf Buffer einspringt und Letzterem in der Semantik ähnelt. Im Gegensatz zu Perf Buffer erlaubt es der neue Puffer allerdings auch, dieselbe Instanz eines Ringpuffers effizient zwischen verschiedenen CPUs zu teilen.

Änderungen im Threads-Bereich [5] ermöglichen es, »pidfds« mit Namespaces von Prozessen zu verknüpfen. Sie lassen sich zum Beispiel dem »setns()«-Syscall als erstes Argument mit auf den Weg geben. Das reduziere nicht nur die Zahl der Syscalls, um alle verfügbaren Namespaces zu bündeln, sondern erlaube auch atomare »setns()«-Aufrufe für eine Untermenge an Namespaces, schreibt Entwickler Christian Brauner. Das Feature reduziert so die Komplexität im Umgang mit Containern ein Stück weiter.

In Sachen Sicherheit gibt es Performance-Updates für SELinux [6], für die Optimierungen der internen Datenstrukturen den Ausschlag geben. Zugleich vereinfachen die Änderungen laut Entwickler Paul Moore den Code. Auch für den Fehlerbehandlungscode warten Updates.

Das Lockdown-Feature steckt noch nicht lange im Kernel und erlaubt es zum Beispiel in Enterprise-Umgebungen, die Zugriffe auf bestimmte Kernel-Schnittstellen zu verbieten. Dank der jüngsten Änderungen von James Morris dürfen auch unprivilegierte Anwender den Status des Lockdown-Features sehen.

Proc-Bugs

Im Pseudodateisystem »/proc« (Abbildung 1) reparierte Eric Biederman einen Fehler, der offenbar schon sehr lange dort schlummerte. Biederman hat diesen Fehler “zu seiner Überraschung” gefunden [7].

Abbildung 1: Im Pseudodateisystem »/proc« wurde nicht nur ein uralter Bug beseitigt, sondern es gibt auch Optimierungen.

Auch an weiteren Stellen bringt der Kernel 5.8 Reparaturen beziehungsweise Modernisierungen an »/proc« mit [8]. So sorgen Aktualisierungen von Entwickler Alexej Gladkow dafür, dass jeder Proc-Mount einen neuen Superblock verwendet. Das erlaubt es den Benutzern, »proc« einzuhängen, ohne dabei anderen, bereits existierenden Proc-Mounts in die Quere zu kommen. Das bisherige Verhalten hatte zu Problemen und auch zu Sicherheitslücken geführt.

Für den Device Mapper meldete indes Mike Snitzer Neues. Dazu zählt die Möglichkeit, reguläre Blockgeräte besser mit Zoned Devices zu kombinieren, um Performance-Einbrüche abzumildern. Die entstehen aufgrund der begrenzten Anzahl zufällig beschreibbarer Zonen.

Für das Flash-Dateisystem F2FS berichtet Jaegeuk Kim [9] von Optimierungen am Kompressions-Feature: So unterstützt F2FS nun den »lzo-rle«-Algorithmus. Zudem wurde die Testumgebung gehärtet. Auch Bugs am Dateisystem, die auf Android zum Tragen kamen, haben die Entwickler behoben.

David Sterba vermeldet Highlights für das Dateisystem Btrfs: So klappe die Dead Root Detection nun schneller, die nötig zu sein scheint, um gelöschte Subvolumes aufzuräumen. Ein neuer Suchalgorithmus geht die Sache laut Sterba nun schneller an, insgesamt legt Btrfs an Performance zu.

Für das Linux Persistent Storage Filesystem, kurz »pstore«, kündigen sich ebenfalls Änderungen an. Neuerdings lassen sich auch Blockgeräte als »pstore«-Backends verwenden. Damit erfüllen die Entwickler einen bereits länger gehegten Wunsch; die dazugehörige Konfigurationsoption im Kernel heißt »CONFIG_PSTORE_BLK«. Einher mit der Änderung gehen grundsätzliche Umbauten des Codes.

Aufgeweckt

Die Power-Management-Updates von Rafael Wysocki erleichtern das Umschalten des »cpuidle«-Governors zur Laufzeit, unabhängig von der Kernel-Konfiguration. Sie verbessern den Code für den Umgang mit Geräten, die aus dem Userspace-Ruhezustand aufwachen. Zudem berühren sie die systemweiten Treiber-Flags für das Power Management, die sich nun einfacher handhaben lassen [10].

Weitere Änderungen gibt es an der Input Output Memory Management Unit (IOMMU). Die von Joerg Roedel eingereichten Patches ändern die Weise, wie Geräte mit der IOMMU kommunizieren. Anstelle von »add_device()« und »remove_device()« kommen nun die Funktionen »probe_device()« und »release_device()« zum Einsatz. In diesem Zug wanderte Code, der vorher in den IOMMU-Treibern steckte, in den Kerncode von IOMMU.

Im GPIO-Bereich wartet ein neuer Aggregatortreiber im Linux-Kernel. Er bündelt ausgewählte GPIO-Leitungen und erlaubt es auf diesem Weg, Geräte mit Restriktionen zu belegen. Prozesse erhalten dann lediglich Zugriff auf ausgewählte Leitungen, was die Sicherheit stärkt und vor allem im industriellen Umfeld interessieren dürfte. Eine weitere Anwendung besteht darin, diese ausgewählten Leitungen für virtuelle Maschinen und Container zur Verfügung zu stellen. Das Feature lässt sich über die Option »CONFIG_GPIO_AGGREGATOR« einschalten.

Subtile Unterschiede

Als Steppings bezeichnet man unterschiedliche Vertreter desselben Prozessortyps, die sich – anders als neue Prozessortypen – oft kaum vom Vorgänger unterscheiden. Steppings gibt es etwa von Intel für die x86-Architektur. Von ihnen kann Ingo Molnár ein Lied singen: Er musste in diesem Release-Zyklus die x86-Familie samt Model-Makros um Steppings erweitern, “weil das x86-Leben nicht komplex genug ist und Intel Steppings verwendet, um verschiedene CPUs voneinander zu unterscheiden.” Doch wofür das Ganze?

Um eine weitere Hardware-Lücke in Intel-CPUs zu stopfen – oder, wie Thomas Gleixner es formuliert –, um ein neues Kapitel im Groschenroman “Der Performance-Killer” [11] aufzuschlagen. Die Lücke hängt diesmal mit einem Feature namens Special Register Buffer Data Sampling (SRBDS) zusammen und ermöglicht ein Side-Channel-Leak im Stil von Meltdown und Spectre. Laut Gleixner erlaubt es die Schwachstelle, Bits des Zufallsgenerators über Kerne und Threads hinweg zu leaken und erfordert daher den “üblichen Haufen unschöner Zutaten” als Gegenmaßnahmen.

An dieser Stelle klärt sich dann auch schnell, wozu der von Molnár erwähnte Stepping-Abgleich nötig ist: Die Schutzmaßnahmen müssen unter anderem die CPU-Modelle und Steppings von Intel identifizieren, was den beschriebenen Stepping-Match-Support erfordert. Die gewählten Schritte verlangsamen die Intel-CPUs, wenn die Admins die Schutzmechanismen einsetzen.

RISC-V und ARM

Für RISC-V kündigen sich ebenfalls Neuerungen an. Die betreffen den Support für Kendryte K210, einen RISC-V-basierten Edge-Computing-Chip. Für ihn liefern die Linux-Entwickler nun den fehlenden Code nach – und eine Möglichkeit, Device Trees im Kernel abzubilden, da der K210 keinen Bootloader mitbringt, der einen Device Tree anbietet.

ARM-Entwickler Arnd Bergmann [12] kündigt Support für fünf neue Arm-SoCs an. Dabei handelt es sich um drei Realtek-SoCs (RTD1195, RTD1395, RTD1619), die in NAS-Geräten und Settopboxen zum Einsatz kommen. Außerdem gibt es Support für den Renesas RZ/G1H (»r8a7742«) sowie den Rockchip RK3326. Weiterhin unterstützt der Kernel 5.8 zahlreiche neue Maschinen, die auf bereits unterstützten SoCs basieren. Dazu zählen unter anderem TV-Boxen, Single Board Computer und ein Router.

WPA3 für alte Treiber

Gute Nachrichten gibt es auch für Nutzer der etwas älteren WLAN-Treiber »rt2800«, »b43« und »b43_legacy«: Alle drei bringen laut Kalle Valo [13] seit Kernel 5.8 Support für WPA3 mit. Die Treiber »ath9k« und »ath9k_htc« dürfen neuerdings zudem Broadcast Action Frames empfangen, was insbesondere im Mesh-Bereich von Interesse ist.

Auch für Thunderbolt-Schnittstellen gibt es Neuigkeiten: Der Kernel unterstützt jetzt Intels “Tiger-Lake”-basierten Thunderbolt-Controller. Dabei kümmert sich eine Firmware-basierte Software um die Verbindungen. Zugleich lässt sich der Treiber auch für andere Plattformen als x86 bauen.

Selbst für Nutzer des Linux-Desktops bringt der neue Kernel mindestens eine nützliche Änderung mit. Sie betrifft Benachrichtigungen über Schlüssel und den Schlüsselspeicher und behebt ein Problem von »gnome-online-accounts«. Bislang ließen sich Schlüsselspeicher im Kernel nicht asynchron beobachten. Stattdessen musste der Desktop dort aktiv regelmäßig nachfragen.

Kernel 5.8 führt Keyring-Benachrichtigungen ein, wobei die Benachrichtigungs-Warteschlange auf einer Standard-Pipe basiert, die ein spezielles Flag mitbringt: »pipe2(fds, O_NOTIFICATION_PIPE)«. Aktivieren lässt sich das General Notification Queue genannte Feature, indem der Admin die neue Kernel-Konfigurationsoption »CONFIG_WATCH_QUEUE« aktiviert.

Grafik-Updates

Wie in jeder neuen Kernel-Version gibt es in Kernel 5.8 wieder Änderungen an der Grafik [14]. So haben die Entwickler den Kern des Direct Rendering Manager (DRM) umgebaut, um Treiber zu vereinfachen. Der Kernel aktiviert außerdem standardmäßig den Support für Intels “Tiger-Lake”-Plattform.

Der AMDGPU-Treiber unterstützt neuerdings Peer-to-Peer-basiertes PCI-Buffer-Sharing und das Verschlüsseln von GPU-Speicher. Außerdem informieren die DRM-Konnektoren nun den Userspace mithilfe von Sysfs über Hotplug Events – also darüber, dass der User bestimmte Geräte anstöpselt. Wer den neuen Kernel testen möchte, greift am besten zu Git oder lädt ihn über Kernel.org oder Github [15] herunter.