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

61–70 of 248 posts

Re: LLVM patch to fix half of Spectre attack

#61

Post by [deleted] »

tptacek wrote: post #42
rayiner wrote: post #36

Earlier quoted context omitted.

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.

[deleted]

Re: LLVM patch to fix half of Spectre attack

#63

Post by pdpi »

voidmain wrote: post #27
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 th…

ARM’s white paper details a variant 3a that affects some of their cores that are unaffected by var3 (and vice versa)

Re: LLVM patch to fix half of Spectre attack

#64

Post by jacquesm »

JDevlieghere wrote: post #19
jacquesm wrote: post #9

Earlier quoted context omitted.

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.

Ah right, of course. Sorry, in the midst of doing a pile of stuff I should not be commenting on this without studying it further, I figured that the first level read access would allow you to dig up the secrets required to give you write access which would then allow you the free run of the whole system, but if you are still on the other side of a virtual machine then that won't do any good unless that virtual machine can be escaped as well.

Re: LLVM patch to fix half of Spectre attack

#65

Post by CmdDot »

mike_hearn wrote: post #56
CmdDot wrote: post #54

Earlier quoted context omitted.

Not really, once a program is compiled with -retpoline, new hardware won't bring back reliable branch prediction. I'd hope maybe, just maybe, this would be enough to put a focus on compilers producing code that ends up using processor-optimized paths chosen at runtime, to avoid "overheads ranging from 10% to 50%". Though, in this case, that would essentially mean making the entire executable region writable for some…

Not quite - lots of "serious" applications these days are written to target JIT compilers, which would be capable of switching retpoline on and off depending on need.

Funnily enough, I ended up not including a PS starting with "A sufficiently smart JIT, however..." ;)

Re: LLVM patch to fix half of Spectre attack

#66

Post by Tuna-Fish »

phkahler wrote: post #28

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.

The details that this attack depends on are outside the architecture of the system, in the microarchitecture. A cpu of almost any architecture can be vulnerable or not depending on how it was implemented, thus Ryzen is immune to the worst variant while both Intel and the fastest Arm cpus are vulnerable.

I'd presume that the slowest RISC-V designs are immune due to not speculating enough, while any high-performance implementation is vulnerable.

Re: LLVM patch to fix half of Spectre attack

#67

Post by pjc50 »

xigency wrote: post #51
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?

What about users who only execute trusted code? All of these attacks assume you are running something you don't trust on your CPU, whether it is another user's program, a non-root executable, or a JavaScript program from a website. When do we stop hacking processors, kernels, and compilers and revisit our assumptions of what we can and can't do securely.

Define "trusted"? Who do you trust to do your verification, and how much does it cost?

Re: LLVM patch to fix half of Spectre attack

#68

Post by geertj »

voidmain wrote: post #27
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 th…

> d I fear there's little reason to think that the "three variants" from project zero's announcement are the full scope of the problem.

Agreed. This is an entirely new class of vulnerabilities, and we're just at the beginning.

Re: LLVM patch to fix half of Spectre attack

#69

Post by ars »

phkahler wrote: post #28

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.

As of right now every single CPU that does speculative execution. (I.e. runs both sides of a branch then throws away the one that didn't end up being valid.)

Re: LLVM patch to fix half of Spectre attack

#70

Post by wyager »

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…

> leveraging fundamental assumptions about high-performance CPU design.

I believe the generalized fix is to restore the entire CPU state after a mispredict. You’d either need to add an extra copy of the entire processor state (tens of megabits) for every simultaneous predict you support ($$$) or keep track of how to revert all changes and revert them one at a time ($, slow).

Post reply on HN