Linux 5.5 freigegeben: Wireguard-Fundament und Performance-Verbesserungen

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

Inhaltsverzeichnis

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

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

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

Wireguard steckt bereits im Entwicklungszweig, in dem die Netzwerk-Entwickler die Änderungen für Linux 5.6 sammeln.

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

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

Ein Umbau an Btrfs verspricht die Performance eines bestimmten Zugriffsmusters erheblich zu verbessern.

(Bild: git.kernel.org – d79b7c26b122 )

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

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

Mehr Infos

Dies war ein schrittweise aktualisierter Artikel

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

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

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

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

Der Support für den Raspberry Pi 4 im Linux-Kernel ist noch lückenhaft.

(Bild: github.com – lategoodbye/rpi-zero/issues/43)

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

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