Linus Torvalds brachte vergangene Woche den Linux-Kernel 6.15 auf den Weg. Der neue Kernel widmet sich neben den üblichen neuen und angepassten Treibern sowie vielen kleinen Korrekturen hauptsächlich dem Optimieren und Entrümpeln. Einige neue Features stechen hervor und lohnen einen näheren Blick.

Bessere Performance

Der „Translation Lookaside Buffer“ (TLB) ist ein kleiner, schneller Cache in der CPU, der hilft, virtuelle Adressen schnell in physische Adressen zu übersetzen. Er speichert die zuletzt verwendeten Adressübersetzungen, um Zugriffe auf die Page Table – eine vom Kernel verwaltete Tabelle im Speicher – zu vermeiden. Wird eine virtuelle Adresse verwendet, prüft die CPU zuerst den TLB. Ist dort kein Eintrag vorhanden, greift die Hardware auf die Page Table zu, um den physischen Speicherort zu finden.

Wenn sich die Page Table ändert, können gespeicherte TLB-Einträge veraltet sein. Der Kernel muss sie daher explizit aus dem TLB löschen, damit sie bei der nächsten Verwendung neu geladen werden. Dazu verwendet er CPU-Befehle wie INVLPD (x86 allgemein) oder INVLPGA (bei AMD), sowie koordinierte TLB Shootdowns, bei denen andere Prozessoren über Interrupts zum Löschen ihrer TLB-Einträge aufgefordert werden. Das ist notwendig, da in einem Mehrprozessorsystem jede CPU ihren eigenen TLB besitzt, der jeweils ungültige Einträge vorhalten kann.

Diese Operationen sind bei vielen CPUs oder beim Löschen vieler TLB-Einträge besonders aufwendig. Bei einem TLB-Shootdown setzt der Kernel sogenannte „Inter-Processor Interrupts“ (IPI) ein, um andere CPUs zum Löschen ihrer TLB-Einträge aufzufordern. Besonders zeitintensiv ist das Warten darauf, dass alle betroffenen Prozessoren die Interrupts empfangen und bearbeiten. Außerdem lässt sich in einem IPI immer nur ein TLB-Eintrag zum Löschen mit auf den Weg geben.

Mit Linux 6.15 bringt ein von Meta beigesteuerter Patch für AMD-Prozessoren eine deutlich effizientere Lösung. Linux setzt nun den AMD-spezifischen CPU-Befehl INVLPGB ein. Der Befehl ist seit der Zen 3-Architektur verfügbar, die AMD im November 2020 einführte. Der Clou: INVLPGB muss weder auf die Verarbeitung von Interrupts warten, noch ist er auf das Löschen einzelner Einträge beschränkt. Mehrere TLB-Einträge lassen sich in einem einzigen Broadcast entfernen. Dieses Zusammenfassen mehrerer TLB-Einträge beim Löschen und die entfallende Wartezeit sollen für einen Leistungsschub sorgen.

Einheitliches Firmware-Management

Linux 6.15 führt das neue Subsystem fwctl (Firmware Control) ein. Es stellt eine standardisierte und sichere Schnittstelle für die Verwaltung von Firmware direkt aus dem Userspace bereit. Bislang mangelt es an einheitlichen und geräteunabhängigen Methoden zum Konfigurieren und Provisionieren sowie Fehlerdiagnose von Firmware.

Moderne Hardware enthält oft umfangreiche Komponenten mit jeweils eigener Firmware. Da eine einheitliche Methode bislang fehlte, braute jeder ein eigenes Süppchen. Schließlich führte das zu einem „Wildwuchs“ an fragmentierten und unsicheren Lösungen. fwctl tritt an, das zu ändern.

Sicherheit und Kompatibiltät

fwctl ist ein Kernel-Subsystem, das es ermöglicht, über Remote Procedure Calls (RPCs) mit der Firmware eines Geräts zu kommunizieren – etwa, um neue Firmware zu übertragen. Diese Kommunikation erfolgt über eine standardisierte Schnittstelle, die auf IOCTLs basiert und über /dev/fwctlX-Gerätedateien zugänglich ist. Damit können verschiedene Aufgaben durchgeführt werden, zum Beispiel das Auslesen von Debug-Informationen, die Konfiguration von Geräten oder das Provisionieren von Hardware.

