Die Ankündigung von Spectre und Meltdown fand nicht nur ein weltweites Medienecho, auch Linux und diverse Open-Source-Projekte beschäftigen sich mit den Folgen, darunter Mozilla, Ubuntu und Red Hat.

Red Hat widmet sich dem Thema Performance und gibt Zahlen heraus, die es in Benchmarks mit RHEL 7 und vorherigen Versionen gewonnen hat. Generell betreffen die Performance-Einschränkungen vor allem Software, die viele Kontextwechsel zwischen User- und Kernelspace benötigt, was den Translation Lookaside Buffer (TLB) zu häufigeren Löschaktionen zwingt.

Einen “messbaren” Performance-Einbruch von 8 bis 19 Prozent sieht Red Hat beim Einsatz von Online-Transaktionsverarbeitungen (OLTP), die zum Beispiel bei ERP-Systemen zum Einsatz kommen und gepufferte Ein- und Ausgaben. Verschiedene Benchmarks wie Tpc, Sysbench, Pgbench, Netperf (bei weniger als 256 Byte) und Fio (bei zufälligem Lesen und Schreiben auf NvME) zeigen Ergebnisse, die in diese Kategorie gehören.

Einen moderaten Performance-Einbruch zeigen Systeme zur Datenbank-Analyse oder zur Unterstützung bei komplexen Entscheidungen, aber auch Java VMs. Die von den Einbußen betroffenen Anwendungen erzeugen signifikanten sequenziellen Festplatten- oder Netzwerk-Traffic, wobei die (Kernel)-Treiber die Anfragen in der Regel vor dem Ausführen bündeln.

Weniger betroffen (2 bis 5 Prozent) sind CPU-intensive High-Performance-Workloads im HPC, weil diese Jobs überwiegend im Userspace laufen und zudem CPU-Pinning oder Numa-Kontrollen verwenden. Zu den hier eingesetzten Benchmarks gehören Linpack NxN auf x86 sowie Spec-CPU-2006. Nur minimal treffen die Lücken schließlich Software, die versucht, den Kernel zu umgehen. So genannte Linux-Beschleuniger-Technologien, die vor allem in Netzwerk-Software zum Einsatz kommen, Red Hat nennt DPDK.

Pläne für Ubuntu

Auch für den gewöhnlichen Nutzer gibt es Neuigkeiten. So verriet Canonicals Dustin Kirkland, dass die OS-Hersteller mit den Lücken ursprünglich am 9. Januar an die Öffentlichkeit gehen wollten, um zu diesem Zeitpunkt zugleich die Fixes zu präsentieren. Das haben die Spekulationen im Vorfeld nun verhindert, Canonical hält für seine Ubuntu-Patches aber wahrscheinlich an diesem Datum fest.

Für 64-Bit-Architekturen sollen also am 9. Januar Kernel-Patches erscheinen, das für April geplante Ubuntu 18.04 LTS kommt mit Kernel 4.15, das die KPTI-Patches bereits an Bord hat. Die Softwareflicken reparieren auch Kernel, die unter anderem in den Public Clouds von Amazon, Google und Microsoft laufen. Live-Patching wird allerdings nicht möglich sein, die Cloud-Anbieter müssen ihre Systeme neu starten. Daneben erwarten die Ubuntu-Entwickler Updates für CPU-Microcode, GCC und Qemu.

Prozessor-Hersteller legen nach

Intel hat inzwischen auch mit mehr Details auf die gefunden Bugs reagiert und ein Whitepaper veröffentlicht. Das setzt sich mit den Schwachstellen auseinander und unterbreitet Vorschläge, wie diese sich womöglich beheben lassen. So soll das Process-Context-Identifier- Feature (PCID) die Performancekosten der TLB-Löschaktionen gehörig senken, was allerdings voraussetzt, dass der Prozessor das Feature unterstützt.

