Die Neuerungen Von Linux 4.18 Update

Der am 6. oder 13. August erwartete Linux-Kernel 4.18 bringt endlich Maßnahmen mit, um von Spectre betroffene 32-Bit-ARM-CPUs vor dem Ausnutzen der Prozessorlücke zu schützen. Probleme bei der Interaktion mit dem zuständigen Subsysteme-Betreuer sind der Grund, warum die vor Monaten von ARM entwickelten Gegenmaßnahmen erst jetzt im offiziellen Kernel auftauchen. Darüber hinaus gab es noch allerlei andere Änderungen rund um Sicherheit, denn die Kernel-Entwickler haben auch am Spectre-Schutz für AMD-Prozessoren gefeilt. Außerdem dürfen in Containern definierte Anwender jetzt eigenständig Dateisysteme mit FUSE mounten, wenn sie Root-Rechte im Container haben.

Monate nach den Korrekturen für 64-Bit-x86-Systeme schützt jetzt auch der für 32-Bit-ARM-Kerne zuständige Linux-Code vor der ersten (u. a. 1, 2) und zweiten (u. a. 1, 2, 3, 4) Variante der Prozessor-Sicherheitslücke Spectre, die zu Jahresbeginn publik wurde. So lange hätte es nicht dauern müssen, denn ein ARM-Mitarbeiter hatte bereits in den ersten Wochen des Jahres Patches mit Gegenmaßnahmen veröffentlicht. Einige Distributionen und Hersteller von Embedded-Linuxen haben solche Patches auch integriert. Der zuständigen Subsystembetreuer Russell King hat sie aber erst zurückgewiesen und eine Weile links liegen gelassen, bevor er sie schließlich grundlegend umgeschrieben und jetzt integriert hat. Bei Anwendern von Mainstream-Kerneln trudeln sie daher erst rund sieben Monate nach Bekanntwerden der Lücken ein.

>
(Bild: Google+-Profilfoto von Russell King )

Die Verzögerung ist offenbar eine Folge von Differenzen mit King. Der war bekanntermaßen lange als ständiger Contractor für ARM tätig und ist in der Maintainers-Datei in den Kernel-Quellen als einziger Betreuer des "ARM Port" verzeichnet – also dem Kerncode zur Unterstützung von 32-Bit-ARM-Prozessorkernen. Ende März, kurz vor der Fertigstellung von Linux 4.16, hat King den Pflegestatus allerdings von "Gewartet" (Maintained) auf "gelegentliche Korrekturen" (Odd Fixes) geändert. Im begleitenden Kommentar betonte King, ARM bezahle ihn seit Anfang des Jahres nicht mehr für die Arbeit am ARM-Port. Die Pflegearbeit habe für ihn nun eine niedrigere Priorität. Der Code bekomme keine kommerzielle Unterstützung und werde fortan durch Freiwillige betreut.

Das ist Kings Sichtweise und Außendarstellung, die dabei geholfen hat, dass ARM ihn zumindest zur Integration des Spectre-Schutzes nochmal als Contractor angeheuert hat. ARM hat den 32-Bit-ARM-Port im Linux-Kernel nämlich keineswegs aufgegeben: Neben den ersten Gegenmaßnahmen haben ARM-Mitarbeiter in den vergangenen Monaten auch noch zahlreiche andere Änderungen für dieses Subsystem eingereicht. Der Status "Maintained" wäre daher in der Maintainers-Datei normalerweise allemal adäquat. Aus Kernel-Kreisen war zu hören, mehrere Entwickler wären auch nicht abgeneigt, King zu unterstützen oder die Betreuung des ARM-Ports ganz zu übernehmen; einer der Kandidaten arbeitet sogar bei ARM. Die Entwickler scheinen aber den offenen Konflikt mit King zu scheuen, der die Betreuung offenbar nicht abgeben will (siehe u. a. 1, 2); er scheint auch nicht daran interessiert zu sein, ein Entwicklerteam zu bilden, dessen Mitglieder sich gemeinsam um den Code kümmern; solch ein Modell wird beim Kerncode für ARM64- und x86-Systeme erfolgreich praktiziert.

