Seite 3: Maßnahmen gegen Meltdown und Spectre

Inhaltsverzeichnis

Meltdown-Schutz

Gegen die Prozessor-Sicherheitslücke Meltdown konnte man sich bereits schützen, als die Lücke am späten Abend des 3. Januar bekannt wurde. Das war der eigens entwickelten Page Table Isolation (PTI) zu verdanken, die manchmal auch Kernel PTI (KPTI) genannt wird. Mit ihrer Hilfe blendet der Kernel im Adressraum von Prozessen nicht mehr seinen ganzen Speicher ein; vielmehr findet sich dort nur noch ein kleiner Teil davon, der zur Interaktion zwischen Programmen und Kernel unerlässlich ist. Dadurch steigt der Overhead allerdings deutlich, wenn Programme für irgendwelche Aufgaben den Kernel zur Hilfe nehmen. Dieser muss dann zunächst seinen Speicher wieder einblenden, der durch das Versteckspiel auch noch aus den Caches geflogen ist.

Linus Torvalds hatte PTI am Tag vor Silvester in den Hauptentwicklungszweig integriert, aus dem kurz darauf die sechste Vorabversion von Linux 4.15 hervorging. Einige Vorarbeiten waren sogar schon in den Wochen davor eingeflossen, zahlreiche Fehlerkorrekturen folgten in den Wochen danach (1, 2, 3, 4, 5, 6, 7). Die Schutztechnik floss auch in Version 4.14.11 ein, die am 2. Januar erschien.

All das war äußerst ungewöhnlich: PTI ist eine tiefgreifende Änderung, wie sie Torvalds beim Vorbereiten neuer Versionen normalerweise nur in den ersten zwei Entwicklungswochen integriert. Solche großen Umbauten fließen eigentlich auch nie in Stable/Longterm-Kernel zurück – und schon gar nicht innerhalb von lediglich drei Tagen.

Durch diese Aktivitäten wurde rund um Neujahr in Linux-Kreisen schon deutlich, dass die Bekanntgabe einer größeren und schwerwiegenden Lücke kurz bevor stand. Indizien dafür hatte es schon früher gegeben, denn Kernel-Patches mit dem PTI-Vorläufer KAISER (Kernel Address Isolation to have Side-channels Efficiently Removed) hatten an der Meltdown-Entdeckung beteiligte Forscher der TU Graz bereits im Herbst veröffentlicht. Hugh Dickins hat diesen Ansatz dann mit anderen Entwicklern grundlegend überarbeitet, damit er auf mehr Systemen funktioniert und den Qualitätsansprüchen der Kernel-Entwickler genügt. Später entstand unter Federführung von Thomas Gleixner dann eine neue PTI-Implementierung, die den Ansatz von KAISER verwendet, mit dessen Code aber kaum noch etwas gemein hat. Diese floss in 4.15-rc6 und 4.14.11 ein. Dort kann sie den Overhead mithilfe der in neueren Intel-Prozessoren gebotenen "Process-Context Identifiers" (PCID) reduzieren, die der Kernel seit Linux 4.14 zu nutzen weiß.

Auch die am 5. Januar erschienenen Kernel-Versionen 4.9.75 und 4.4.140 enthalten PTI – allerdings nicht die jüngste Implementation, sondern die von Dickins vorangetriebene Variante. Diese haben auch viele Distributionen integriert, die nicht ohnehin schon 4.14 verwendeten. Mit dem älteren PTI erhielten die Kernel auch PCID-Unterstützung – allerdings nur eine rudimentäre. Bei diesen Kerneln kann PCID daher nicht so viel Overhead wett machen, wie es es 4.14.11 und 4.15-rc6 können; der Performance-Einbruch kann daher größer sein.

