zurück zum Artikel

Der neue Kernel bietet überarbeitetes ID-Remapping, mehr Unabhängigkeit des kcmp()-Aufrufs, den IoT-Hypervisor ACRN und viele konsequente Verbesserungen.

Linus Torvalds hat die Version 5.12 des Linux-Kernels freigegeben – ein Standard-Release, das sich vor allem durch konsequente Weiterentwicklung und neue Treiber auszeichnet. Wirklich neu ist die Aufname des IoT-Hypervisors ACRN. Größe Änderungen verbergen sich außerdem unter der Haube – so das neue ID-Remapping für Dateisysteme, das Entkoppeln von kcmp() vom Checkpoint/Restore-Featuresowie eine performantere MMU-Unterstützung für KVM. Für den Nutzer sichtbar sind Verbesserungen bei den Dateisystemen, allen voran NFS mit dem neuen Support für "eager writes" und btrfs mit der Unterstützung für Zoned-Devices.

Kernel- und Treiberentwickler können sich über den neuen Memory-Error-Detektor KFENCE ("Kernel Electric Fence") und die Unterstützung für LTO ("Link Time Optimization") von Clang freuen. Letzteres optimierte den von Linux abstammenden Android-Kernel schon seit einiger Zeit und ist nun auch im Linux-Mainline-Kernel angekommen.

Holpriger Start und Ehrenrunde

Der Release-Prozess war diesmal recht holprig verlaufen. Zunächst legte ein massiver Wintereinbruch vielerorts in den USA das Stromnetz lahm – mit der Konsequenz, dass Linus Torvalds fast eine Woche lang keine Änderungen ins Repository aufnehmen konnte. Der erste Release-Candidate startete letztlich mit leichter Verzögerung, und dann auch noch mit einem schweren Bug, der Torvalds dazu bewog, den zweiten Release Candidate vorzuziehen.

Zum Ende des Release-Zyklus überraschte dann der siebte Release Candidat mit ungewohnter Größe. Der entsprechend hohe Korrekturbedarf brachte den angepeilten finalen Release-Termin am 18. April nur eine Woche vor dem Release ins Wanken. "Ich schwanke noch bezüglich des finalen 5.12", teilte Torvalds mit. Und obwohl eine größere Welle von Bug-Reports ausblieb, bewogen ihn einzelne Rückmeldungen letztlich doch dazu dazu, Linux 5.12 sicherheitshalber eine Ehrenrunde in Gestalt eines achten Release Candidate (rc8) drehen zu lassen.

ID-Remapping: Neue Anforderungen, neuer Ansatz

Eine wichtige Änderung in Linux 5.12 mit Auswirkungen auf Container ist die auf den Namen "ID-mapped Mounts" getaufte neue Implementierung des so genannten ID-Remapping.

Zum Hintergrund: Jedes mehrbenutzerfähige Dateisystem verwaltet Zugriffsrechte mit Benutzern und Gruppen. Das funktioniert solange gut, wie die Rechteverwaltung nur über eine einzige Instanz erfolgt – sobald mehrere Instanzen im Spiel sind, etwa beim Netzwerkbetrieb oder bei der Arbeit mit Containern, kommen Konflikte auf. Diesem Problem begegnet das ID-Remapping durch das Abbilden (Remapping) von Benutzer- und Gruppen-IDs der einen Rechteverwaltung auf IDs der anderen.

Ein klassisches Beispiel für Remapping-Bedarf im Netzwerkbetrieb ist NFS (Network File System). Es unterstützt das klassische Unix-Konzept von Benutzern und Gruppen, wobei die numerischen IDs zwischen NFS-Client und -Server jedoch abweichen können. So kann der Benutzer foo auf dem Server die ID 1023 und auf dem Client die 1307 haben. Da es der gleiche Benutzer ist, sind die beiden IDs bei Schreib- und Lesevorgängen mittels Remapping "auszutauschen". Bei Dateisystemen ohne Berechtigungsattribute wie etwa den FAT-Abkömmlingen dient das ID-Remapping noch einem weitern Zweck: Kommt ein solches Dateisystem in einem unixoiden System zum Einsatz, muss diesem nachträglich ein Unix-Berechtigungskonzept "übergestülpt" werden, solange es gemountet ist. Den herrenlosen Dateien weist ID-Remapping in solchen Fällen Benutzer und Gruppen zu und vergibt und Schreib-, Lese- und Ausführungsrechte.

