AMD Did NOT Disable Branch Prediction With A Zen Microcode Update

[finalzone]

There's this from Fedora, which i guess might be that same microcode update: https://bodhi.fedoraproject.org/upda...018-41af2a8d65

https://bodhi.fedoraproject.org/updates/FEDORA-2018-53f304b0d3

That fix solved an issue related to temporary lockup on AMD APU A10 while resuming from suspension.

[newwen]

I guess that disabling indirect branch prediction would have a significant impact with C++ or java virtual function calls, whatever function pointer or even switch statements if the compiler generates jump tables. I can’t believe that disabling it is the solution to variant 1 spectre vulnerability, as AMD states it will have negligible impact on performance.

[Naib]

Gentoo is advertising the fixes...

https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre#sys-kernel.2Fgentoo-sources

Also as to why it isn't disabled is covered here:

https://lkml.org/lkml/2018/1/5/383

https://lkml.org/lkml/2018/1/5/405

[pal666]

Excuse my ignorance on the subject, but why would disabling speculative branch execution cause less of a performance hit than disabling branch prediction?

btw, retpoline patches only disable speculative execution on indirect branches, which are minority of conditional jumps

[pal666]

Branch prediction, speculative execution and prefetching in general are all one big system. And it works all together to fight the limitation of memory latency!

even when all code is in cache, there is length of pipeline to fight

[newwen]

btw, retpoline patches only disable speculative execution on indirect branches, which are minority of conditional jumps

Whenever you have jump tables, function pointers and virtual function tables that must resolve in runtime you have indirect jumps.
Retpoline patches substitute these jumps with a hack, which is to store the jump address in the stack and use return calls to jump to it and to cache the return target in the branch predictor in a controlled way, as modern processors have a separate branch predictor for function returns. Speculatice execution is not disabled, but with the retpoline patch, indirect jumps redirect speculative execution to a controlled location, thus avoiding the branch target injection vulnerability from other processes. It's a clever hack that costs a few extra instructions for every indirect jump, but at least it keeps the CPU pipeline full, which would not happen if speculatice execution for indirect jumps were disabled.

I'd like to test the performance hit with C programs that use function pointers (GTK uses them a lot) and C++ programs that use virtual functions and polymorphism.

[pal666]

Whenever you have jump tables, function pointers and virtual function tables that must resolve in runtime you have indirect jumps.

which is much more rare than when you have conditions or loops

Retpoline patches substitute these jumps

i know

[duby229]

Branch prediction has to execute speculatively to be useful, as the performance gain is obtained by keeping the pipeline full.

Keeping the pipeline full is kinda hard. I'm sure you're fully aware of context switching and how that occurs. You should say it the other way around, speculative execution requires branch prediction. The point is speculative execution will kill performance from stalls caused by context switches flushing and filling the pipeline over and over and over again. That's kinda the point of branch prediction is to alleviate that scenario. The performance gain actually comes from avoiding context switches, which can but doesn't necessarily mean the pipeline will be more full.