Nach zwei Monaten Entwicklung stellte Linus Torvalds die Version des Linux-Kernels 5.18 vor. Zu den bemerkenswertesten \u00c4nderungen geh\u00f6ren: eine umfassende Bereinigung veralteter Funktionen, die Erkl\u00e4rung des Reiserfs-Dateisystems als obsolet, die Implementierung von Ereignissen zur Nachverfolgung von Benutzerprozessen, die Hinzuf\u00fcgung von Unterst\u00fctzung f\u00fcr den Sicherheitsmechanismus Intel IBT, die Aktivierung eines \u00dcberlauf-Detection-Modus bei Verwendung der memcpy()-Funktion, die Einf\u00fchrung eines Mechanismus zur Verfolgung von Funktionsaufrufen (fprobe), die Verbesserung der Leistung des CPU-Schedulers auf AMD Zen und die Integration eines Treibers zur Verwaltung von Intel-CPU-Funktionen (SDS). Zudem wurden einige Patches zur Restrukturierung von Header-Dateien integriert und die Verwendung des C11-Standards genehmigt. <\/p>\n
In der neuen Version wurden 16.206 Korrekturen von 2.127 Entwicklern vorgenommen (in der vorherigen Version gab es 14.203 Korrekturen von 1.995 Entwicklern), die Patchgr\u00f6\u00dfe betr\u00e4gt 108 MB (die \u00c4nderungen betreffen 14.235 Dateien, hinzugef\u00fcgt wurden 1.340.982 Zeilen Code, 593.836 Zeilen wurden gel\u00f6scht). Etwa 44 % aller \u00c4nderungen in 5.18 betreffen Ger\u00e4tetreiber, ungef\u00e4hr 16 % beziehen sich auf die Aktualisierung von Architektur-spezifischem Code, 11 % betreffen den Netzwerkstack, 3 % die Dateisysteme und 3 % interne Subsysteme des Kernels. <\/p>\n
Hauptneuheiten im Kernel 5.18: <\/p>\n
\n
Festplattensubsystem, Ein-\/Ausgabe und Dateisysteme<\/b>\n
\n
Im Btrfs-Dateisystem wurde Unterst\u00fctzung f\u00fcr die Durchleitung komprimierter Daten bei den send- und receive-Operationen hinzugef\u00fcgt. Vorher wurde bei der Verwendung von send\/receive die sendende Seite gezwungen, die komprimierten Daten zu dekomprimieren, w\u00e4hrend die empfangende Seite sie vor dem Schreiben erneut komprimierte. Im Kernel 5.18 haben Anwendungen im Benutzerspeicher, die send\/receive-Aufrufe verwenden, die M\u00f6glichkeit, komprimierte Daten ohne Neuverpackung zu \u00fcbertragen. Diese Funktionalit\u00e4t wurde durch neue ioctl-Operationen BTRFS_IOC_ENCODED_READ und BTRFS_IOC_ENCODED_WRITE erm\u00f6glicht, die ein direktes Lesen und Schreiben von Informationen in Extents erlauben.\n
Dar\u00fcber hinaus wurde die Leistung von fsync in Btrfs verbessert. Es wurde die M\u00f6glichkeit zur Deduplizierung und zur Durchf\u00fchrung von Reflink (Klonen von Dateimetadaten mit Erstellung eines Links zu bereits vorhandenen Daten ohne deren tats\u00e4chliche Kopie) f\u00fcr das gesamte Speicherger\u00e4t hinzugef\u00fcgt, ohne auf die Einh\u00e4ngepunkte beschr\u00e4nkt zu sein. <\/p>\n
Im Modus direkten Eingangs\/Ausgangs (Direct I\/O) ist der Zugriff auf verschl\u00fcsselte Dateien unter Verwendung von fscrypt Inline-Verschl\u00fcsselung m\u00f6glich, bei der die Verschl\u00fcsselungs- und Entschl\u00fcsselungsoperationen von dem Speichercontroller und nicht vom Kernel durchgef\u00fchrt werden. Bei herk\u00f6mmlicher Verschl\u00fcsselung durch den Kernel ist der Zugriff auf verschl\u00fcsselte Dateien \u00fcber Direct I\/O nach wie vor nicht m\u00f6glich, da der Zugriff auf die Dateien den Puffermechanismus im Kernel umgeht.\n
Auf dem NFS-Server ist standardm\u00e4\u00dfig die Unterst\u00fctzung des Protokolls NFSv3 aktiviert, das nun keine separate Aktivierung mehr erfordert und beim allgemeinen Aktivieren von NFS verf\u00fcgbar ist. NFSv3 wird als die prim\u00e4re und stets unterst\u00fctzte Version von NFS betrachtet, w\u00e4hrend die Unterst\u00fctzung von NFSv2 m\u00f6glicherweise in Zukunft eingestellt wird. Die Effizienz beim Lesen des Inhalts von Verzeichnissen wurde erheblich verbessert.\n
Das Dateisystem ReiserFS wurde als veraltet eingestuft und wird 2025 entfernt. Die Einstufung von ReiserFS als veraltet erm\u00f6glicht eine Verringerung des Aufwands f\u00fcr die Wartung allgemeiner \u00c4nderungen an Dateisystemen in Bezug auf die Unterst\u00fctzung neuer APIs f\u00fcr das Einh\u00e4ngen, iomap und Folios.\n
F\u00fcr das FS F2FS wurde die M\u00f6glichkeit implementiert, Benutzer-IDs von eingeh\u00e4ngten Dateisystemen zuzuordnen, die verwendet wird, um Dateien eines bestimmten Benutzers auf einem fremden eingeh\u00e4ngten Laufwerk einem anderen Benutzer im aktuellen System zuzuordnen.\n
Der Code zur Berechnung von Statistiken in den Device-Mapper-Handlern wurde \u00fcberarbeitet, was die Genauigkeit der Abrechnung in solchen Handlern wie dm-crypt erheblich verbessert hat.\n
F\u00fcr NVMe-Ger\u00e4te wurde die Unterst\u00fctzung f\u00fcr 64-Bit-Pr\u00fcfziffern zur \u00dcberpr\u00fcfung der Integrit\u00e4t implementiert.\n
F\u00fcr das Dateisystem exfat wurde eine neue Montageoption \"keep_last_dots\" vorgeschlagen, die das Entfernen von Punkten am Ende des Dateinamens verhindert (unter Windows werden Punkte am Ende des Namens standardm\u00e4\u00dfig entfernt).\n
In EXT4 wurde die Leistung des fast_commit-Modus verbessert und die Skalierbarkeit erh\u00f6ht. Die Montageoption \"mb_optimize_scan\", die die Leistung unter starker Fragmentierung des FS verbessert, wurde f\u00fcr die Arbeit mit Dateien mit Extents angepasst.\n
Die Unterst\u00fctzung f\u00fcr Schreibstr\u00f6me (write stream) im Teilsystem, das den Betrieb blockbasierter Ger\u00e4te gew\u00e4hrleistet, wurde eingestellt. Diese Funktion wurde f\u00fcr SSDs vorgeschlagen, fand jedoch keine Verbreitung, und derzeit gibt es keine Ger\u00e4te, die diesen Modus unterst\u00fctzen. Es ist unwahrscheinlich, dass solche Ger\u00e4te in Zukunft erscheinen werden. <\/ul>\n
Speicher und Systemdienste<\/b>\n
\n
Die Integration eines Patch-Sets, das die Neuaufbauzeit des Kernels erheblich verk\u00fcrzt, hat begonnen. Dies geschieht durch die Umstrukturierung der Hierarchie der Header-Dateien und die Reduzierung der Anzahl der Kreuzabh\u00e4ngigkeiten. Die Kernelversion 5.18 enth\u00e4lt Patches, die die Struktur der Header-Dateien des Prozessplaners (kernel\/sched) optimieren. Im Vergleich zur vorherigen Version wurde der CPU-Zeitverbrauch beim Bauen des Codes kernel\/sched um 61 % reduziert, und die tats\u00e4chliche Build-Zeit verringerte sich um 3,9 % (von 2,95 auf 2,84 Sekunden).\n
Im Kernel-Code wurde die Verwendung des C11-Standards, ver\u00f6ffentlicht im Jahr 2011, erm\u00f6glicht. Der zuvor in den Kernel hinzugef\u00fcgte Code musste der ANSI C-Spezifikation (C89) entsprechen, die bereits 1989 erstellt wurde. In den Build-Skripten des Kernels 5.18 wurde die Option \u2018--std=gnu89\u2019 durch \u2018--std=gnu11 -Wno-shift-negative-value\u2019 ersetzt. Es wurde in Betracht gezogen, den C17-Standard zu verwenden, aber in diesem Fall m\u00fcsste die minimal unterst\u00fctzte GCC-Version erh\u00f6ht werden, w\u00e4hrend die Unterst\u00fctzung von C11 den aktuellen Anforderungen an die GCC-Version (5.1) entspricht.\n
Die Leistung des Task-Schedulings auf AMD-Prozessoren mit der Mikroarchitektur Zen wurde verbessert. Diese besitzen mehrere Last-Level-Caches (LLC) f\u00fcr jeden Knoten mit lokalen Speicherkana\u0308len. In der neuen Version wurde das Ungleichgewicht zwischen den LLCs in NUMA-Knoten behoben, was unter bestimmten Lasten zu einer erheblichen Leistungssteigerung f\u00fchrte.\n
Die Mittel zur Nachverfolgung von Anwendungen im Benutzermodus wurden erweitert. In der neuen Kernversion wurde die M\u00f6glichkeit hinzugef\u00fcgt, dass Benutzerprozesse Nachverfolgungsereignisse (User events) erstellen und Daten in den Nachverfolgungspuffer schreiben k\u00f6nnen. Diese k\u00f6nnen dann \u00fcber g\u00e4ngige Nachverfolgungswerkzeuge des Kernels, wie ftrace und perf, eingesehen werden. Benutzer-Tracking-Ereignisse sind von den Ereignissen des Kernel-Trackings isoliert. Der Status der Ereignisse kann \u00fcber die Datei \/sys\/kernel\/debug\/tracing\/user_events_status eingesehen werden, w\u00e4hrend die Registrierung eines Ereignisses und das Schreiben von Daten \u00fcber die Datei \/sys\/kernel\/debug\/tracing\/user_events_data erfolgt.\n
Ein Mechanismus zur Verfolgung (Probe) von Funktionsaufrufen wurde hinzugef\u00fcgt - fprobe. Die API von fprobe basiert auf ftrace, ist jedoch nur auf die M\u00f6glichkeit beschr\u00e4nkt, Callback-Handler an Einstiegs- und Ausgangspunkte von Funktionen anzuh\u00e4ngen. Im Gegensatz zu kprobes und kretprobes erm\u00f6glicht der neue Mechanismus die Verwendung eines Handlers f\u00fcr mehrere Funktionen gleichzeitig.\n
Die Unterst\u00fctzung \u00e4lterer ARM-Prozessoren (ARMv4 und ARMv5), die nicht mit einer Speicherverwaltungseinheit (MMU) ausgestattet sind, wurde eingestellt. Die Unterst\u00fctzung f\u00fcr ARMv7-M-Systeme ohne MMU bleibt bestehen.\n
Die Unterst\u00fctzung der RISC-\u00e4hnlichen Architektur NDS32, die in Prozessoren von Andes Technologies verwendet wurde, wurde eingestellt. Der Code wurde aufgrund fehlender Wartung und des mangelnden Bedarfs an NDS32-Unterst\u00fctzung im Hauptkern von Linux entfernt (die verbleibenden Nutzer verwenden spezialisierte Kernel-Builds von Hardwareherstellern).\n
Die Kernel-Kompilierung mit Unterst\u00fctzung f\u00fcr das Format a.out f\u00fcr die Architekturen alpha und m68k, in denen dieses Format weiterhin verwendet wird, ist standardm\u00e4\u00dfig deaktiviert. Es ist wahrscheinlich, dass die Unterst\u00fctzung des veralteten Formats a.out bald vollst\u00e4ndig aus dem Kernel entfernt wird. Pl\u00e4ne zur Entfernung des Formats a.out werden seit 2019 diskutiert.\n
F\u00fcr die PA-RISC-Architektur wurde eine minimale Unterst\u00fctzung des vDSO-Mechanismus (virtual dynamic shared objects) implementiert, der eine begrenzte Anzahl von Systemaufrufen bereitstellt, die im Benutzerspeicher ohne Kontextwechsel verf\u00fcgbar sind. Die Unterst\u00fctzung von vDSO erm\u00f6glicht die Ausf\u00fchrung mit einem nicht ausf\u00fchrbaren Stapel.\n
Die Unterst\u00fctzung des Intel HFI (Hardware Feedback Interface) wurde hinzugef\u00fcgt, das es der Hardware erm\u00f6glicht, dem Kernel Informationen \u00fcber die aktuelle Leistung und Energieeffizienz jedes CPU zu \u00fcbermitteln.\n
Ein Treiber f\u00fcr den Intel SDSi (Software-Defined Silicon) Mechanismus wurde hinzugef\u00fcgt, der die Aktivierung zus\u00e4tzlicher Funktionen im Prozessor erm\u00f6glicht (z. B. spezielle Instruktionen und zus\u00e4tzlichen Cache-Speicher). Die Idee besteht darin, dass Chips zu einem niedrigeren Preis mit deaktivierten erweiterten Funktionen geliefert werden, die dann \u201anachgekauft\u2018 und ohne Hardware-Austausch aktiviert werden k\u00f6nnen.\n
Der Treiber amd_hsmp wurde hinzugef\u00fcgt, um die Schnittstelle AMD HSMP (Host System Management Port) zu unterst\u00fctzen, die den Zugriff auf Funktionen zur Prozessorsteuerung \u00fcber einen Satz spezieller Register erm\u00f6glicht, die in den Serverprozessoren AMD EPYC ab der Generation Fam19h eingef\u00fchrt wurden. Beispielsweise kann \u00fcber HSMP auf Daten zum Energieverbrauch und zur Temperatur zugegriffen, Frequenzgrenzen gesetzt, verschiedene Leistungssteigerungsmodi aktiviert und die Speicheroperationen verwaltet werden.\n
Im io_uring-Schnittstelle f\u00fcr asynchronen Ein-\/Ausgabe wurde die Option IORING_SETUP_SUBMIT_ALL f\u00fcr die Registrierung eines Sets von Dateideskriptoren im Ring-Puffer implementiert, sowie die Operation IORING_OP_MSG_RING, die es erm\u00f6glicht, ein Signal von einem Ring-Puffer in einen anderen Ring-Puffer zu senden.\n
Im Mechanismus DAMOS (Data Access Monitoring-based Operation Schemes), der das Freigeben von Speicher unter Ber\u00fccksichtigung der Zugriffsfrequenz auf den Speicher erm\u00f6glicht, wurden die M\u00f6glichkeiten zur \u00dcberwachung von Speicheroperationen im Benutzerspeicherraum erweitert.\n
Die dritte Serie von Patches zur Umsetzung des Konzepts von Seitenfolios (page folios) wurde integriert, die an verbundene Seiten (compound pages) erinnern, jedoch durch eine verbesserte Semantik und eine klarere Arbeitsorganisation unterscheiden. Der Einsatz von Folios erm\u00f6glicht eine schnellere Speicherverwaltung in einigen Kernsubsystemen. In den vorgeschlagenen Patches wurde die Umstellung auf Folios interner Speicherverwaltungsfunktionen, einschlie\u00dflich Varianten der Funktion get_user_pages(), vorgenommen. Die Unterst\u00fctzung f\u00fcr die Erstellung gro\u00dfer Folios im Code f\u00fcr vorab geladenen Daten wurde bereitgestellt.\n
Im Build-System wird die Unterst\u00fctzung f\u00fcr die Umgebungsvariablen USERCFLAGS und USERLDFLAGS eingef\u00fchrt, mit denen zus\u00e4tzliche Flags an den Compiler und den Linker \u00fcbergeben werden k\u00f6nnen.\n
Im eBPF-Subsystem wurde im Mechanismus BTF (BPF Type Format), der Informationen zur Typpr\u00fcfung im BPF-Pseudocode bereitstellt, die M\u00f6glichkeit implementiert, Anmerkungen zu Variablen hinzuzuf\u00fcgen, die auf Speicherbereiche im Benutzerspeicher verweisen. Diese Anmerkungen unterst\u00fctzen das BPF-Code-Verifizierungssystem dabei, Speicherzugriffe qualitativ besser zu identifizieren und zu \u00fcberpr\u00fcfen.\n
Ein neuer Handler f\u00fcr die Speicherzuweisung zur Speicherung geladener BPF-Programme wurde vorgeschlagen, der eine effizientere Nutzung des Speichers in Situationen erm\u00f6glicht, in denen eine gro\u00dfe Anzahl von BPF-Programmen geladen wird.\n
Im Systemaufruf madvise() wurde das Flags MADV_DONTNEED_LOCKED hinzugef\u00fcgt, das das bereits vorhandene Flags MADV_DONTNEED erg\u00e4nzt. Damit kann der Kernel im Voraus \u00fcber die bevorstehende Freigabe eines Speicherblocks informiert werden, d.h. dass dieser Block nicht mehr ben\u00f6tigt wird und vom Kernel verwendet werden kann. Im Gegensatz zu MADV_DONTNEED ist die Verwendung des Flags MADV_DONTNEED_LOCKED f\u00fcr in RAM festgelegte Seiten erlaubt, die bei einem Aufruf von madvise ohne \u00c4nderung ihres festen Status verdr\u00e4ngt werden und im Falle eines sp\u00e4teren Zugriffs auf den Block und der Generierung eines \u201epage fault\u201c mit der Bindung zur\u00fcckgegeben werden. Dar\u00fcber hinaus wurde eine \u00c4nderung hinzugef\u00fcgt, die die Verwendung des Flags MADV_DONTNEED mit gro\u00dfen Speicherseiten in HugeTLB erm\u00f6glicht. <\/ul>\n
Virtualisierung und Sicherheit<\/b>\n
\n
F\u00fcr die x86-Architektur wurde die Unterst\u00fctzung des Schutzmechanismus zur Verfolgung indirekter Spr\u00fcnge (IBT, Indirect Branch Tracking) von Intel hinzugef\u00fcgt, der die Anwendung von Techniken zur Erstellung von Exploits unter Verwendung zur\u00fcckkehrend orientierter Programmierung (ROP, Return-Oriented Programming) erschwert. Dabei wird der Exploit in Form einer Kette von Aufrufen bereits im Speicher vorhandener Maschinencode-St\u00fccke gebildet, die mit einem R\u00fcckgabebefehl enden (in der Regel den Enden von Funktionen). Der Kern des implementierten Schutzverfahrens besteht darin, indirekte Spr\u00fcnge in den Funktionsk\u00f6rper zu blockieren, indem zu Beginn der Funktion eine spezielle Anweisung ENDBR hinzugef\u00fcgt wird. Die Ausf\u00fchrung \u00fcber einen indirekten Sprung ist nur zul\u00e4ssig, wenn auf diese Anweisung zugegriffen wird (ein indirekter Aufruf \u00fcber JMP und CALL muss immer auf die ENDBR-Anweisung zeigen, die sich am Anfang der Funktion befindet).\n
Eine strengere \u00dcberpr\u00fcfung der Puffergrenzen in den Funktionen memcpy(), memmove() und memset() wurde aktiviert, die beim Kompilierungsprozess im CONFIG_FORTIFY_SOURCE-Modus durchgef\u00fchrt wird. Die hinzugef\u00fcgte \u00c4nderung besteht darin, das \u00dcberschreiten der Grenzen von Elemente von Strukturen zu \u00fcberpr\u00fcfen, deren Gr\u00f6\u00dfe bekannt ist. Dabei wird festgestellt, dass die implementierte M\u00f6glichkeit alle mit memcpy() in Verbindung stehenden Puffer\u00fcberl\u00e4ufe im Kernel, die in den letzten drei Jahren festgestellt wurden, blockieren k\u00f6nnte.\n