Seite 8: Mehr RAM und verkümmernder 32-Bit-x86-Support

Inhaltsverzeichnis

Mehr und mehr Qualitätsmängel bei 32-Bit-x86-Unterstützung

Linux mag mit der 32-Bit-x86-Architektur (auch als IA-32, i386, ix86, … bekannt) seinen Siegeszug angetreten haben – die Qualität des für diese Prozessoren zuständigen Kernel-Codes lässt seit einiger Zeit aber massiv nach, weil sich immer weniger Entwickler dafür interessieren. Das lässt sich schon länger beobachten und zeigte sich jüngst wieder in einer Mail des angesehenen Linux-Entwicklers Andy Lutomirski. In der Mail an eine Mailingliste zur Sicherheit von Open-Source-Software umreißt er einige schwerwiegende Fehler, die teilweise eine ganze Weile im 32-Bit-x86-Code von Linux schwelten. Durch sie waren letztlich sowohl Sicherheit als auch korrekte Funktionsweise von 32-Bit-x86-Kerneln nicht sichergestellt.

Die Mail verschickte Lutomirski, nachdem er die Ursache einiger solcher Fehler korrigiert hatte; diese Änderung floss nicht nur in Linux 5.5 ein, sondern wurde auch in mehrere Stable- und Longterm-Kernel zurückportiert. Die Anpassung soll die gefundene Probleme indes nur "weitgehend" beseitigen – Lutomirski äußert zudem den Verdacht, dass noch mindestens ein weiterer Fehler zurückblieb.

Den vielen Anwendern, die auf einem 64-Bit-x86-Prozessor eine 32-Bit-x86-Linux-Distribution nutzen, rät Lutomirski zum Wechsel auf einen 64-Bit-x86-Kernel – solche sind durch große Verbreitung bei Entwicklern, Testfarmen (CI/Continuous Integration) und Anwendern besser getestet, daher fallen Fehler eher auf. Lutomirski wendet sich zudem an all jene, die 32-Bit-x86-Linux aktiv unterstützen: Sie sollen damit entweder aufhören oder sich bei Entwicklung und Qualitätssicherung im offiziellen Linux-Kernel engagieren.

Ob oder wo das Gehör findet, bleibt abzuwarten. Bei Hardware-Herstellern, die eine der Hauptstützen der Kernel-Entwicklung darstellen, kommt 32-Bit-x86-Linux schließlich nur noch sehr selten zum Einsatz, daher dürfte deren Motivation gering ausfallen. Linux-Distributionen sind normalerweise eine weitere große Stütze – aber alle großen haben den Support für die 32-Bit-x86-Architektur bereits eingestellt oder lassen ihn auslaufen, wenn man von Debian GNU/Linux und openSUSE Tumbleweed absieht. Ähnlich wie beim Support für bereits seit Jahren exotische Prozessorarchitekturen müssen am Ende wohl Freiwillige mit genug Motivation versuchen, die Fahne hochzuhalten.

Bis zu 128 Pebibyte Arbeitsspeicher

Bei neu konfigurierten 64-Bit-x86-Kernel-Images ist das seit Linux 4.14 unterstützte 5-Level-Paging jetzt standardmäßig aktiv. Diese Technik erweitert den Adressraum für Virtual Memory von 48 auf 57 Bit, wodurch die Menge des adressierbaren Arbeitsspeichers um das 512-fache wächst:

von 256 Tebibyte auf 131.072 Tebibyte (128 Pebibyte).

Intel hat Unterstützung für so große Adressräume in einige seiner jüngsten Prozessoren eingebaut, weil sich abzeichnete, dass die bisherige Grenze bei einigen Kunden bald kneifen würde. Die 128 Pebibyte sollten hier auf absehbare Zeit genug Spielraum verschaffen – ähnlich, wie es die 256 Tebibyte taten, die 2003 bei der Einführung der ersten x86-64-Prozessoren mehr als ausreichend erschienen.

Performance für KVM und Emulation für mehr Sicherheit

