AMD gibt Programmierleitfaden gegen Spectre heraus

Gestern hat Leser skelletor im Forum ein neues Whitepaper von AMD entdeckt, welches Programmierern und Compilerentwicklern einige Techniken an die Hand geben soll, wie die Angriffsszenarien Spectre 1 und 2 auf AMD-Prozessoren erschwert werden können. Von Meltdown ist AMD aufgrund der Architektur-Unterschiede zu Intel bekanntlich nicht betroffen. Bei Spectre jedoch ist auch bei AMD-Prozessoren zumindest die Möglichkeit gegeben, die Lücke auszunutzen, auch wenn AMD sie im Falle von Variante 2 mit „nahe Null” angibt.

Wer einen Blick in den Leitfaden wirft, findet eine ganze Palette an Vorschlägen. So sollen z.B. Register geleert werden sobald sie nicht mehr benötigt werden, der Befehl LFENCE soll genutzt werden, um Ladeoperationen seriell durchzuführen und es wird anhand eines Beispiels gezeigt, wie Retpoline, Googles Vorschlag zur Milderung von Spectre 2, in der Programmierpraxis umgesetzt werden kann; im Whitepaper V2-1 genannt.

Der Vorteil von Retpoline wäre, dass die AMD-Prozessoren – im Gegensatz zu Intel – ohne weitere Microcode-Updates auskämen. Es müssten also weder BIOS-Updates gegen Spectre 2 geschnürt und verteilt, noch Microcode-Updates in Linux Repositorys ausgerollt werden. Es zeichnet sich ab, dass Retpoline der bevorzugte Weg in der Linux-Welt werden wird, während sich Microsoft in seinen bisherigen Windows-Updates auf eine andere Variante konzentriert, im Whitepaper V2-4 genannt. Diese setzt neue CPU-Befehle voraus – Indirect Branch Restricted Speculation (IBRS), Single Thread Indirect Branch Predictors (STIBP) und Indirect Branch Predictor Barrier (IBPB) – ist damit nur mittels Microcode-Update und/oder neuer CPUs machbar und kostet je nach CPU-Generation mal mehr mal weniger an Leistung.

Aus diesem Grund spricht sich AMD im Fazit deutlich für Retpoline als Lösungsweg gegen Spectre 2 aus, schließlich käme man dann ohne weitere Microcode-Updates aus:

AMD is aligned with the x86 community that V1-1 (lfence) is the preferred variant 1 software solution and that the V2-1 (retpoline) is the preferred variant 2 software solution. AMD continues to evaluate opportunities for new mitigations in both the x86 ISA and micro-architecture for future AMD processors.

Ob Microsoft jedoch noch einmal umschwenken wird, darf zumindest bezweifelt werden. Sollte Intel jedoch seine Microcode-Updates nicht zeitnah hinkriegen – der erste Versuch musste nach Instabilitäten bereits wieder zurückgezogen werden – wäre Microsoft womöglich gezwungen dazu. Insbesondere Linux-Chefstratege Linus Torvalds hat sich kürzlich deutlich („The patches are COMPLETE AND UTTER GARBAGE”) zu den bisher abgelieferten Patches geäußert.

Von Kernelentwickler Ingo Molnár existiert mittlerweile noch ein weiterer Vorschlag, der derzeit untersucht wird, eine Ergänzung, um Retpoline auch auf anscheinend besonders gefährdeten*) Intel-Skylake-CPUs nutzbar zu machen. Dieser käme ohne Microcode-Updates aus und würde auf einen bereits in den meisten Kernels enthaltenen CONFIG_FUNCTION_TRACER fußen:

Note the huge number of advantages:

- All distro kernels already enable the mcount based patching options, so there’s literally zero overhead to anything except SkyLake.

- It is fully kernel patching based and can be activated on Skylake only

- It doesn’t require any microcode updates, so it will work on all existing CPUs with no firmware or microcode modificatons

- It doesn’t require any compiler updates

- SkyLake performance is very likely to be much less fragile than relying on a hastily deployed microcode hack

- The „SkyLake stack depth tracer” can be tested on other CPUs as well in debug builds, broadening the testing base

- The tracer is very obviously simple and reviewable, and we can forget about it in the far future.

- It’s much more backportable to older kernels: should there be a new class of exploits then this machinery could be updated to cover that too - while upgrades to newer kernels would give the higher performant solution.

Der Lösungsweg wird derzeit noch evaluiert und ist bisher noch nicht implementiert worden.

*) David Woodhouse: „Then there’s Skylake, and that generation of CPU cores. For complicated reasons they actually end up being vulnerable not just on indirect branches, but also on a ‚ret’ in some circumstances (such as 16+ CALLs in a deep chain).”