Auch ARM hat auf die Lücken reagiert und beschreibt tabellarisch für verschiedene Cortex-Prozessoren, welche der drei Lücken für diese jeweils relevant sind. Zudem hat der Hersteller noch Informationen für eine weitere Variante von Meltdown (3a) ergänzt. Tauchen bestimmte Kerne nicht in der Tabelle auf, betreffen die Probleme diese laut der Mitteilung auch nicht.

Kernel-Updates

Auch auf der Kernel-Mailingliste sind die Intel-Probleme und die vorgeschlagenen Lösungen ein Thema. Von Intels Andi Kleen kommt der Vorschlag, spekulative indirekte Calls über eine spezielle Codesequenz namens “retpoline” zu verhindern. Dazu braucht es allerdings eine neue Compiler-Option “-mindirect-branch=thunk-extern” für GCC, die Patches will Intel liefern. Mit dieser soll der Kernel dann neu kompiliert werden.

Auf wenig Gegenliebe stieß aber die im Code eingebaute Warnung, falls der Kernel nicht mit dem modifizierten GCC übersetzt wurde. Anstatt vor einem “Data Leak” im Kernel zu warnen, drängt Entwickler Thomas Gleixner darauf, das “CPU_BUG”-Bit zu setzen, schließlich verursache die Hardware das Problem, nicht der Kernel.

Auch Linus Torvalds zeigte sich wenig erfreut. Er frage sich, ob Intel das Problem tatsächlich lösen möchte und ob man künftig nicht mehr in die ARM-64-Richtung schauen solle. Er wirft Intel vor, keine Kernel-Config-Optionen für das Problem anzubieten, schließlich seien nicht “alle CPUs Müll”. Einige können durchaus auch ohne die Patches auskommen, etwa Intels Atom und Itanium CPUs. Gleixners Idee, die Option “CPU_BUG” zu verwenden, hält auch er für einen gangbaren, wenn auch steinigen Weg.

Mozilla-Updates

Auch Browser-Hersteller Mozilla beschäftigt die gefundene Klasse von Angriffen. Diese scheinen auch mit Browsern zu funktionieren, um private Informationen verschiedenen Ursprungs abzugreifen. Da diese Angriffe aber auf einem präzisen Timing basieren, habe Mozilla kurzfristig verschiedene Zeitquellen für Firefox entweder deaktiviert oder unpräziser gemacht. Dazu gehören “performance.now()” und implizite Quellen, um hochauflösende Timer zu entwickeln wie “SharedArrayBuffer”. Bis auf weiteres reduziert Mozilla die Auflösung von “performance.now()” auf 20 Mikrosekunden und deaktiviert “SharedArrayBuffer”.

Längerfristig will man das Leak allerdings entfernen und nicht nur verstecken, was allerdings Zeit brauche, um alle Probleme zu verstehen, Code zu implementieren und zu testen. Ist das erledigt, sollen auch die hochauflösenden Timer wieder wie zuvor funktionieren.

Die Cloud

Natürlich müssen auch die zahlreichen Anbieter von Clouddiensten, die Linux und Virtualisierung verwenden, ihre Kernel patchen. Sie alle aufzuzählen, würde den Rahmen sprengen, Admins und Entwickler werfen besser einen Blick auf die Strategie der von ihnen genutzten Anbieter, kalkulieren eventuelle Auszeiten für Updates mit ein und checken ihre Backups.

Mit den Fixes ist das Problem nämlich nicht aus der Welt geschafft. Vielmehr sind in Zukunft grundlegende Umbauten und Reparaturarbeiten am Linux-Kernel, aber auch an den Kernen anderer Systeme zu erwarten. Diese recht hektischen Aktivitäten ziehen mitunter Folgefehlern nach sich, womöglich entdecken die Entwickler dabei weitere Lücken, wie es das Statement von ARM bereits andeutet.

Update [5.1.]: Auch Suse hat eine Webseite zu den Lücken veröffentlicht und bietet seit dem 4.1. Updates für die jüngsten seiner Suse-Linux-Enterprise-Versionen. Auch für andere Versionen sollen Updates folgen, eine Support-Webseite hält Admins zudem auf dem neuesten Stand.