Mit der leichtgewichtigen Virtualisierung über Container hat das ID-Remapping nochmals stark an Bedeutung gewonnen. Container laufen auf dem Host-System mit niedrig privilegierten Benutzern und bringen zudem eine eigene Rechteverwaltung mit. Dennoch müssen sie, da sie autarke Systeme abbilden, auf die gemounteten Dateisysteme als Root und mit vom Host abweichenden IDs zugreifen. Der Dauerbetrieb von Containern stellt in puncto Performance besonders hohe Anforderungen an das ID-Remapping. Und da sich der aus früheren Linux-Kernelversionen bekannte Ansatz in Gestalt des Dateisystems shiftfs aus "Container-Sicht" als inperformant erwiesen hat, stehen in Linux 5.12 nun die ID-mapped Mounts [1] von Entwickler Christian Brauner auf dem Prüfstand.

"ID-mapped Mounts" im Überblick

Das neue ID-Remapping-Konzept setzt auf den User-Namespaces [2] auf, die sicherheitsrelevante Identifier und Attribute und insbesondere Benutzer- und Gruppen-IDs isolieren. Innerhalb und außerhalb des User-Namespace können diese unterschiedlich sein, und beim Übergang findet jeweils ein Remapping statt. Beispielsweise "glaubt" ein Container in seinem User-Namespace als Root zu operieren, ist auf dem Host aber nur als normaler User unterwegs.

"ID-mapped Mounts" erzeugen vereinfacht dargestellt zunächst einen neuen User-Namespace und setzen hierin ein passendes ID-Remapping. Diesen User-Namespace hängt das System dann an die jeweilige vfsmount-Struktur im Kernel an. vfsmount wurde hierzu um den neuen Zeiger mnt_user_ns erweitert, welcher auf den User-Namespace verweist. Alle Zugriffe auf den Mount erfolgen dann über den User-Namespace und unterliegen somit dem entsprechenden ID-Remapping.

Auf den ersten Blick scheint das Konzept, einen ganzen User-Namespace für reines ID-Remapping zu unterhalten, ein ziemlicher "Wasserkopf" zu sein; schließlich isoliert dieser mehr als nur Benutzer- und Gruppen-IDs. Die Kernel-Entwickler entschieden sich aber dennoch für diesen Ansatz, um alle bereits bestehenden Helper-Funktionen der User-Namespaces ohne große Änderungen im ID-Remapping verwenden zu können.

Damit das Ganze nun auch in der Praxis funktioniert, sind kleinere Änderungen am Programmcode der Dateisysteme notwendig: Sie müssen dieses ID-Remapping-Konzept, das eben nicht transparent in einer separaten Schicht funktioniert, explizit unterstützen. Für FAT, XFS und ext4 ist die ID-Remapping-Unterstützung bereits für Linux 5.12 mit von der Partie. Das sind zwar wichtige Zugpferde, aber der "Dateisystemwald" von Linux ist noch weit größer. Somit bleibt abzuwarten, ob sich die "ID-mapped Mounts" tatsächlich dauerhaft etablieren werden.

Feintuning bei den Dateisystemen

Neben dem Remapping-Thema gab es eher kleinere Änderungen im Dateisystembereich. btrfs spendiert der neue Kernel die Unterstützung für Zoned-Block-Devices. Obwohl das Ganze noch ziemlich "work in progess" ist, ist es schon jetzt im Mainline-Kernel gelandet.

In Flash-Dateisystem FS2FS ("Flash-Friendly File System") lässt sich im neuen Kernel neben dem Kompressionsalgorithmus nun auch der Grad der Kompression angeben. Dadurch lässt sich das Dateisystem besser an den Anwendungsbereich anzupassen. Zudem ist jetzt ein Modus für "LZ4 high compression" mit von der Partie.

Der NFS-Client kann im neuen Kernel mit "eager writes" zu schreibende Daten sofort übers Netzwerk an den Server schicken, statt sie erst m Page-Cache zwischenzuspeichern. Das reduziert den Speicherbedarf fürs Caching auf dem Client und soll in einigen Szenarien den Datendurchsatz steigern. Zudem erlaubt es sofortige Rückmeldung, wenn das Volume vollläuft.

Unabhängiger kcmp()-Call...

Mit Linux 5.12 ist der System-Call kcmp() unabhängig von der Software CRIU (Checkpoint/Restore in User Space) konfigurier- und nutzbar. Nach einigen Diskussionen in der Entwicklergemeinde durfte sich das Feature nun doch – trotz einiger Sicherheitsbedenken – vom ursprünglichen Einsatzszenario abnabeln.