fwctl implementiert dabei Sicherheitsmechanismen, die den Zugriff auf sensible Funktionen gezielt kontrollieren. Es definiert verschiedene Zugriffsebenen (Scopes) für RPCs, um den Grad des Zugriffs auf die Firmware zu steuern. Beispielsweise erfordert vollständiger Debug-Zugriff spezielle Berechtigungen und markiert den Kernel als „tainted“ (wörtlich „verschmutzt“ oder „unsauber“). Ein „tainted“ Kernel signalisiert allgemein, dass sich der Kernel in einem modifizierten oder potenziell unsicheren Zustand befindet – etwa durch nicht unterstützte Treiber oder tiefgehende Debug-Zugriffe.

Zudem gewährleistet fwctl die Kompatibilität mit bestehenden Kernel-Subsystemen wie RDMA, DRM oder VFIO. So wird vermieden, dass Anwendungen auf gerätespezifische Schnittstellen zugreifen müssen, die sich künftig möglicherweise ändern.

Mounts im Fokus

Mit dem Kernel 2.6.36 hielt fanotiy (file access notify) als Schnittstelle für Echtzeitvirenscanner Einzug. Es dient ursprünglich zum Überwachen, Benachrichtigen und Unterbinden von Dateisystemzugriffen. So konnte damit der Echtzeitvirenscan ermöglicht werden. fanotify mauserte sich über die Jahre zur eierlegenden Wollmilchsau. Beispielsweise baut systemd auf den Read-Ahead von fanotify, um Inhalte von Dateien in weiser Voraussicht komplett ins RAM einzulesen und den Zugriff darauf zu beschleunigen.

Linux 6.15 dopt die Wollmilchsau erneut. fanotify erlaubt nun das Registrieren, um über das Ein- und Aushängen von Dateisystemen informiert zu werden. Statt wie bisher /proc//mountinfo pollend und damit teuer im Auge zu behalten, lehnt sich der Prozess ab jetzt entspannt zurück und lässt sich über Änderungen bei den Mounts informieren. Der Kernel weiß, wann ein Mount hinzu- oder wegkommt. Er hängt schließlich ein und aus. Ein ständig nachfragender Prozess ist da ziemlicher Overhead.

Der Kernel führt für fanotify die Benachrichtigungsmasken FAN_MNT_ATTACH und FAN_MNT_DETACH zum Überwachen des Ein- beziehungsweise Aushängens eines Dateisystems ein. Als Benachrichtigung erhält der registrierte Prozess die Mount-ID des betroffenen Dateisystems. Damit lassen sich über System-Calls listmount() und statmount() anschließend nähere Informationen über den Mount in Erfahrung bringen. Die beiden System-Calls sind erst in Linux 6.8 eingeführt und in 6.11 nochmals erweitert worden. Auch diesmal erweitern die Programmierer den System-Call statmount(), der jetzt auch Informationen über die auf dem Mount angewendeten ID-Mappings enthält.

ID-mapped von ID-mapped

Außerdem hebt die neue Kernel-Inkarnation die „ID-mapped Mounts“ auf eine neue Stufe. Linux 6.15 erlaubt nun das Erzeugen von ID-mapped Mounts auch von bestehenden ID-mapped Mounts. Bislang funktionierte das nur von Dateisystemen, die keinem ID-Remapping unterlagen.

Da bereits zum wiederholten Male an ID-Remapping geschraubt wird, haben sich die ID-mapped Mounts und der damit verbundene „Wasserkopf“ als etabliert angesehen. Beim Erscheinen des Kernels 5.12 war das noch nicht ganz abzusehen.

Dieser Link ist leider nicht mehr gültig.

Links zu verschenkten Artikeln werden ungültig,
wenn diese älter als 7 Tage sind oder zu oft aufgerufen wurden.

Sie benötigen ein heise+ Paket, um diesen Artikel zu lesen. Jetzt eine Woche unverbindlich testen – ohne Verpflichtung!