Re:Avoid speculative indirect calls in kernel
by mikeash on Wednesday January 03, 2018 @09:10PM
(#16067429)
That has to be crazy slow. They probably haven’t published benchmarks yet because they’re still waiting for it to finish running!
Re:Avoid speculative indirect calls in kernel
by rst on Wednesday January 03, 2018 @09:35PM
(#16067531)
Interacting terribly with CPU branch prediction is the whole point -- Spectre attacks work by messing with the branch predictor, to misdirect speculative execution onto paths that reveal information useful to the attacker. So, the point of this whole crazy dance is to effectively disable the branch predictor.
Re:Avoid speculative indirect calls in kernel
by revelation on Wednesday January 03, 2018 @09:39PM
(#16067552)
Of course. But it needs spelling out, because branch prediction is essential to good performance and why todays CPUs can be much faster despite not reaching higher clocks.
It's much more than just the cost of a few more instructions.
Re:Avoid speculative indirect calls in kernel
by mike_hearn on Thursday January 04, 2018 @09:16AM
(#16070425)
Apparently the perf impact isn't so bad outside of microbenchmarks actually. 10% for real world programs ... as long as you use profile guided optimisation to devirt as many calls as possible!
https://support.google.com/faqs/answer/7625886
http://webcache.googleusercontent.com/search?q=cache%3Ahttps...
(some websites with info on this are DoSd and down right now, including the Arm website and LLVM code review site so switched to a cache link)
Pretty painful for C++ but fixable with build changes. JVM users and other JIT-compiled languages will probably be fixable without any serious impact, as HotSpot and other advanced runtimes devirtualise calls (convert indirect to direct) as much as they can anyway, meaning most calls won't be indirect when finished and once the code has warmed up.
Re:Avoid speculative indirect calls in kernel
by smitherfield on Friday January 05, 2018 @06:28PM
(#16082698)
The above example compiled with optimizations and with `indirect_jump` altered so the compiler actually emits a jump table instead of an array lookup:
https://godbolt.org/g/LPycpY
Every single call rax and jump rax that you see on the right will be replaced with the following:
And indirect_thunk does an lfence and a call to another function that gets rax from the stack and jumps there in a very roundabout way that interacts terribly with CPU prediction. I can see why they somehow didn't get around to benchmarking this yet, because they are not going to like the results. And it doesn't end with the kernel. Every JIT is going to need the treatment.