>
Beim Zusammenspiel zwischen King und anderen Entwicklern hakt es schon seit einer ganzen Weile häufiger. (Bild: LKML-Archiv bei lore.kernel.org )

Maintainer-Wechsel erfolgen normalerweise einvernehmlich, daher wird das Problem wohl bleiben, bis irgendwas passiert, das dafür sorgt, dass sich King rührt oder Torvalds einschreitet. Bis dahin bleibt abzuwarten, ob die Differenzen noch weitere Verzögerungen auslösen, wie es sie beim Spectre-Schutz gab. Ohnehin sind die Schwierigkeiten nicht wirklich neu, sondern nur auf einer neuen Stufe angelangt: Entwickler, die in ihrer Freizeit oder bei anderen Firmen am Kernel-Code für 32-Bit-ARM-Kerne arbeiten, haben schon häufiger offen oder hinter vorgehaltener Hand über Probleme mit King geklagt; in den Archiven der Entwicklermailinglisten finden sich allerlei Mails, die Schwierigkeiten bei der Zusammenarbeit mit King zeigen.

Auf die Unterstützung neuer SoCs und Plattformen mit 32-Bit-ARM-Kernen dürfte das Ganze indes keinen sonderlichen Einfluss haben: Den SoC-Support samt der Device Trees betreut das "ARM Sub-Architectures Team", dessen Aushängeschilder Arnd Bergmann (derzeit: Linaro) und Olof Johansson (Facebook) sind.

Der Kernel-Code für 64-Bit-ARM-Kerne ist deutlich weiter, denn der schützt jetzt auch vor der im Mai publik gewordenen Prozessorlücke Spectre v4 (1, 2, 3, 4, 5). Die dafür zuständigen Änderungen stammen von ARM, dessen Mitarbeiter den ARM64-Code selbst betreuen. ARM-Entwickler haben für 4.18 auch eine Optimierung für die 64-Bit-Virtualisierung mit KVM und zahlreiche andere für ARM64 wichtige Änderungen beigesteuert.

> Anzeige
>

Das Kernel-Log

Die Artikelserie "Die Neuerungen von Linux" beschreibt regelmäßig die Änderungen neuer Linux-Versionen:

Auch bei den Spectre-Gegenmaßnahmen für andere Architekturen gab es Finetuning. Einige der Patches verbessern etwa den Spectre-v4-Schutz bei AMD-Prozessoren (1, 2, 3, 4). Zudem wurden weitere Codestellen gegen Spectre v1 abgesichert.

Der 32-Bit-x86-Code von Linux bringt indes nach wie vor keine Gegenmaßnahmen für Meltdown mit. Dafür zuständige Patches wurden kürzlich erneut zur Begutachtung gestellt. Torvalds zeigte sich dabei offen für die Integration, beklagt aber, dass der Code nur wenig getestet werde, da die meisten Kernel-Entwickler mittlerweile 64-Bit-Linux einsetzen. Sofern sich bei Review und Tests keine größeren Probleme zeigen, dürfte der Schutz dann wohl in 4.19 einziehen.

In einem Container definierte Anwender dürften dort jetzt Dateisysteme per FUSE (Filesystem in Userspace) mounten, wenn sie im Container denn Root-Rechte haben und der Admin das erlaubt (1, 2, 3, 4). Prinzipiell bringt der Kernel jetzt sogar alles Wesentliche mit, damit Root-Anwender eines Containers auch Dateisysteme wie Btrfs, Ext4, FAT oder XFS einhängen könnten; solche werden nicht wie bei FUSE durch Userspace-Programme gehandhabt, sondern durch Kernelcode. Der aber ist vielfach nicht oder nur bedingt gegen mutwillig beschädigte Dateisystemstrukturen abgesichert. Das Einbinden solcher Dateisysteme bleibt daher untersagt. Ein Angreifer könnte sonst womöglich im Container ein Image mit gezielt manipulierten Dateisystemstrukturen per Loop-Mount einhängen, um den Kernel so aus dem Tritt zu bringen, dass der Bösewicht den Host übernehmen kann. Aufgrund ähnlicher Gefahren hängen manche Distributionen auch USB-Sticks nicht automatisch ein, schließlich könnte ein Angreifer auch dessen Dateisystemstrukturen gezielt manipuliert haben. Die Ext4-Entwickler nehmen dieser Tage aber mehr und mehr Änderungen vor, um die Gefahr zu reduzieren. Details zum Ganzen erläutert ein Artikel bei LWN.net.

