Der erste neue Kernel in diesem Jahr ist im Großen und Ganzen ein Standard-Release: Neue Treiber wurden eingeführt und bestehende Features ausgeweitet. Neu in Linux 5.11 ist die Unterstützung für Intels Sicherheitsfunktion Software Guard Extensions (SGX).
Wir fassen in diesem Artikel die wichtigsten Neuerungen zusammen und werfen außerdem einen Blick auf rege Community-Diskussionen, die sich im Zuge des vorangegangenen LTS-Releases 5.10 entsponnen haben. Eine vollständige Übersicht über alle Änderungen liefert das Changelog zu Linux 5.11.
SGX eingebaut
Nach nunmehr fünf Jahren Entwicklungszeit und über 40 Reviews sind Intels Software Guard Extensions (SGX) im Linux-Kernel angekommen. Mittels SGX lassen sich kryptographisch abgeschottete Bereiche, sogenannte Enklaven, erstellen. Der Zugriff auf die Speicherbereiche dieser Enklaven ist aus dem Rest des Systems und auch aus anderen Enklaven heraus nicht möglich – dies ist nur Code gestattet, der innerhalb der Enklave läuft. Der Aufruf von Programmcode in den Enklaven von außen darf ausschließlich in kontrollierter Form erfolgen. Anwendungsentwicklern soll SGX die Möglichkeit bieten, ihre Software und insbesondere sensible Daten selbst dann vor unbefugten Zugriffen und Manipulationen zu schützen, wenn das Hostsystem kompromittiert wurde.
Diskussionen rund um die Sicherheit von SGX und die Ansätze zur Umsetzung im Linux-Kernel verzögerten die Integration. Nachvollziehbarerweise, wenn man bedenkt, dass die Entdecker von Meltdown und Spectre Anfang 2019 in einer wissenschaftlichen Veröffentlichung erläutert hatten, wie sich SGX-Enklaven mittels der Angriffstechniken "knacken" ließen. Zwischenzeitlich hat Intel jedoch bei der Sicherheitsfunktion nachgebessert, so dass SGX unter Linux hoffentlich unbeeinträchtigt zur Sicherheit beiträgt.
KASAN erweitert
Der Kernel Address Sanitizer (KASAN) ist eine ausgefeilte Technologie zum frühzeitigen und dynamischen Aufspüren von fehlerhaften Speicherzugriffen des Kernels. Im Zusammenspiel mit der Gnu Compiler Collection (GCC) zum Instrumentalisieren von Speicherzugriffen und "Shadow-Memory" zum Tracking von legitimen Speicherbereichen lassen sich Bugs einfacher aufspüren. Da KASAN bereits beim Compile-Vorgang ansetzt, ist die Technik deutlich schneller als reine Runtime-Ansätze wie beispielsweise kmemcheck.
KASAN wurde ursprünglich für x86_64 eingeführt und ist heute auf einigen, aber nicht auf allen Architekturen verfügbar. Mit Linux 5.11 ist KASAN jetzt auch für 32-Bit-ARM implementiert. Eine Verbesserung erfährt die Technologie zudem auf 64-Bit-ARM. Dort kommt statt des Software-Taggings und Shadow-Memory jetzt die "Memory Tagging Extension" fürs Tracking zum Einsatz. Statt eine Karte der legitimen Speicherbereiche zu zeichnen, nutzt KASAN auf ARM64 die oberen nicht genutzten Bits der 64-Bit-Speicheradresse, um legitimen Speicher zu markieren.
Architekturelle Erweiterungen
Auf ARM64-Systemen erweitert Linux 5.11 die Zugriffsmöglichkeiten auf die Memory Type Extension. Die oberen nicht genutzten Bits lassen sich nun auch in Signal-Handlern nutzen, um so beispielsweise auf die Markierungen von Zeigern zuzugreifen. sigaction() erhält hierfür die Option SA_EXPOSE_TAGBITS.
Der Zugriff aus dem Userspace auf MSRs (model-specific registers) auf x86-Systemen wurde weiter reduziert. So ist jetzt der schreibende Zugriff auf MSR_IA32_ENERGY_PERF_BIAS nicht mehr erlaubt. Stattdessen sollen Tools geschaffen werden, die den Zugriff auf die MSRs zentralisieren und – so die Hoffnung – in der Zukunft bessere Lösungen gefunden werden. Ein Dokument auf git.kernel.org bietet einen Überblick über den aktuellen Stand.
Neuerungen bei Dateisystemen
Der Re-Export von Dateisystemen über NFS (Network File System) wird mit der neuen Kernel-Version nun offiziell unterstützt. Somit können bereits gemountete NFS-Dateisysteme über den Kernel-NFS-Server an andere Systeme erneut freigegeben werden.
XFS führt ein neues Flag ein, das eine notwendige Reparatur des Dateisystems anzeigt. Ist das betreffende Bit gesetzt, ist es nicht möglich, das Dateisystem zu mounten, bis mittels xfs_repair eine Reparatur angestoßen wurde, im Zuge derer das Flag wieder zurückgesetzt wird. Durch diese Vorgehensweise soll vermieden werden, dass ein beschädigtes Dateisystem den Betrieb aufnehmen kann.
F2FS erhält einen neuen ioctl()-Call. Über diesen kann aus dem Userspace heraus gesteuert werden, welche Dateien komprimiert werden sollen. btrfs hat neue Mount-Optionen erhalten, die bei der Datenrettung auf einem defekten Dateisystem helfen sollen. rescue=ignorebadroots versucht, trotz eines defekten Root das Dateisystem zu mounten. resuce=ignoredatacsums schaltet das Prüfen von Checksummen aus. Zudem erfährt btfs einen Performance-Schub.
Grafik und Gaming
Nachdem die Windows-Treiber von Intel für Gen11-GPUs bereits 2019 um Integer-Mode-Scaling aufgestockt wurden, hält mit Kernel 5.11 diese Neuerung auch auf Linux-Systemen Einzug. Der DRM-Treiber für i915 unterstützt Integer-Scaling – ebenfalls nur für Gen11 / Ice Lake. Das Integer-Scaling sorgt für ein klareres Bild beim Upscaling von Games und anderer grafikorientierter Software. Insbesondere Pixel-Art-Content, wie er in Retro-Spielen und Video-Streams vorkommt, profitiert von der neuen Technik. XBMC/Kodi ist beispielsweise bereits für diese Technik vorbereitet.
Intel Gen9 und neuer erhält zudem nach langen Code-Review-Zyklen endlich das Async-Page-Flipping. Interessant ist dies für Games und andere Applikationen im Vollbild bei nativer Bildschirmauflösung: Deren Leistung lässt sich dadurch, dass das sonst notwendige Extra-Blit pro Frame vor dem Page-Flip eingespart werden kann, steigern.
Für die kommenden GPU-Generationen Green Sardine und Van Gogh von AMD bietet der neue Kernel rudimentäre Unterstützung. Außerdem fließt Support für Dimgrey Cavefish als zukünftigen neuen Vertreter im RX6000-Lager ein. Die aktuellen Radeon RX6800 und RX6900 (Sienna Cichlid) profitieren von Performance-Steigerungen.
NVIDIA GA100 und GeForce RTX "Ampere" unterstützt nun der Nouveau-Treiber fürs Kernel Mode Setting (KMS). Mit reinem KMS steht damit allerdings keine 3D-Beschleunigung, sondern lediglich das Setzen des Video-Modes zur Verfügung. Das genügt gerade, um das System soweit aufzusetzen, dass man sich von der NVIDIA-Seite den proprietären Treiber herunterladen und diesen installieren kann. Bleibt zu hoffen, dass in zukünftigen Kernel-Versionen der Nouveau-Treiber vollständigen Ampere-Support erhalten kann/wird.
Windows-Games
Durch Syscall User Dispatch (SUD) adressiert Linux 5.11 moderne Windows-Spiele, die unter Wine beziehungsweise Proton laufen. Bislang kommt Linux beim Ausführen moderner Spiele das Digital Rights Management (DRM) in die Quere. Viele Games umgehen die Windows-API zugunsten von direkten System-Calls, um so DRM und ähnliche Schutzmechanismen zu implementieren.
Würde Wine auf jeden möglichen Fall eines solchen direkten System-Calls mit einer emulierten Antwort reagieren wollen, würde das den Emulator bis zur Umbrauchbarkeit verlangsamen. Mit SUD leitet der Linux-Kernel die betreffenden System-Calls effizient um, sodass diese wieder im User-Space landen. Dort nimmt sie Wine in Empfang und bearbeitet sie entsprechend. Salopp gesprochen lässt sich Wine vom Linux-Kernel gezielt anstoßen, statt selbst alle Eventualitäten von direkten System-Calls durchzuprüfen.
Prozessor-News
Bislang waren die Treiber des Power Capping Framework (PowerCap), mit dem sich die Energieaufnahme der Chips überwachen und steuern lässt, auf Intel beschränkt. Die dahinter stehende Technik ist das "Running Average Power Limit" (RAPL) von Intel. Mit Linux 5.11 halten Patches für AMD ab Zen 1 Einzug. Ryzen- und Epyc-Systeme können mit dem neuen Kernel von der bestehenden PowerCap-Codebasis profitieren. Darüber hinaus unterstützt der AMD Energy-Treiber nun auch Zen 3. Zuvor waren lediglich Zen 1 und Zen 2 berücksichtigt worden.
Der neue Kernel unterstützt die Intel Platform Monitoring Technology (PMT). RISC-V verfügt nun über Unterstützung für den Continguous Memory Allocator (CMA) und Interrupt Time Accounting und sichert /dev/mem ab. Abschied nimmt der Kernel hingegen von Microblaze-Systemen ohne Memory Management Unit – die Entwickler nehmen an, dass solche Systeme kaum mehr im Einsatz sind.
Hardware-Support
Dell steuert Patches zum neuen Kernel bei, die das Konfigurieren von BIOS-Einstellungen direkt aus Linux heraus ermöglichen. Über den Systems Management Driver over WMI für Dell-Systeme lassen sich BIOS-Attribute über eine neu geschaffene sysfs-Schnittstelle konfigurieren. Unterstützt werden laut Dell WMI-basierte Systemen ab Baujahr 2018. Das neue sysfs-Interface mag auch andere Hersteller bewegen, auf diesen Zug aufzupringen und ebenfalls das BIOS-Setup (teilweise) für Linux zu öffnen.
Linux 5.11 baut die Unterstützung für USB4 und Thunderbolt aus. Intel Maple Ridge als erster diskreter Thunderbolt-4-Controller wird nun unterstützt. Außerdem spendiert Linux für die kommende Intel-Core-Plattform Alder Lake den passenden Sound-Treiber.
Neues gibt es auch an der WiFi-Front: Intel bringt Treiber fürs 6-GHz-Band beziehungsweise Ultra High Band (UHB) ein. Intel zieht damit für seine AX210-Module im Bereich WiFi 6E nach. Qualcomm hatte bereits in Linux 5.9 seinen Ath11k-Treiber für 6 GHz fit gemacht. Vom Haupt- in den Staging-Zweig wurde hingegen WiMAX (Worldwide Interoperability for Microwave Access) verschoben. Etwaige Benutzer, von denen es nach momentaner Einschätzung der Entwickler außerhalb der Bodenkommunikation auf Flughäfen (AeroMACS) nicht viele gibt, sollen mit dieser demonstrativen Geste dazu gebracht werden, ihr Interesse zu bekunden und dadurch zu verhindern, dass WiMAX gänzlich dem Rotstift zum Opfer fällt.
Itanium: Sterben auf Raten
Für etwas Wellengang in der Fachpresse sorgte schon vor der Veröffentlichung von Linux 5.11 ein einzelner Patch von Linus Torvalds: Es war die Rede davon, Linux würde ab 5.11 die IA64-Architektur nicht mehr unterstützen. Ganz so schlimm kommt es mit Linux 5.11 aber (noch) nicht: IA64-Support bleibt vorerst erhalten, aber das Zittern bleibt.
Wie der Kernel-Entwickler Adrian Glaubitz herausfand, verursachten einige Timer-Patches von Linus Torvalds eine Regression auf allen IA64-Systemen. Da die letzten verbliebenen IA64-Maintainer Tony Luck und Fenghua Yu von Intel nicht mehr am betreffenden Kernel-Code arbeiteten, bewog dieses Problem Torvalds schließlich dazu, IA64 auf "orphaned", also verwaist, zu setzen. Der IA64-Port von Linux hat damit aktuell keinen Maintainer mehr. Beim Build weist eine Warnmeldung auf diesen Umstand hin.
Es ist (fast) tot, Jim
Da sowohl Hewlett-Packard als auch Intel bereits keine Bestellungen mehr für Itanium-Chips akzeptieren, kommentiert Torvalds Itaniums Zukunft wenig optimistisch mit den aus Star Trek entlehnten Worten: "It's dead, Jim". Es ist unwahrscheinlich, dass HP oder Intel noch Maintainer für den IA64-Code abstellen werden: Die Architektur ist gescheitert.
Unter Windows endete der Support mit Windows Server 2008R2, also im Januar 2020. FreeBSD hat seinen Itanium-Port nach Version 10 eingemottet. Selbst NetBSD mit seiner breiten Hardware-Unterstützung hat es bislang nur auf eine halbfertige Portierung gebracht. Die Linux-Distributionen Red Hat, SUSE und Ubuntu haben bereits vor Jahren den Support für IA64 eingestellt. Das freie Debian hatte seine Bemühungen um IA64 offiziell mit "Jessie" zu Grabe getragen, obschon eine Gruppe von Enthusiasten weiterhin an einem inoffizellen Port arbeitet.
Aktuelle "Zugpferde" für Itanium-Systeme sind nur noch HP-UX und OpenVMS. Aber selbst diese lahmen inzwischen sehr. HP-UX erfährt in Version 11i v3 noch bis Ende 2025 Unterstützung. Danach ist die Zukunft schon allein angesichts der dann fehlenden Hardware-Plattform ungewiss. OpenVMS hingegen erfährt aktuell eine Portierung auf x86 durch die Firma VMS Software, inc (VSI). In einer Übergangszeit wird VSI Itanium noch unterstützen. Theoretisch könnte sich daher nach Linux 5.11 noch ein Entusiast von VSI oder ein unabhängiger Hobbyist – vielleicht aus dem Debian-Lager – als IA64-Kernel-Maintainer einfinden. Sehr wahrscheinlich ist das jedoch nicht.
Mit der "orphaned"-Kennzeichnung der IA64-Architektur in Linux 5.11 ist die Plattform allen anderslautenden Meldungen zum Trotz noch nicht tot. Sie darf aber als totgeweiht angesehen werden und der Umstieg auf eine andere Plattform ist ratsam.
Nachhall zu 5.10: Ein wegweisender Blogeintrag
Während der Release-Candidate-Phase zu 5.11 befasste sich die Community ungewöhnlich aktiv mit der Vorgängerversion Linux 5.10, die erwartungsgemäß zum Longterm-Support-Release (LTS) auserkoren worden war. Längere Debatten auf den Kernel-Mailing-Listen kreisten um die Frage, warum 5.10 nicht wie die meisten seiner LTS-Vorgänger von Anfang an eine Support-Spanne von sechs Jahren erhalte. Stattdessen soll 5.10 schon nach zwei Jahren, also im Dezember 2022, "end of life" gehen.
Der hierfür zuständige Kernel-Maintainer Greg Kroah-Hartman stellte daraufhin klar, dass er den angekündigten Zeitraum nur dann verlängern könne, wenn sichergestellt wäre, dass er ausreichend Hilfe beim Backporting von Features und beim Testen erhalte. Hierauf erreichten ihn unzählige Nachfragen aus der Community, wie diese helfen könne. Statt jede Mail einzeln zu beantworten, benannte Kroah-Hartman in einem Blogeintrag vom 3. Februar 2021 die grundsätzlichen Voraussetzungen, die erfüllt sein müssten, um die Support-Spanne eines LTS-Releases zu erweitern:
Blogeintrag Kroah-Hartman: "Helping Out With LTS Kernel Releases"
Für Kroah-Hartman sei wichtig, dass Nutzer die Release-Candidates auf ihren Systemen testen. Anschließend sollten sie ihm über die Announcement-Mailing-Liste (oder alternativ via E-Mail) Rückmeldung zu den Testresultaten geben. Optional könne in jede Rückmeldung auch eine Zeile der Form "Tested by: ..." aufgenommen werden. Diesen Hinweis würde Kroah-Hartman schließlich in den Commit des Dot-Releases integrieren. Examplarisch stellte Kroah-Hartman einige gute Rückmeldungen von Nutzern auf seinem Blog bereit, an denen man sich orientieren könne. Zudem würde er sich freuen, wenn er gezielt von Nutzern per privater Mail oder (bevorzugt) über die Mailing-Liste auf Features hingewiesen würde, die aus ihrer Sicht als Backport in ein LTS-Release einfließen sollten.
Nur wenn kontinuierlich Rückmeldung über Tests und Backports gegeben werde, sei ersichtlich, dass ein Kernel noch genutzt würde. Das allein sei das Kriterium, um ein LTS-Release auf sechs Jahre zu bringen. Für 5.10 lägen indes noch nicht genügend Rückmeldungen vor, die eine sechsjährige Support-Phase rechtfertigen würden.
Quelle: Linux 5.11: Support für Intel SGX, neue Treiber und kleinere Verbesserungen | heise online