I remember doing tricks like this in 6502 assembly and in other early processors. Amazing that to stop these attacks you have to come up with clever tricks again. Back in the 80's I would have never imagined this type of attack being something to worry about.
LLVM patch to fix half of Spectre attack
11–20 of 248 posts
Re: LLVM patch to fix half of Spectre attack
#12retpoline seems to be a novel concept. Can anyone ELI5? Also, any insight about performance impact here?
By design, with retpoline indirect branches won't be able to take advantage of branch prediction. This is nontrivial, but can't be helped. Performance impact should be negligible otherwise.
Re: LLVM patch to fix half of Spectre attack
#13retpoline seems to be a novel concept. Can anyone ELI5? Also, any insight about performance impact here?
retpoline is just a convoluted way of doing an indirect jump/call designed to make branch prediction entirely useless. It's a novel concept because doing this is completely opposite to making a program run faster.
Here is an example of the most common programming patterns that end up causing indirect jumps/calls:
Imagine every virtual function call in a C++ program being mispredicted and taking twice as long.
(Instead of forcing us to recompile the world, maybe Intel should just disable branch prediction in microcode.)
Re: LLVM patch to fix half of Spectre attack
#14The site is down for me. HN hug of death?
Yes. Give it about 5 minutes. It will load without images.
Re: LLVM patch to fix half of Spectre attack
#15I remember doing tricks like this in 6502 assembly and in other early processors. Amazing that to stop these attacks you have to come up with clever tricks again. Back in the 80's I would have never imagined this type of attack being something to worry about.
>early processors
Early processors had speculative execution? I thought this had been added to Intel/AMD/ARM about 20 years ago?
Re: LLVM patch to fix half of Spectre attack
#16I remember doing tricks like this in 6502 assembly and in other early processors. Amazing that to stop these attacks you have to come up with clever tricks again. Back in the 80's I would have never imagined this type of attack being something to worry about.
>early processors Early processors had speculative execution? I thought this had been added to Intel/AMD/ARM about 20 years ago?
I think it means they're tricks for better performance when you _don't_ have speculative execution.
Re: LLVM patch to fix half of Spectre attack
#17Page was down when I tried to read it, but it's archived here: http://archive.is/s831k.
Its hard to get your head around how big a deal this is. This vulnerability is so bad they killed x86 indirect jump instructions. It's so bad compilers --- all of them --- have to know about this bug, and use an incantation that hacks ret like an exploit developer would. It's so bad that to restore the original performance of a predictable indirect jump you might have to change the way you write high-level language code.
It's glorious.
Re: LLVM patch to fix half of Spectre attack
#18retpoline seems to be a novel concept. Can anyone ELI5? Also, any insight about performance impact here?
retpoline is just a convoluted way of doing an indirect jump/call designed to make branch prediction entirely useless. It's a novel concept because doing this is completely opposite to making a program run faster. Here is an example of the most common programming patterns that end up causing indirect jumps/calls: https://godbolt.org/g/eThmnG Imagine every virtual function call in a C++ program being mispredicted and…
> Imagine every virtual function call in a C++ program being mispredicted and taking twice as long.
> (Instead of forcing us to recompile the world, maybe Intel should just disable branch prediction in microcode.)
Wouldn't the performance impact be dramatic ? In this[1] example there's a 6 times slowdown between situation with and without correct branch prediction.
[1]: https://stackoverflow.com/questions/11227809/why-is-it-faste...
Re: LLVM patch to fix half of Spectre attack
#19It's noted in the patch that one would have to recompile linked libraries, which seems impractical, unless a distro decides to build everything with this flag.
Not just linked binaries, also the whole underlying OS, and, critically, the compiler itself. Otherwise you could replace the 'proofed' construct with one that is not proofed against the bug.
Why would you need to recompile the compiler? Both variants only provide read access.
Re: LLVM patch to fix half of Spectre attack
#20Earlier quoted context omitted.
retpoline is just a convoluted way of doing an indirect jump/call designed to make branch prediction entirely useless. It's a novel concept because doing this is completely opposite to making a program run faster. Here is an example of the most common programming patterns that end up causing indirect jumps/calls: https://godbolt.org/g/eThmnG Imagine every virtual function call in a C++ program being mispredicted and…
> Imagine every virtual function call in a C++ program being mispredicted and taking twice as long. > (Instead of forcing us to recompile the world, maybe Intel should just disable branch prediction in microcode.) Wouldn't the performance impact be dramatic ? In this[1] example there's a 6 times slowdown between situation with and without correct branch prediction. [1]: https://stackoverflow.com/questions/11227809/wh…
There is still branch prediction for normal calls or jumps, which are the majority and should be in performance conscious code.
It's just that some language features such as virtual functions in C++ often require indirect invocation when the compiler can't devirtualize a call, and there is lots of it in the kernel in performance-critical paths (think interrupts, syscalls).