Die CRIU-Software, mit der kcmp() 2012 ursprünglich eingeführt wurde, kann laufende Container einfrieren und ihren aktuellen Status (Checkpoint) auf einem Datenträger sichern. Dieser Checkpoint lässt sich – auch auf einem anderen Host – später in den Speicher zurückholen (Restore) und der Prozess wiederbeleben. Verwendet wird das unter anderem von Virtualisierungslösungen wie OpenVZ, LXC/LXD, Docker oder Padman.

Beim Restore eines Checkpoints sind alle Prozesse und verwendeten Ressourcen wieder so herzustellen, dass der Container später problemlos seine Arbeit wiederaufnehmen kann. Eine von zahlreichen Herausforderungen bei diesem Vorgang ist es, herauszufinden, ob womöglich zwei Dateideskriptoren, also eindeutige Kennungen, auf ein und dieselbe offene Datei im Kernel verweisen. Besonders kniffelig wird das, wenn die Deskriptoren in unterschiedlichen Prozessen beziehungsweise Threads beheimatet sind.

kcmp() löst dieses Problem: Der Aufruf kann beim Erzeugen eines Checkpoints prüfen, ob zwei Deskriptoren identisch sind. Dadurch lassen sich Fehlverhalten und Abstürze vermeiden, die aus einem Restore resultieren würden, bei dem aus einem einzigen, jedoch mehrfach referenzierten Dateideskriptor kurzerhand mehrere Deskriptoren gemacht würden.

...mit sicherheitsbedingten Einschränkungen

Mittlerweile wird die Funktionalität von kcmp() auch von Anwendungen genutzt, die keinen direkten Bezug zu Checkpoint/Restore haben. So fußt etwa Mesas os_same_file_description() auf kcmp(). Der Funktionsaufruf dient dazu, festzustellen, ob zwei Deskriptoren, beispielsweise ein Gerät und das Framework DMABUF, auf dieselbe Datei verweisen. Auch systemd nutzt kcmp(), nämlich um Duplikate im File Descriptor Store Service-bezogen aufzulösen.

Bislang war kcmp () nur dann, wenn der Kernel mit Support für Checkpoint/Restore konfiguriert wurde; andernfalls fehlte das Feature schlicht. Aus den – insbesondere im Fall von Mesa starken – Abhängigkeiten von kcmp () ergab sich letztlich jedoch die Notwendigkeit des Loslösens aus dem CheckPoint/Restore-Kontext. Daher landete der kcmp()-Patch aus Linux 5.12 bereits vor dessen Release nicht nur als Backport im LTS-Kernel 5.10.20, sondern wurde zudem auch in den Mainline-Kernel 5.11.3 zurück portiert.

Der Einsatz von kcmp() unterliegt allerdings Beschränkungen. Der aufrufende Prozess benötigt das Recht, ptrace() auf den Zielprozessen auszuführen; zudem müssen die involvierten Prozesse im gleichen PID-Namespace liegen. Dennoch sehen einige Kernel-Entwickler möglichen Exploits Tür und Tor geöffnet. Als Kompromiss ist kcmp() auch in 5.12 nicht per se, sondern nur dann aktiviert, wenn bestimmte Features wie Grafik (oder eben Checkpoint/Restore) ebenfalls aktiv sind.

Das jeweilige Auswahlkriterium lässt sich am einfachsten in der Hilfefunktion in "make menuconfig" unter "General setup -> Enable kcmp() system call" anzeigen. Im Menuconfig lässt sich kcmp() nicht losgelöst von diesen Kriterien aktivieren. Wer es dennoch testen will, kann mit dem Config-Makro CONFIG_KCMP in .config händisch experimentieren.

OProfile geht in Rente

Der bereits seit Linux 2.4 und somit seit rund 20 Jahren im Kernel befindliche System-Profiler OProfile wurde mit der Kernel-Version 5.12 gestrichen. Seit Einzug des perf-Subystems hatten zwei Systeme ums Profiling gebuhlt, und der Kernel hatte somit zwei redundante Interfaces samt separater Funktionalität vorgehalten. Nachdem die Userspace-Tools von OProfile mit Version 1.4 vollständig auf das jüngere perf umgestellt worden waren, wurde der Kernel-Part von OProfile schließlich überflüssig.

Nach dem Abschied von OProfile aus Linux 5.12 funktionieren antiquierte Versionen der OProfile-Tools nicht mehr, so dass spätestens jetzt ein Upgrade auf eine neuere Version zur Notwendigkeit wird. Als Nebeneffekt eliminiert Linux 5.12 übrigens auch den Code für dcookies im Dateisystem, da dieser außerhalb von OProfile ohnehin nicht genutzt wird.

Netzwerk-News

