Seite 2: Herausragende Neuerugen von 5.4

Inhaltsverzeichnis

Exfat-Code integriert, aber schon auf der Abschussliste

Linux 5.4 bringt endlich Code zur Unterstützung von Microsofts exFAT-Dateisystem mit. Damit dürfte das Gros der Linux-Distributionen das bei Speicherkarten aktueller Foto- und Video-Kameras häufig anzutreffende Dateisystem bald endlich von Haus aus unterstützen. Bislang war exFAT-Support beim Kernel und einigen Distributionen bewusst außen vor geblieben, da die Gefahr von Patentklagen bestand. Diese Sorge ist jetzt weitgehend vom Tisch, weil Microsoft die exFAT-Patente und -Spezifikationen für Linux öffnet.

Mehr Infos

Dies war ein schrittweise aktualisierter Artikel

Dieser Text wurde mehrfach erweitert, um nach und nach alle wesentlichen Änderungen in Linux 5.4 zu beschreiben. Zur am 25. November 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 integrierte, vor Jahren von Samsung freigegebene und zwischenzeitlich verbesserte exFAT-Code hat allerdings einige größere Qualitätsprobleme, daher landete er nur im Staging-Bereich; dort wird Code mit solchen Mängeln akzeptiert, um ihn dort im Rahmen der Kernel-Entwicklung auf Vordermann zu bringen. Die Aufnahme war allerdings ziemlich umstritten, wie LWN.net in den Artikeln "On-disk format robustness requirements for new filesystems" und "Examining exFAT" erläutert.

Hinzu kommt: Der integrierte exFAT-Code wird vermutlich schon bald wieder verworfen, denn rund um dessen Aufnahme stellte sich heraus, dass Samsung den Code intern weiter entwickelt hat und dadurch mit "sdFAT" jetzt eine deutlich robustere Lösung zur exFAT-Unterstützung hat. Einige Wochen später gegen Ende September erklärten sich Mitarbeiter des Unternehmens dann bereit, eine Variante dieses sdFAT-Codes bald in den offiziellen Kernel einzubringen. Damit aber nicht genug: In der zweiten Oktoberhälfte veröffentlichte dann auch noch ein Entwickler von Paragon Software GmbH anderen, ganz unabhängig vom Samsung-Ansatz entstandenen Code zur exFAT-Unterstützung mit dem Ziel, diesen in den offiziellen Kernel einzubringen. Die Entwickler müssen sich nun noch abstimmen, welche der Ansätze jetzt in den Kernel einfließen soll.

Rechte des Root-Anwenders aus Sicherheitgründen einschränken

Nach vielen Entwicklungsjahren, mehreren Dutzend Anläufen durch zwei verschiedene Programmierer sowie zahlreichen hitzigen Diskussionen hat Linus Torvalds endlich Patches zum "Kernel Lockdown" integriert. Damit kann Linux selbst dem Root-Anwender (User-ID/UID == 0) ein paar bislang mögliche Dinge verwehren, um die Sicherheit des Systems zu verbessern.

Das ist vorwiegend zum Support von Techniken wie UEFI Secure Boot interessant, denn ohne die Einschränkungen, die der Kernel Lockdown ermöglicht, können Angreifer solche Sicherheitsfunktionen leicht aushebeln. Dass das so leicht ist, liegt vor allem an einigen veralteten und dieser Tage vielfach zweifelhaften Kernel-Treibern und -Funktionen, durch die der Root-Anwender teilweise überall im Arbeitsspeicher schreiben kann. Ohne den Lockdown können Angreifer darüber andere Selbstschutzmechanismen des Kernels aushebeln und so etwa hinterrücks Schadcode in den laufenden Kernel einschleusen.

Lockdown jetzt feiner konfigurierbar

UEFI Secure Boot soll gerade solch ein Umgehen von Schutztechniken verhindern, daher enthalten die Kernel nahezu aller großen Distributionen schon lange Vorläufer der jetzt integrierten Lockdown-Patches. Letztere setzen aber etwas anders an, denn um Kritiker zufrieden zu stellen, wurden der Code zwischenzeitlich angepasst, um wie SELinux, AppArmor & Co. als Linux Security Module (LSM) beim Kernel anzudocken.

Außerdem lässt sich der Lockdown jetzt auch vollkommen unabhängig von UEFI Secure Boot nutzen, um ein Ausprobieren zu erleichtern und die Sicherheit auch unabhängig von solchen Firmware-Mechanismen verbessern zu können. Der Lockdown macht es dadurch etwa Root-Kits schwerer, sich tief einzunisten und dabei so gut zu verstecken, dass man den Schadcode nur schwer entdecken kann.

Durch die Umbauten kam auch der Kernel-Parameter lockdown={integrity|confidentiality} und die Sysfs-Datei /sys/kernel/security/lockdown hinzu, über die man das Verhalten steuern kann, sofern Firmware-, Boot-Loader sowie Lockdown-Konfiguration das denn erlauben.

Wie so häufig bringt auch dieser Sicherheitsgewinn einige Nachteile und Einschränkungen mit. So blockieren gängige Lockdown-Konfigurationen einige Funktionen, die manche Anwender sehr schätzen. Darunter ist etwa der Ruhezustand (Hibernate) oder die Möglichkeit, lokal für Distributionskernel kompilierte Kernel-Module nachzuladen, ohne sie zu signieren und Verifikationsschlüssel zu hinterlegen.

Details zum Ganzen finden sich im Merge Commit zu den Lockdown-Patches, einigen der darüber eingeflossenen Commits (u. a. 1) und dem LWN.net-Artikel "Lockdown as a security module".

Nutzung der Datenträger besser regulieren

Über den neuen I/O-Controller Blk-Iocost können Admins besser regeln, wie stark die einer Prozessgruppe zugeordneten Prozesse die Storage-Hardware eines Systems befeuern dürfen. Damit lässt sich etwa verhindern, dass ein Container die Festplatten oder SSDs so stark mit Anfragen beschäftigt, dass andere Prozesse kaum mehr zum Zug kommen und dadurch letztlich extrem langsam laufen.

Für diese Problematik gibt es bereits I/O-Controller. Sie weisen allerdings allerlei bekannte Schwächen auf, die der von einem Facebook-Entwickler eingebrachte Blk-Iocost zu vermeiden verspricht. Mit diesem Cgroup-v2-Controller lässt sich beispielsweise das Leistungspotenzial der Datenträger leichter ausschöpfen, denn er drosselt erst, wenn tatsächlich Engpässe entstehen.

Weitere Details nennt der Kommentar zum Commit mit Blk-Iocost und der darin enthaltenen Erweiterung einer Dokumentationsdatei. Sie beschreibt die für Blk-Iocost eingeführten Cgroup-v2-Konfigurationsschrauben io.cost.qos und io.cost.model. Einige weitere Hintergründe zum Ansatz erläutert ein Artikel bei LWN.net, der noch aus einer Zeit stammt, als der Ansatz noch "Io.Weight Controller" hieß.