Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLVM patch to fix half of Spectre attack

reviews.llvm.org

Post reply on HN
Print view View original

41–50 of 248 posts

Re: LLVM patch to fix half of Spectre attack

#41

Post by ant6n »

jerf wrote: post #32
dzdt wrote: post #25

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.

That's bad. A single 5% hit might not be the end of the world, but 5% here and 10% there and another 5% over there in the common case adds up badly enough. Doubly-pathological cases (indirect calling-heavy code calling lots of syscalls)... a 50% slowdown and a 30% slowdown combines to a 60% total slowdown. Yeowch. Will be intrigued to see how processor manufacturers respond to this. If they were even slightly relaxed…

Sounds like it could be great for processor manufacturers. In the age where CPUs don't get faster, there's finally a reason for customers to buy new CPUs again!

Re: LLVM patch to fix half of Spectre attack

#42

Post by tptacek »

rayiner wrote: post #36
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…

Is glorious the right word for it? We’re going back to the stone ages where processors couldn’t predict the targets of indirect jumps. More generally, this seems to me like an attempt to patch out of what is really a class of attacks leveraging fundamental assumptions about high-performance CPU design. Before, OOO just had to preserve correctness and (some of) the order of exceptions and memory operations. Now, it ha…

We have different utility functions, you and I.

Re: LLVM patch to fix half of Spectre attack

#43

Post by mayoralito »

hultner wrote: post #6
okneil wrote: post #2

The site is down for me. HN hug of death?

It was a bit slow but eventually loaded for me.

Yeah, same thing happened to me... slow as hell but I guess it's common due the severity of the issue. All people wants to see this at the same time.

Re: LLVM patch to fix half of Spectre attack

#44

Post by tptacek »

JdeBP wrote: post #33
ealexhudson wrote: post #3

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

And once one knows the technical background, one is better positioned to consider the response of Linus Torvalds to the idea that the entire Linux kernel be recompiled for all x86 CPUs with a compiler that implements this. * https://lkml.org/lkml/2018/1/3/797 ( https://news.ycombinator.com/item?id=16066968 )

This would be more interesting if the attack that the compiler mitigations was designed for wasn't cross-vendor, cross-architecture.

Re: LLVM patch to fix half of Spectre attack

#45

Post by tcoppi »

rayiner wrote: post #36
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…

Is glorious the right word for it? We’re going back to the stone ages where processors couldn’t predict the targets of indirect jumps. More generally, this seems to me like an attempt to patch out of what is really a class of attacks leveraging fundamental assumptions about high-performance CPU design. Before, OOO just had to preserve correctness and (some of) the order of exceptions and memory operations. Now, it ha…

Seems like the ultimate end-game here is to have mini-vms for every process using CPU-level ring protection. If you can't speculate across privilege levels, only inside them, it isn't a security problem anymore.

Re: LLVM patch to fix half of Spectre attack

#46

Post by scatters »

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…

This doesn't affect branches, only indirect jumps (and calls). The performance impact will still be considerable. It will make PGO more crucial (or smarter JITting, for VM languages) since the penalty can be avoided by prefixing an indirect call with a direct call to the most likely target - this is a well-known technique, useful on machines with weaker jump predictors than branch predictors.

Quite possibly, the worst affected code will be OO code that is dynamically (open) polymorphic.

Re: LLVM patch to fix half of Spectre attack

#47

Post by Klathmon »

vfaronov wrote: post #31

I have a hunch that the era of side-channel attacks is only now dawning, and that we should expect many more painful exploits and cumbersome mitigations in the coming years. What do people more knowledgeable in the field think about this?

I'm not more knowledgeable than you, but I think I agree.

side channels have always been some of the most insidious exploits. Many are basically un-solvable (timing attacks are always going to leak some information, and compression is basically completely at odds with secure information storage), many more are easily enough overlooked that it would be easy to maliciously include them without raising any eyebrows, and the "fixes" for them almost always murder performance.

I think the only real fully-encompassing solution to this is a redesign in how we use computers. Either a massive step backwards on performance and turning off most automatic "optimizations" until they can be proven through a much more rigorous process (both in compilers, and in hardware), or a significant change in how computers are architected adding more hardware level isolation for processes and systems running on the machine (just daydreaming now, but something like a cluster of isolated micro-CPUs that run one application only).

Re: LLVM patch to fix half of Spectre attack

#48

Post by bouk »

rayiner wrote: post #36
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…

Is glorious the right word for it? We’re going back to the stone ages where processors couldn’t predict the targets of indirect jumps. More generally, this seems to me like an attempt to patch out of what is really a class of attacks leveraging fundamental assumptions about high-performance CPU design. Before, OOO just had to preserve correctness and (some of) the order of exceptions and memory operations. Now, it ha…

tptacek exploits computers for a living, so it's glorious for him :)

Re: LLVM patch to fix half of Spectre attack

#49

Post by contrarian_ »

scatters wrote: post #46
littlestymaar wrote: post #18

Earlier quoted context omitted.

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

This doesn't affect branches, only indirect jumps (and calls). The performance impact will still be considerable. It will make PGO more crucial (or smarter JITting, for VM languages) since the penalty can be avoided by prefixing an indirect call with a direct call to the most likely target - this is a well-known technique, useful on machines with weaker jump predictors than branch predictors. Quite possibly, the wors…

FWIW, all branches will need to be followed by a memory load fence which seems to trip up speculative execution on Intel CPUs.
Post reply on HN