Vorletzten Sonntag gab Linus Torvalds das letzte Release des Linux-Kernels für dieses Jahr frei. Der neue Kernel 5.10 erfährt Long Term Support (LTS) und erhält somit mindestens für die nächsten zwei Jahre noch Patches.
Aktuell gibt kernel.org als "End of Life" (EOL) Dezember 2022 an. In der Regel geht die Wartungsperiode für LTS-Kernel jedoch für bis zu fünf oder sechs Jahre in die Verlängerung – so wurde etwa der Supportzeitraum für die Ausgaben 4.19 und 5.4 im Sommer von zwei auf sechs Jahre ausgedehnt.
Erstes Point-Release verfügbar, zügiges Update ratsam
Linux 5.10 übertrifft in der Anzahl von Changesets seinen Vorgänger Linux 5.9, bleibt aber leicht hinter dem aktuellen Rekordhalter Linux 5.8 zurück. "Rekordverdächtig" (im Hinblick auf die Geschwindigkeit) ist allerdings das keine 24 Stunden nach dem Release von 5.10 nachgeschobene erste Point-Release. Linux 5.10.1 hatte Greg Kroah-Hartman wegen zwei Fehlern freigeben, die das Storage-System und damit eine kritische Komponente betrafen.
Der erste in 5.10.1 enthaltene Fix nimmt einen Reparaturversuch für den Device Mapper zurück: Hier war ursprünglich versucht worden, Probleme bei der Obergrenze des RAID DISCARD für RAID 1 und RAID 10 zu beheben. Welche Auswirkungen dieser misslungene Korrekturversuch hat, ist aktuell noch nicht dokumentiert. Der Commit zum Fix enthält lediglich den Kommentar: "It causes problems :(."
Der zweite Fix in 5.10.1 betrifft den MD (Multiple Devices)-Code: In 5.10 ohne den Fix kann es beim Mounten von RAID6-Setups zu erheblichen Problemen nebst Datenverlust kommen. Anwender von 5.10 sollten daher rasch auf 5.10.1 wechseln. Weitere Korrekturen oder Neuerungen umfasst 5.10.1 nicht.
Frisch eingezogen: ARM Memory Tagging Extension
Mit Linux 5.10 hält die "ARMv8.5 Memory Tagging Extension" (ARMv8.5 MTE) auf ARM64 Einzug in den Kernel. Sie hängt an Zeiger (Pointer) einen Schlüssel an, um automatisch die (Prozess-)Zugehörigkeit eines Zeigers zu markieren und zu erkennen. Auf diese Weise soll Code künftig sicherer und insbesondere Angreifern das Leben erschwert werden. Zudem will man typische Memory-Bugs im Keim ersticken.
Die ARM64-Architektur ist für 64-Bit-Zeiger ausgelegt. Aktuell verwenden Systeme aber nur 48 Bits oder 52 Bits, sofern die "Large Address Option" aktiviert ist. Für das Verwenden aller verfügbaren 64 Bits besteht aktuell (noch) kein Bedarf. Zudem gestatten es ARM-Prozessoren über ein spezielles Feature, das oberste Byte einer virtuellen Adresse zu ignorieren (top byte ignore). Daher entstanden diverse Erweiterungen für diese ungenutzten Bits. Ein prominenter Vertreter ist die "ARM Pointer Authentication", die kryptographische Schlüssel im obersten Byte zur Authentisierung von Zeigern nutzt. Mit MTE kommt nun noch eine Erweiterung in Linux hinzu.
Die MTE nutzt das untere Nibble (die unteren vier Bits) des oberen Bytes der virtuellen Adresse. Es lässt sich damit einem oder mehreren Speicherbereichen eine Markierung zuweisen. Wird ein Zeiger dereferenziert, vergleicht das System die Markierung des Zeigers mit der des Speicherbereichs, auf den der Zeiger verweist. Sind die beiden Markierungen nicht identisch, löst die CPU einen so genannten Trap aus: Der unerlaubte Zugriff wird unterbunden.
MTE in Aktion
Vier Bits erscheinen nicht viel, lassen sich damit doch "nur" 16 Markierungen verwalten. In der Praxis ist das meist schon ausreichend, um effektive Schutzfunktionen zu implementieren. Mit Speicherverwaltungsroutinen wie malloc() und free() können so auf einfache Weise bestehende Anwendungen um Schutzmechanismen erweitert werden. Beispielsweise lassen sich Use-After-Free-Bugs und Buffer-Overflow-Angriffe verhindern oder zumindest erschweren. malloc() setzt passende Markierungen und versucht zumindest über eine Rotation der Marken verschiedene Stack-Frames unterschiedlich zu markieren. Damit schottet das System diese innerhalb einer Anwendung gegeneinander ab.
Gibt das System Speicher über free() frei, kann dieser freie Speicher mit einer speziellen Marke versehen werden. Damit ist dieser explizit als "frei gegeben" markiert. Will die Anwendung infolge eines Bugs oder aufgrund eines Angriffs diesen Speicher lesen, stimmen die Marker des Zeigers und des Speicherbereichs nicht überein. Das System löst einen Trap infolge einer Use-After-Free-Situation aus.
Die Markierungen kann entweder die Anwendung selbst oder die CPU verwalten. Setzen lassen sich die Marken dabei jeweils auf 16-Byte-Speicherblöcke. MTE ist dabei zunächst auf allen Linux-Systemen deaktiviert. Die Extension lässt sich aus der Anwendung heraus über das PROT_MTE-Flag von mmap() oder über mprotect() aktivieren; eine entsprechende ARM64-CPU vorausgesetzt. PROT_MTE ist allerdings nur auf anonymem Memory gültig. File-Backed Memory wird nicht unterstützt.
Aktuell ist MTE auf den Userspace begrenzt. Der Kernel selbst nutzt das Feature noch nicht. Support für den Kernelspace ist für Linux 5.11 geplant. Mit der "ARM Pointer Authentication" steht MTE im Übrigen nicht in Konflikt. Obwohl beide Erweiterungen das obere Byte der virtuellen Adresse nutzen, können beide gleichzeitig im Einsatz sein. Durch die vier Bits, die MTE vom oberen Byte "abgräbt", verkürzen sich die kryptographischen Signaturen der Pointer-Authentication. Die kann jedoch grundsätzlich auch mit den verkürzten Signaturen arbeiten.
"Schlafenszeit" für manche BPF-Programme
Der BPF (Berkeley Packet Filter) ist seiner ursprünglichen Motivation, Pakete anhand ihres Inhalts flexibel weiterzuleiten, längst entwachsen. Er unterstützt – neben dem modernen Dialekt "extended BPF" (eBPF) – inzwischen Helper-Funktionen, Zugriff auf Datenstrukturen im Kernel- und Userspace sowie die Synchronisation mit Spinlocks. Dennoch hat sich die atomare Natur von BPF-Programmen nicht verändert. Sie müssen alles unterlassen, was einen Thread in einen Sleep versetzt. Aus der Sicht der ursprünglich in der Paketverarbeitung im Network-Stack beheimateten BPF ist das nicht verwunderlich: Netzwerkpakete müssen verarbeitet werden, sobald sie eintreffen, und beim Blockieren oder Schlafen wäre zumindest an dieser Stelle ein Kollaps vorprogrammiert.
Mit Linux 5.10 ist es nun möglich, beim Laden eines BPF-Programms das neue Flag BPF_F_SLEEPABLE mitzugeben, um das Programm als "sleepable" zu markieren. Sinnvoll und zulässig ist das nur bei bestimmten Programmtypen. Diese können dann beispielsweise auch Funktionen wie bpf_copy_from_user() verwenden, um Daten aus dem Userspace in den Kernelspace zu kopieren. Bei Daten aus dem Userspace ist nicht garantiert, dass diese im RAM liegen. Sie müssen gegegenenfalls aus dem Swap eingelagert werden. Daher müssen sich Programme immer "bewusst" sein, dass diese Operation blockiert und der entsprechende Thread dann in den Sleep-Zustand geht. Aus diesem Grund war BPF-Programmen der Zugang zu Funktionen wie copy_from_user() bislang verwehrt – für solche aus der Kategorie "sleepable" ändert sich das jetzt.
Verbesserungen für die Dateisysteme
Bislang konnte XFS lediglich mit Datumsangaben bis 2038 umgehen. Mit Linux 5.10 ist das Dateisystem nun in der Lage, Daten bis ins Jahr 2486 abzubilden. Damit wurde wieder eines der wenigen noch verbliebenen Probleme rund um "Year 2038" im Kernel gefixt. Zudem ist vorgesehen, dass XFS V4 im Jahr 2030 ausgemustert wird. Anwender haben damit zehn Jahre lang Zeit, auf das moderne XFS V5 umzusteigen. XFS V5 bietet neben dem Fix fürs Jahr 2038 auch eine bessere Metadatenvalidierung, unterstützt das Reflink-Feature und erlaubt die Online-Dateisystemprüfung mittels fsck.
ext4 wartet mit neuen "Fast Commits" auf. Der von Google eingereichte Change richtet sich an ext4-Anwender, die Dateisysteme im Ordered-Mode einhängen ("Option data=ordered"). Das neue Feature verwaltet ein minimales Delta, um die betreffenden Metadaten beim Fast-Commit mit Hilfe des JDB2-Journals wiederherzustellen. Das kann die Schreibgeschwindigkeit um bis zu 103 Prozent im Ordered-Mode beschleunigen, wenn die Fast-Commits aktiv sind.
Auch btrfs kann mit Performance-Verbesserungen in Verbindung mit fsync() glänzen. Ebenso verbessert Linux 5.10 F2FS und den NFS-Client-Code.
Grafik und weitere Features
Die Unterstützung für Raspberry Pi VC4 ist im Mainline-Kernel angekommen. Der Display-Support für Raspberry Pi 4 ist damit einsatzbereit. Grundlage ist Mesa 20.3, das den V3DV-Vulkan-Treiber für Raspberry Pi 4 einführt. Im AMD-GPU-Bereich unterstützt Linux 5.10 Display Core (DC) für GCN 1.0 "Southern Islands"-GPUs.
Linux unterstützt die "AMD Secure Encrypted Virtualization" (SEV) schon seit Kernel 4.15. Damit ist es möglich, den Arbeitsspeicher von Gastsystemen zu verschlüsseln, sodass das Hostsystem auf den Inhalt keinen Zugriff hat und somit nicht ausspähen kann. Im neuen Kernel kommt nun auch die Unterstützung für "Ecrypted State" (SEV-ES) hinzu. Damit werden auch die Inhalte der CPU-Register des Gastsystems verschlüsselt, womit die Abschottung gegenüber dem Host vollständig wird.
Zudem bricht Linux 5.10 mit einem fast 30-jährigen Erbe: Das Ende des unsicheren set_fs()-Mechanismus, der nachfolgenden Userspace-Funktionen Zugriff auf den Kernelspace gestattet, wurde eingeläutet. Die Funktion war in der Vergangenheit mehrfach für Sicherheitslücken verantwortlich. Den Hintergründen haben wir bereits vor einiger Zeit eine eigene ausführliche Meldung gewidmet:
Kleines Streichkonzert
Der ursprüngliche PowerPC 601, und damit das Reanimieren alter "32-Bitter" wie PowerMacs, wird künftig nicht mehr unterstützt. Ebenfalls dem Rotstift zum Opfer gefallen ist das "IA64 Performance Monitoring". Anwender von Itanium werden dieses Feature allerdings wohl kaum vermissen; es hatte über die Jahre nie wirklich funktioniert. Ernüchternd mag eher sein, dass keine Bemühungen mehr unternommen werden, das Feature überhaupt noch zum Laufen zu bringen.
Alle Neuerungen listen das Changelog zu Linux 5.10 beziehungsweise das Changelog zum Point-Release 5.10.1 auf.
Quelle: Long-Term-Release Linux 5.10: Die wichtigsten Neuerungen im Überblick | heise online