LLVM patch to fix half of Spectre attack • Hacker News Board

Re: LLVM patch to fix half of Spectre attack

#21

Post by nothrabannosir » Thu, Jan 04, 2018, 2:50 PM UTC

littlestymaar wrote: post #18

revelation wrote: post #13

Earlier 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…

I don’t think this is about all branch prediction—just about branch jump prediction. Like, “jump to %rax, but don’t try to guess what %rax is before you’re 100% certain.” Not the same as “jump to a known location if you think this here register is true/false”. As far as I can piece together, the exploit relies on making the branch predictor think the branch target will be somewhere you stored malicious code , which will then be executed by another process, e.g. a kernel. If it does harm before the branch predictor catches that it was wrong, you’re home free.

I’m not sure, but that’s what it looks like, so far.

Re: LLVM patch to fix half of Spectre attack

#22

Post by kough » Thu, Jan 04, 2018, 2:52 PM UTC

ealexhudson wrote: post #3

This patch apparently implements this mitigation: https://support.google.com/faqs/answer/7625886

This is a really good writeup, thanks. I'm curious -- how often are google support faq articles deeply technical like this?

Re: LLVM patch to fix half of Spectre attack

#23

Post by [deleted] » Thu, Jan 04, 2018, 2:55 PM UTC

[deleted]

Re: LLVM patch to fix half of Spectre attack

#24

Post by jncraton » Thu, Jan 04, 2018, 2:55 PM UTC

tptacek wrote: post #17

Page 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 p…

Agreed. I haven't had this much fun thinking through the implications of a new exploit technique in a long time. It is truly beautiful.

Re: LLVM patch to fix half of Spectre attack

#25

Post by dzdt » Thu, Jan 04, 2018, 2:56 PM UTC

When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%.

Ouch! This is independent of other performance hurts, like from the kernel syscall overhead that was the hot topic yesterday. This is pretty crazy.

Re: LLVM patch to fix half of Spectre attack

#26

Post by blattimwind » Thu, Jan 04, 2018, 2:57 PM UTC

littlestymaar wrote: post #18

revelation wrote: post #13

Earlier 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 are two paragraphs dedicated to performance impact in the linked PR.

Re: LLVM patch to fix half of Spectre attack

#27

Post by voidmain » Thu, Jan 04, 2018, 2:58 PM UTC

tptacek wrote: post #17

Page 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 p…

And I fear there's little reason to think that the "three variants" from project zero's announcement are the full scope of the problem. They were just the variants that the few people in on this found time to develop exploits for. There can now be security bugs in things your program doesn't do; it seems like there is room for nearly unlimited creativity in finding them.

From the spectre paper:

"A minor variant of this could be to instead use an out-of-bounds read to a function pointer to gain control of execution in the mis-speculated path. We did not investigate this variant further."

Re: LLVM patch to fix half of Spectre attack

#28

Post by phkahler » Thu, Jan 04, 2018, 2:59 PM UTC

RISC-V impact? With all the reports of these attacks, I have not seen mention of risc-v. Since they are in the process of finalizing a lot of specs including memory model and privileged instructions, I wonder if there will be last minute changes to mitigate these vulnerabilities.