Seite 7: Sicherheit: Endlich Spectre-Schutz für ARM

Inhaltsverzeichnis

Spectre v1 & v2: Endlich Schutz für 32-Bit-ARM

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 Prozessorsicherheitslü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.

Schwierigkeiten rund um die Betreuung des 32-Bit-ARM-Codes

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.

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.

Noch mehr Arbeit an Spectre-Gegenmaßnahmen

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.

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.

Mounten in Containern, neue Verschlüsselungsalgorithmen

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).