Besitzer von AMD-Prozessoren brauchen dennoch keinen Geschwindigkeitsverlust fürchten: Linux deaktiviert PTI seit 4.14.12 und 4.15-rc7 automatisch, wenn es Athlon, Epyc, Ryzen & Co. vorfindet, denn die sind von Meltdown alle nicht betroffen. Bei Intel-CPUs hängt der Performance-Einbruch von der Generation ab, zu der der Prozessor gehört: Linux nutzt PCID erst bei CPUs mit Haswell-Innenleben, das beispielsweise in den seit Mitte 2013 verkauften Core-i-4000er-Prozessoren steckt; ältere Prozessoren beherrschen diese Technik nicht oder nur in einer Weise, bei der eine Nutzung keine Vorteile brächte.

PTI funktioniert derzeit nur auf der 64-Bit-x86-Architektur. ARM64-Support soll bei 4.16 folgen. An Patches zur Unterstützung von PTI auf 32-Bit-x86-Systemen wird mittlerweile gearbeitet.

Gegenmaßnahmen für die zweite Spectre-Variante

Gegen Meltdown konnte man sich somit bereits schützen, als die Lücken bekannt wurden. Ein Schutz gegen die zweite der beiden Spectre-Varianten folgte erst am 15. Januar mit Linux 4.15-rc8 (1, 2); später folgten noch Korrekturen und Verbesserungen (u. a. 1).

Der Grund für die späteren Gegenmaßnahmen: Erst rund um das Bekanntwerden von Spectre erhielten die Kernentwickler von Linux konkrete Informationen zur Lücke und möglichen Schutzansätze. Erschwerend kam hinzu, dass Kernel-Entwickler verschiedener Firmen zwei unterschiedliche Techniken zum Spectre-Schutz einreichten.

Der von Intel eingereichte Schutz greift auf die neuen Prozessor-Flags IBRS, STIBP und IBPB zurück, die Microcode-Updates des Unternehmens nachrüsten. Auf diese greifen die Spectre-Gegenmaßnahmen zurück, die Windows und einige Enterprise-Linuxe integriert haben. Auf älteren Prozessoren soll er größeren Overhead haben, auf Skylake (Core i-6000) und neueren CPUs aber nur wenig.

Ein zweiter Ansatz kam von Spectre-Mitentdecker Google: Kernel-Patches für eine Software-Lösung namens "Return Trampoline" (Retpoline). Sie soll weniger Overhead aufweisen und funktioniert auch ohne neuen Microcode; für umfassenden Schutz erfordert sie jedoch angepasste Compiler, mit denen der Kernel und schützenswerte Anwendungen neu übersetzt werden müssen.

Die Kernentwickler von Linux mussten zunächst die Vor- und Nachteile der beiden Ansätze gegeneinander abwägen; einige dabei im Raum stehende Unklarheiten und Fehlinformationen erschwerten diese ohnehin hektische und leicht chaotische Zeit weiter. Zum Ende der zweiten Januarwoche integrierten die Entwickler dann ein überarbeitetes Retpoline. Das blockt einige der Schwachpunkte, die zur zweiten Spectre-Variante gehören. Ein umfassenderer Schutz erfordert aber ein Kompilieren mit einem Compiler mit Retpoline-Support; Patches, die den nachrüsten, zogen am 16. Januar in den Stable-Zweig der GNU Compiler Collection (GCC) 7 ein.

Der Retpoline-Schutz in 4.15-rc8 ist allerdings nur der Anfang der Gegenmaßnahmen. So folgt für manche Prozessoren vielleicht auch noch die Lösung, die auf den neuen Microcode von Intel zurückgreift. Teile dieses Ansatzes sind ohnehin zur Integration vorgesehen oder bereits enthalten: Sie sind für sicheres Virtualisieren wichtig, damit in mit Linux aufgesetzten VMs auch die neuen Microcode-Funktionen zur Verfügung stehen, die Windows und andere als Spectre-Schutz nutzen. Andere Teile der Microcode-Schutztechnik braucht der Kernel-eigene KVM-Hypervisor zum effizienten Schutz vor Spectre 2; ganz unabhängig davon nahmen die Entwickler auch noch einige Änderungen in Linux 4.15 ein, um die KVM-Virtualisierung besser abzusichern. Auch da steht aber noch mehr im Raum.