Die Integration und Weiterentwicklung von Multipath TCP im Linux-Kernel schreitet voran. Eine willkommene Erweiterung in der neuen Kernel-Version ist die Möglichkeit, Prioritäten für Subflows festzulegen. So kann beispielsweise ein Subflow als "Backup" genutzt werden und einspringen, wenn der primäre Subflow ausfällt.

netfilter gestattet nun, einzelnen Tabellen einen Besitzer zuzuweisen. Damit ist es möglich, die exklusive Kontrolle und Verwaltung einer Tabelle an einen Prozess beispielsweise einen Firewall-Daemon zu übertragen.

Berkeley Packet Filter verbessert

Der BPF ("Berkeley Packet Filter") wartet in Linux 5.12 mit atomaren Operationen auf. Diese sind notwendig, um global eindeutige Cookies in BPF-Programmen zu erzeugen. Allerdings geht der Entwickler Alexei Starovoitov davon aus, dass sie auch in anderen Anwendungsszenarien sinnvoll sein können. Näheres findet sich in der zugehörigen Merge-Beschreibung [3].

BPF-Programme lassen sich jetzt auch an "Bare-Tracepoints" anhängen. "Bare-Tracepoints" haben kein zugehöriges Trace-Event, das aus dem Userspace sichtbar wäre. Entstanden sind sie aus der Befürchtung, die betreffenden aus dem Userspace nicht sichtbaren Trace-Events könnten in das ABI ("Application Binary Interface") wandern. Wären sie dort einmal angelangt, wäre es schwierig, das später wieder zurückzudrehen.

Eine willkommene Neuerung ist der direkte lesende und schreibende Zugriff auf den Stack mittels Zeiger und variablem Offset. Bislang war dies BPF-Programmen verwehrt und nur indirekt über Helper möglich. Damit können auf dem Stack alloziierte Puffer für die Datenmanipulation genutzt werden. Gerade für kleinere Datenmengen ist das deutlich komfortabler und einfacher als beispielsweise über ein Per-CPU-deklariertes Array zu gehen.

Virtualisierung: Neuzugang ACRN

Mit dem neuen Linux-Kernel hält ACRN [4] als zusätzlicher Hypervisor Einzug. Er ist für Einsatzbereiche wie IoT (Internet of Things) und Embedded-Systeme vorgesehen. Es handelt sich um einen hybriden Virtual Machine Monitor (VMM). Der direkt auf der Hardware aufsetzende ACRN Hypervisor befindet im Kernel. Im Userspace ist eine privilegierte Service-VM, welche die Systemressourcen wie CPUs, Arbeitsspeicher und I/O-Zugriffe der User-VMs verwaltet. Die Gastsysteme sind jeweils in eigenen User-VMs im Userspace angesiedelt und adressieren ihre Ressourcen über die Service-VM. ACRN erlaubt den Betrieb mehrerer User-VMs mit Linux, Android und Windows.

KVM ("Kernel-based Virtual Machines") erlaubt in Linux 5.12, auf x86 und x86_64-Systemen im Userspace Xen-Hypercalls zu emulieren. Die ursprünglich von Oracle 2019 ins Spiel gebrachte Funktionalität erlaubt es, die Xen HVM ("Hardware Virtual Machine"), die eigentlich auf den direkten Betrieb auf der Hardware ausgelegt und angewiesen ist, in einen KVM-Gast zu verfrachten.

Darüber hinaus wurde KVMs MMU-Code ("Memory Management Unit") verbessert. Das neue "Two Dimensional Paging" (TDP MMU) parallelisiert die MMU, was den monolithischen MMU-Lock ablöst und dessen Flaschenhals verhindern soll.

Neues bei Grafik-Hardware

Mit Linux 5.12 lernen Intels Xe-Grafikeinheiten Adaptive-Sync, also die Übermittlung variabler Refresh-Raten (VRR) an Bildschirme. In 3D-Spielen zeigen Monitore etwa so viele Bilder pro Sekunde, wie fps gerendert werden. Die GPU-Architektur Xe kommt ab der Mobilgeneration Tiger Lake (Core i-1100G, i-11000H) und bei den Desktop-Prozessoren Rocket Lake-S (Core i-11000) zum Einsatz. Den kommenden Nachfolger Alder Lake-S und Intels Grafikkarten (bisher nur DG1) berücksichtigt der neue Kernel ebenfalls.

