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

71–80 of 248 posts

Re: LLVM patch to fix half of Spectre attack

#71

Post by bem94 »

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 problem (in my understanding) is not with the specification of the x86 ISA, but with the implementation of the speculative execution micro-architecture and probably the memory sub-system as well. That is why Intel is so badly affected by the problem, but not AMD, despite them both implementing the same instruction set.

RISCV has already had to fix its memory consistency model, so it is not without problems. But it that is a spec bug, not an implementation bug. Whether there is an out of order, speculative execution RISCV core in the wild which suffers from this is as far as I know very unlikely. If there is, no doubt it's designers have had a busy time lately.

Re: LLVM patch to fix half of Spectre attack

#72

Post by Keyframe »

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.

RISC-V is an ISA, so it depends on the implementation.

Re: LLVM patch to fix half of Spectre attack

#73

Post by tzahola »

js2 wrote: post #52
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…

CPUs have been vulnerable to this attack since 1995. How did it collectively take us 22 years to figure this out? I know it's a highly esoteric complex attack, but there's no shortage of clever hackers in the world.

- we didn't have browsers compiling JavaScript into machine code

- we didn't have hyperconverged cloud infrastructures running arbitrary entities' code next to each other

Re: LLVM patch to fix half of Spectre attack

#74

Post by nwmcsween »

tptacek wrote: post #58
fooker wrote: post #10

retpoline seems to be a novel concept. Can anyone ELI5? Also, any insight about performance impact here?

An indirect jump is when your program asks the CPU to transfer control to a location that your code itself computes: "jmp %register". Compare to a direct jump, where the destination of the jump is hardcoded into the jump instruction itself: "jmp $0x100". Most programs have indirect jumps somewhere. Higher-level languages with virtual function calls have lots of indirect jumps, because they parameterize functions: to…

Intel is going to release a microcode update for BTB control apparently.

Re: LLVM patch to fix half of Spectre attack

#75

Post by ashleyn »

tzahola wrote: post #73
js2 wrote: post #52

Earlier quoted context omitted.

CPUs have been vulnerable to this attack since 1995. How did it collectively take us 22 years to figure this out? I know it's a highly esoteric complex attack, but there's no shortage of clever hackers in the world.

- we didn't have browsers compiling JavaScript into machine code - we didn't have hyperconverged cloud infrastructures running arbitrary entities' code next to each other

Sounds like it's time for me to give up on the so-called "modern web" and install noscript.

Re: LLVM patch to fix half of Spectre attack

#76

Post by paulmd »

wyager wrote: post #70
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…

> 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).

This is harder than it seems, because once cache is deleted you can't just un-delete it, you'd have to go back to memory and pull it again.

Only the "extra copy of processor state" thing is really viable. You have to have a speculative cache and buffer in reads that only get flushed to the main cache once they're confirmed to be valid, which is enormously complicated. This facility already exists for writes, but now it needs to exist for reads too.

GP is absolutely correct that this is a fundamental assault on processor design as we know it, the speculative execution concept is going back to the drawing board for a major re-think.

Re: LLVM patch to fix half of Spectre attack

#77

Post by maxerickson »

CmdDot wrote: post #54
ant6n wrote: post #41

Earlier quoted context omitted.

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!

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…

Horizontal scaling though. If every individual processor is slower, more are needed.

Re: LLVM patch to fix half of Spectre attack

#78

Post by peapicker »

This brings to mind Ken Thompson's "Reflections on Trusting Trust"[1] -- after all, all I have to do to write code with the exploit is be able to remove the patch and rebuild the compiler and build some executables.

Trusting in a compiler you hope was used to build all the executables on your system isn't trustworthy enough to be the final solution.

[1] https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html

Re: LLVM patch to fix half of Spectre attack

#79

Post by tlrobinson »

bouk wrote: post #48
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…

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

Isn't that a bit like a firefighter saying your house burning down is "glorious"?

Re: LLVM patch to fix half of Spectre attack

#80

Post by ikeyany »

jasode wrote: post #55
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…

>Its hard to get your head around how big a deal this is. It truly is difficult to predict all the ripple effects from this. I can't think of a single computer bug in the last 30 years that's similar in reach to this Intel Meltdown. [EDITED following text to replace "Intel bug" with "Spectre bug" based on ars and jcranmer clarification. The Intel Meltdown can be fixed with operating system update patches for kpti ins…

Is this a 5% to 50% performance hit on all workloads or specific workloads?
Post reply on HN