Linux 5.12: Standard-Release mit neuem Hypervisor & überarbeitetem ID-Remapping
Der neue Kernel bietet überarbeitetes ID-Remapping, mehr Unabhängigkeit des kcmp()-Aufrufs, den IoT-Hypervisor ACRN und viele konsequente Verbesserungen.
(Bild: Wikimedia Commons / Lieutenant Philip Hall, NOAA Corps / Public Domain)
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 von Entwickler Christian Brauner auf dem Prüfstand.
"ID-mapped Mounts" im Überblick
Das neue ID-Remapping-Konzept setzt auf den User-Namespaces 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.