Wie jüngst üblich enthält auch 5.5 Optimierungen an verschiedenen Stellen, um den Overhead der Spectre-v2-Schutztechnik Retpoline zu reduzieren und so die Geschwindigkeit zu steigern. Bei 5.5 soll davon etwa die Performance bei der Virtualisierung mit KVM (Kernel Virtual Machine) profitieren (u. a. 1, 2, 3, 4).

Einen Sicherheitsgewinn verspricht eine Emulationschicht des Systemaufrufs iopl() auf x86-Systemen, den Userspace-Anwendungen nutzen können, um via IO-Ports mit Hardware zu interagieren (u. a. 1, 2, 3). Ohne diese Schicht können böswillige Anwendungen die Verarbeitung von Interrupts ein- und ausschalten und so das System ins Straucheln bringen. Details zu Gefahren und einen Lösungsansatz erläutert der LWN-net-Artikel "Emulated iopl()".

Unterstützung für neue und uralte Systeme

Neben dem eingangs bereits erwähnten Support für den Raspberry Pi 4 hat Linux auch den Umgang mit einer Reihe weiterer Prozessoren und Single Board Computer (SBC) mit ARM-Kernen gelernt. Dadurch unterstützt Linux jetzt etwa den Freescale S32V234, den Rockchip RK3308, das NanoPi Duo2 (Allwinner) und eine Reihe von Boards mit NXP-Prozessoren.

Linux läuft jetzt auch auf Prozessoren der MIPS Loongson-3A Revision 4 (R4). Apropos MIPS: Einige Entwickler haben Support für SGI Octane/Octane2 Workstations(IP30) nachgerüstet, die vor rund zwei Jahrzehnten produziert wurden.

Fehler abfangen, aber nicht zu viel warnen

Der x86-Code von Linux kann den Zufallszahlengenerator jetzt mit einer Saat (Seed) in Gang bringen, die der Kernel via UEFI erhält. Außerdem prüft der x86-Code jetzt, ob via RDRAND vom Prozessor angeforderte Zufallszahlen allem Anschein nach valide sind; das soll gegen Fehler helfen, wie sie Mitte 2019 bei einigen Prozessoren von AMD bekannt wurden. Apropos AMD: Die Entwickler haben einige Anpassungen im Treiber für MCEs (Machine-check Exceptions) vorgenommen, um ein Problem zu beseitigen, durch das Linux auf vielen Boards mit AMDs neuem Threadripper nur bei Angabe von mce=off startete.

Der Kernel warnt in seinem Protokollausgaben nicht mehr so deutlich, wenn sich der Prozessor drosselt, um sich vor Überhitzung zu schützen. Dazu haben sich die Kernel-Entwickler unter anderem entschlossen, weil dies "Throttling" bei modernen Notebooks deutlich häufiger vorkommt – unter anderem, weil deren Kühlsysteme teilweise nicht mehr für längere Volllast ausgelegt sein sollen.

Der RISC-V-Code von Linux beherrscht jetzt auch den "nommu" genannten Betrieb, was den Einsatz auf Prozessoren ohne Memory Management Unit (MMU) ermöglicht.

Unter den Änderungen am Code zum Betrieb unter Microsofts Hypervisor Hyper-V war Support zum Wechsel in den Ruhezustand (Hibernation).

Bei PCI/PCIe-Geräten lässt sich jetzt via Sysfs (/sys/…) steuern, ob oder wie weit sie die Stromspartechnik ASPM verwenden.

Details zu diesen und weitere Neuerungen rund um den Architektur-Support finden sich in den wichtigsten Kommentaren der wichtigstes Git-Merges der Subsysteme ARC, ARM, ARM64 (1, 2), Armsoc (Defconfig, Driver, DT, Fixes, Platform), Devicetree/DT, EDAC, EFI, KVM, M68K, MIPS, PCI, Power, RAS/Reliability, Availability and Serviceability (1, 2), RISC-V, S390 (1, 2), x86 (ASM, Boot, CPU, Microcode, MM), XEN und Xtensa.