Wie bei PTI wird auch der Retpoline-Schutz in Stable- und Longterm-Kernel zurückportiert. Er ist in Linux 4.14.14 und 4.9.77 eingeflossen, die am 17. Januar erschienen sind. Im parallel veröffentlichten 4.4.112 ist er aber nicht enthalten.

Spectre-v1-Schutz in Vorbereitung

An Maßnahmen gegen die erste Spectre-Variante schrauben die Entwickler noch. Ähnlich wie Retpoline sind dazu Änderungen bei Kernel und Compilern nötig. Jene für den Kernel werden seit Anfang Januar diskutiert, fließen aber wahrscheinlich nicht mehr in Linux 4.15 ein. Ein Grund für die Trägheit sind Unstimmigkeiten an einigen Stellen. Außerdem ist das ganze aufwendig: Die Entwickler versuchen Codestellen im Kernel zu eliminieren, die gegen die Lücke anfällig sind. Dazu müssen sie den gesamten Kernel-Code nach kritischen Stellen absuchen und auch in Zukunft darauf achten, keine neuen Angriffspunkte einzubauen. Darüber hinaus schrauben die Linux-Entwickler am vom Userspace nutzbaren BPF-Interpreter des Kernels, damit auch darüber ausgeführte Programme keinen Unfug anstellen können.

Aktivieren und Diagnostizieren

Die neuen Schutzmaßnahmen muss man vor dem Kompilieren eines Kernel-Images über die Konfigurationsoptionen CONFIG_PAGE_TABLE_ISOLATION und CONFIG_RETPOLINE explizit einschalten.

Über einige unter /sys/devices/system/cpu/vulnerabilities/ zu findende Dateien kann man mit Linux 4.15 prüfen, welchen Lücken den eingesetzten Prozessor betreffen und wie der Kernel dagegen vorgeht. Genau wie die Beschreibung in den vorherigen Absätzen bezieht sich das aber nur auf den Linux-Kernel. Zum umfassenden Schutz gegen die beiden Spectre-Varianten sind darüber hinaus auch Änderungen und Neukompilieren potenziell anfälliger Userspace-Anwendungen nötig. Für Meltdown ist das unnötig, denn das fängt der Kernel komplett ab.

Die erwähnten Gegenmaßnahmen können sich alle auch auf die Performance auswirken. Wie sehr sich das bemerkbar macht, hängt stark vom Prozessor und der verwendeten Linux-Version ab. Zugleich hat aber auch die Anwendung einen großen Einfluss. Auf rechenlastige, die meiste Zeit im Userspace verbringende Programme zeigt sich meist kein Effekt; Wer Kryptogeld mit der CPU schürft, kann sich also beruhigt zurücklehnen.

Auch auf manche Servern – darunter jene hinter Kernel.org – sollen die Schutztechniken keine größeren Einbußen auslösen. Manche Server-Admins berichten hingegen von Performance-Einbrüchen von bis zu 50 Prozent. Das zeigt, wie sehr die Auswirkungen vom Prozessor, der eingesetzten Software und der Workload des Systems abhängen.

Wie stark der Einfluss der Schutztechniken im Kernel ist, können Admins mit dem Kernel-Boot-Parameter nopti und nospectre_v2 testen, denn die legen die Gegenmaßnahmen lahm. Bei einigen mit Meltdown und Spectre-Schutz versehenen Distributionskerneln funktionieren diese Parameter nicht, weil sie andere Lösungen oder älteren Code verwenden. Die nächsten Wochen dürften hier Vereinheitlichung bringen, nachdem die Kernel-Entwickler jetzt Maßnahmen gegen zwei der drei Lücken integriert haben.

Der Tanz zum Schutz vor Meltdown und Spectre ist damit keineswegs beendet; viele weitere Änderungen werden bereits diskutiert. Dabei geht es nicht nur um Feintuning und noch besseres Abdichten, sondern auch größere Optimierungen. So zirkulieren bereits Patches, um PTI bei vertrauenswürdigen Prozessen deaktivieren zu können und so bei ihnen Performance-Einbußen zu vermeiden.