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.

Artikel veröffentlicht am 24. Januar 2018, 17:45 Uhr, Kristian Kißling/Linux Magazin

Wie weiter mit den Spectre-Pachtes? Die Kernel-Community ist sich da noch uneins. (Bild: Liam Quinn, flickr.com/CC-BY-SA 2.0)

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.

Inhalt:

1. IBRS und Retpoline: Linux-Entwickler diskutieren weiter über Spectre-Paches
2. Retpoline für bessere Geschwindigkeit

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.