Original-URL des Artikels: https://www.golem.de/news/ibrs-und-retpoline-linux-entwickler-diskutieren-weiter-ueber-spectre-paches-1801-132364.html    Veröffentlicht: 24.01.2018 17:45    Kurz-URL: https://glm.io/132364

IBRS und Retpoline

Linux-Entwickler diskutieren weiter über Spectre-Paches

Nach ausfälligen Kommentaren von Linux-Chefentwickler Linus Torvalds erklärt ein Amazon-Entwickler ausführlich den geplanten Verwendungszweck der verschiedenen Patches gegen den Spectre-Angriff. Einigkeit über das Vorgehen herrscht aber immer noch nicht.

Nachdem sich Linux-Erfinder und -Chefentwickler Linus Torvalds über die derzeit verfügbaren Patches gegen eine Variante des Spectre-Angriffs aufgeregt hat, erklärt der ehemalige Intel-Entwickler und nun bei Amazon angestellte Kernel-Hacker David Woodhouse, was die drei neuen Funktionen bewirken, die über Microcode-Updates bereitgestellt werden, und wo die Alternative Retpoline genutzt werden kann.

Mit den Microcode-Updates sei wohl niemand wirklich glücklich, stellt Woodhouse zunächst fest, sie seien aber für aktuelle Hardware die einzige Möglichkeit, da man hier lediglich nachträgliche Änderungen am Microcode vornehmen könne. Also sei man auf diese Möglichkeiten beschränkt.

Die Funktionen sind alle dazu gedacht, das Ausnutzen der Spectre-2-Lücke (Branch Target Injection, CVE-2017-5715) zu verhindern. Über diese lässt sich die CPU dazu bewegen, das Ziel einer indirekten Codeausführung zu verfälschen, um so Zugriff auf privilegierten Speicher zu erhalten.

Drei Microcode-Funktionen

Funktion Nummer eins nennt sich Indirect Branch Prediction Barrier (IBPB). Die Barriere soll im Zuge von Kontextwechseln verhindern, dass der Prozessor bereits bekannte Branch Targets verwendet. Die Funktion ist laut Woodhouse recht CPU-intensiv und benötigt rund 4.000 CPU-Zyklen.

Eine zweite Funktion trägt den Namen Single Thread Indirect Branch Predictors (STIBP). Sie hält Zwillingsthreads beim Hyperthreading davon ab, den Branch-Vorhersagen des anderen Zwillings zu folgen. Sinnvoll sei die Funktion, wenn unzusammenhängende Prozesse im Userspace laufen. Oder wenn verschiedene VM-Gäste beim Hyperthreading Zwillingsprozesse verwenden.

Die dritte Funktion ist etwas komplexer. Die Indirect Branch Restricted Speculation (IBRS) wird gesetzt, sobald die CPU in einen privilegierten Modus fällt. In diesem Fall sorgt der Code dafür, dass die CPU die in einem weniger privilegierten Modus erlernten Ziele für den Codezweig vergisst.

Speziell gegen IBRS richtete sich auch die Kritik von Linus Torvalds. Woodhouse räumt ein, dass IBRS bei jedem Eintritt in den Kernelspace gesetzt werden müsse, was es nicht nur teuer mache, sondern zugleich ein "mieser Hack" sei. Woodhouse hält ihn allerdings für alternativlos.

Da die CPU trotz IBRS nicht zwischen verschiedenen Userspace-Prozessen und Gast-VMs entscheiden könne, bräuchte man auch die IBP-Barriere für Kontextwechsel und Wechsel beim Beenden und Speichern einer Gast-VM (vmexit). Während die VMs laufen, benötige man zudem eventuell STIBP. Alles zusammen wirke sich recht negativ auf die Performance aus.

Retpoline für bessere Geschwindigkeit

Der Vorschlag von Google-Mitarbeiter Paul Turner, um die Performance-Situation zu verbessern, nennt sich Retpoline (Return Trampoline). Diese Lösung erlaubt es, indirekte Branches von der spekulativen Ausführung auszunehmen. Diese Technologie erfordert Änderungen am Compiler, verbessert aber die Performance deutlich. Laut Woodhouse kann man so größtenteils auf IBRS verzichten und lediglich Retpoline und die erstgenannte Funktion IBPB verwenden.

Eine Notwendigkeit für das Aktivieren von IBRS sieht er zumindest für VM-Gäste, die die Funktion auf Windows und RHEL nutzen. Ansonsten erhofft sich Woodhouse eine Diskussion der Frage, ob überhaupt und zu welchem Zeitpunkt man beim Kontextwechsel die IBPB aktivieren wolle und in welchen Fällen die STIBP im Userspace nötig seien.

Alternativer Vorschlag ohne Microcode

Laut Woodhouse benötigen Skylake und die verwandten Prozessoren-Generationen weiterhin IBRS. Wer IBRS aufgrund von Performance-Erwägungen auf Skylake abschalte, solle dies bewusst tun. Er wäre glücklicher darüber, wenn es eine kohärente Analyse gäbe, die zeigen könne, dass IBRS auf Skylake nicht nötig sei, so der Entwickler.

Tatsächlich gibt es nun von Kernelentwickler Ingo Molnár einen alternativen Vorschlag, um den teuren IBRS-Einsatz und die Änderungen im Compiler zu umgehen. Er schlägt vor, CONFIG_FUNCTION_TRACER=y zu verwenden, um einen schnellen Tracking-Tracer zu implementieren, der Retpoline aktiviert, sobald ein Stack mehr als etwa 16 Einträge summiert.

Dieser Schritt könne den Overhead auf Skylake-CPUs reduzieren, nutze zugleich in aktuellen Distro-Kerneln vorhandene Möglichkeiten und erzeuge auf anderen CPU-Generationen als Skylake keinen Overhead. Seine Lösung erfordere zudem keine Microcode-Updates und der Stack Depth Tracer lasse sich auch auf anderen CPUs testen.

Laut Molnár besteht also eine Chance, auf die Microcode-Hacks zu verzichten und die Probleme über reguläre Kernel-Updates und mit weniger Performance-Einbuße zu beheben. Ob diese Lösung in der Praxis funktionieren könnte, ist aber noch offen. Sie wirft zumindest Fragen auf, und die Kernel-Entwickler müssten sie intensiv testen. Für welche der Lösungen sich die Community also langfristig entscheidet, ist derzeit noch offen.  (kki)


Verwandte Artikel:
LLVM 6.0: Clang bekommt Maßnahme gegen Spectre-Angriff   
(09.03.2018, https://glm.io/133241 )
PTI und IBRS: FreeBSD erhält Patches gegen Meltdown und Spectre   
(19.02.2018, https://glm.io/132856 )
Spectre und Meltdown: CPU-Bugs sind laut Google schon seit Juni 2017 bekannt   
(04.01.2018, https://glm.io/131958 )
Google: Chromebooks bekommen "Linux-VMs" und "Terminal"   
(27.02.2018, https://glm.io/133030 )
Librem 5: Purism-Smartphone bekommt Smartcard für Verschlüsselung   
(09.03.2018, https://glm.io/133248 )

© 1997–2019 Golem.de, https://www.golem.de/