Allerdings unterstützt Linux 5.12 nur Adaptive-Sync über DisplayPort- beziehungsweise eDP-Verbindungen. HDMI bleibt außen vor. Laut Phoronix könnte das an der nicht offen zugänglichen HDMI-Spezifikation liegen: Wie das Linux-Nachrichtenportal im Januar berichtete, habe das HDMI-Forum den öffentlichen Zugang zur HDMI-Spezifikation gesperrt [5]. Dadurch könnten Open-Source-Treiber keine Spezifikationen implementieren, die in der “geheimen" HDMI-Spezifikation beschrieben seien. Die quellcodeoffene Implementierung würde die Spezifikation indirekt offenlegen.

Im AMD-Bereich bringt der neue Kernel OverDrive-Overclocking für die Grafikkartenserie Radeon RX 6000. Zudem wird die Unterstützung für das Gleitkommaformat FP16 mit halber Genauigkeit auf ältere Radeon-GPUs ausgeweitet, die mindestens die Display Controller Engine (DCE) 8 verwenden. Heißt: ab der Radeon RX 290 ("Hawaii"). Da diese Grafikkarten FP16-Instruktionen nicht nativ beherrschen, ist allerdings kein großer Geschwindigkeitsvorteil zu erwarten.

Bewegung bei den CPU-Architekturen

Bei den unterstützten Prozessoren gab es auch diesmal reichlich Bewegung. Linux unterstützt nun NUMA-Systeme (non-uniform memory access) der RISC-V-Architektur. Primär sind dies das System-on-Chip (SoC) SiFive FU740 sowie das darauf basierende Entwicklerboard "HiFive Unmatch". Mit dem NUMA-Support wurde zudem der ARM64-Code generisch gestaltet, was die Aufnahme neuer Plattformen erleichtern soll. Diese Architektur unterstützt mit dem neuen Kernel auch kprobes, uprobes und Per-Task-Stack-Canaries zur Absicherung vor Stack-Overflows. Auch KASAN (Kernel Address Sanitizer) erfährt Verbesserungen auf RISC-V wie das Verwenden von großen Pages beim Alloziieren von KASAN-Regionen [6].

Den Rotstift setzt Linux 5.12 bei einigen 32-Bit-ARM-Plattformen an: Der Kernel unterstützt fortan EFM32, PicoXcell, PRIMA2, Tango, U300, ZX und ARCH/C6X nicht mehr. Konsequenterweise wurden auch die entsprechenden Treiber rund um diese Plattformen aus dem Kernel-Tree verbannt. Diese Plattformen würden nicht mehr genutzt, was der Grund für den Rauswurf sei. Eine Gnadenfrist bekommen hingegen Axxia, Broadcom Kona, Digicolor, Dove, Nspire und Spear. Sollte sich jedoch abzeichnen, dass in naher Zukunft weiterhin keine ausreichende Entwicklungstätigkeit stattfindet, könnten sie in einem der zukünftigen Kernel-Releases doch noch gestrichen werden.

Ein Neuzugang ist die Unterstützung für Intel eASIC N5X. Ebenso gehört Qualcomms SoC Snapdragon 888 nun zum Repertoire des Mainline-Kernels. Kurioserweise hat übrigens auch die 1996 erschienene Spielkonsole Nintendo 64 den Sprung in den Mainline-Kernel geschafft – nach 25 Jahren.

Ausblick und weitere Informationen

Linus Torvalds hat das Patch-Window für Linux 5.13 geöffnet: Entwickler können Beiträge zur Aufnahme in das kommende Release einreichen. Schon jetzt existiert eine lange Liste möglicher Features für 5.13. In seiner Ankündigung zu Linux 5.12 hat Torvalds bereits angedeutet, dass auf das relative kleine 5.12- wohl ein großes 5.13-Release folgen wird.

• Ankündigung zu Linux 5.12 [7]
• ChangeLog zu Linux 5.12 [8]
• Themenseite "Linux und Open Source" [9] bei heise online

(ovw [10])

URL dieses Artikels:
https://www.heise.de/-6024865

Links in diesem Artikel:
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d6beb71da3c
[2] https://man7.org/linux/man-pages/man7/user_namespaces.7.html
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7064a7341a0d
[4] https://projectacrn.org/
[5] https://www.phoronix.com/scan.php?page=news_item&px=HDMI-Closed-Spec-Hurts-Open
[6] http://lkml.iu.edu/hypermail/linux/kernel/2102.3/02934.html
[7] https://lore.kernel.org/lkml/CAHk-=wj3ANm8QrkC7GTAxQyXyurS0_yxMR3WwjhD9r7kTiOSTw@mail.gmail.com/T/#u
[8] https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.12
[9] https://www.heise.de/thema/Linux-und-Open-Source
[10] mailto:ovw@heise.de

Copyright © 2021 Heise Medien