Weitere Neuerungen rund um Sicherheit nennen die Kommentare in den wichtigsten Git-Merges der Subsysteme AppArmor, Audit, Integrity und Security. Unter den Neuerungen am Crypto-Subsystem war Support für den Kompressionsmechanismus Zstandard (zstd) (u. a. 1), den andere Subsysteme schon länger unterstützen. Neu ist auch eine Implementation der Verschlüsselungsalgorithmen AEGIS (u. a. 1, 2) und MORUS (u. a. 1, 2, 3). Darüber hinaus gab es noch einige Umbauten, um Overflow besser zu erkennen (1, 2).

Schrittweise aktualisierter Text zu Linux 4.18

Support für eine neue Generation von AMDs Vega-Grafikkernen und die Grafikhardware des Intel/AMD-Radeon-Kombiprozessors sind zwei Highlights von Linux 4.18. Die am 6. oder 13. August erwartete Kernel-Version bringt zudem Grundlagen für Bpfilter mit: einen neuen Mechanismus für das Filtern von Netzwerkpaketen, der nach dem Willen einiger Entwickler die Netfilter-Infrastruktur ersetzen soll, auf die Firewall-Lösungen wie Iptables und Nftables bislang zurückgreifen (siehe c't 13/2018, S. 88 und c't 15/2018, S. 34). Neu dabei sind auch Treiber für Valves Steam-Controller und Support für ein Qualcomm-SoC mit ARM-Innenleben, das für Notebooks gedacht ist.

Diese und weitere Neuerungen von Linux 4.18 sind seit dem 17. Juni absehbar, als Linus Torvalds die erste Vorabversion dieser Kernel-Version freigegeben hat. Damit hat er die "Merge Window" genannte Phase des Entwicklungszyklus abgeschlossen, in der er alle wesentlichen Umbauten für eine neue Kernel-Version vornimmt. Größere, erwähnenswerte Änderungen erfolgen danach nur in Ausnahmefällen; es passiert auch nur äußerst selten, dass die Entwickler eine umfangreichere, im Merge Window integrierte Änderung vor der Fertigstellung deaktivieren oder gar entfernen.

Das Kernel-Log der c't kann daher bereits jetzt die Neuerungen der nächsten Linux-Version in einem detaillierten Text beschreiben. Er wird zwischen Erstpublikation und der Fertigstellung des neuen Kernels mehrfach erweitert, um die wesentlichen Änderungen der verschiedenen Kernel-Bereiche schrittweise in leichter handhabbaren Mengen zu beschreiben. Aus diesem Grund wird das Kernel-Log den Bpfilter auch unabhängig von den anderen Änderungen im Netzwerkbereich erläutern.

Der Newsticker von heise online erwähnt größere Erweiterungen des Textes zum neuen Linux-Kernel, die Sie immer auf der ersten Artikelseite finden. Ältere Textpassagen stehen auf den folgenden Seiten. Details zur Versionshistorie des Artikels liefert das Changelog am Artikelende.

Source :>https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-18-4078605.html<

Die Neuerungen von Linux 4.18 Update
Ubuntus neuer Server-Installer sucht Tester
Netfilter: Iptables 1.8 bringt bessere Werkzeuge für Nftables-Backend
Bios und Uefi: Die wichtigsten Funktionen enträtselt
Plasma 5.13 aktualisiert
Arco Linux 6.9.2 mit neuen Startmedien
Monitoring-Software Icinga 2 erhält Update
Windows 10: Notepad mit erstem großen Feature-Update seit Jahren
Linux Mint 19 freigegeben: Modifiziertes Ubuntu 18.04 mit Snapshot-Funktion
Panorama Update erscheint noch diesen Monat