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

Re: LLVM patch to fix half of Spectre attack

#131

Post by FractalNerve » Thu, Jan 04, 2018, 4:45 PM UTC

tptacek wrote: post #123

bouk wrote: post #48

Earlier quoted context omitted.

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

It's not that it makes the practice of breaking into computers that much more interesting so much as it makes the underlying field much more interesting to work in. The engineering problems just got a lot more complex. We're all taking an attack vector seriously --- microarchitectural side channels --- that we weren't taking as seriously before, except as an abstract threat to crypto and a way of defeating a mitigati…

> they didn't have the cycles to write everything down!

hahaha that was a good pun! Do you have a link to Jann Horns personal blog or Github? I've not never heard of him before.

Re: LLVM patch to fix half of Spectre attack

#132

Post by ufo » Thu, Jan 04, 2018, 4:45 PM UTC

sandworm101 wrote: post #90

tcoppi wrote: post #45

Earlier quoted context omitted.

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.

Or time to have Kernel live on dedicated cache not ever accessed/shared with anything else. Let the CPU speculate all it wants, just not when playing in the kernel's cache. It may even be time for dedicated kernel cpus/cores.

Reading Kernel memory (Meltdown attack) is extra bad but regular user processes being able to read each other's memory (Spectre attack) is also very bad and not solvable by isolating the kernel.

Re: LLVM patch to fix half of Spectre attack

#133

Post by s4vi0r » Thu, Jan 04, 2018, 4:45 PM UTC

jzl wrote: post #95

A new thing that's going to become a standard part of systems engineering: deciding whether any given system needs to run with or without these kinds of protections. Do you want the speed of speculative execution or do you want Meltdown/Spectre protection? In some cases lack of protection is fine. But figuring out the answer for any given system is often going to take expert-level security knowledge. Security is all…

Spectre relies on tricking the CPU into branch predicting its way into accessing protected memory, no? Is it not possible that we can keep most of the performance benefits of speculative execution by somehow having a built in "Hey, never ever speculate that I'll want to access this region of memory" sort of thing?

Re: LLVM patch to fix half of Spectre attack

#134

Post by als0 » Thu, Jan 04, 2018, 4:45 PM UTC

teilo wrote: post #93

Isn't it the case that the Itanium architecture would not be vulnerable to Spectre because it moves the onus of branch prediction from the CPU to the compiler?

Assuming the compiler knows what it's doing :)

Re: LLVM patch to fix half of Spectre attack

#135

Post by DannyBee » Thu, Jan 04, 2018, 4:46 PM UTC

jgowdy wrote: post #102

The problem I see with this concept is ROP mitigations like Intel’s control flow enforcement don’t seem compatible with intentionally using tweaked addresses with ret. The address they inject won’t match the shadow stack and the program will be terminated.

This is true, and so far, nobody has a better idea. (IE i would expect that unless someone comes up with one, that hardware CFE in its current form dies and won't happen for Intel until the processors are changed in a way that mitigation is not needed)

Re: LLVM patch to fix half of Spectre attack

#136

Post by FractalNerve » Thu, Jan 04, 2018, 4:47 PM UTC

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

Wasn't Intel's transactional CPU Memory the solution, but it also failed to to bugs?

Re: LLVM patch to fix half of Spectre attack

#137

Post by DannyBee » Thu, Jan 04, 2018, 4:47 PM UTC

nikanj wrote: post #127

TheCycoONE wrote: post #110

Earlier quoted context omitted.

The 50% was for a microbenchmark of C++ code making heavy use of virtual. V-tables and jump tables get much more expensive. Any execution path that is known at compile time is not affected.

I wonder where that leaves Java, C#, Node.js etc. Do the VMs generate code that suffers from this?

yes

Re: LLVM patch to fix half of Spectre attack

#138

Post by StavrosK » Thu, Jan 04, 2018, 4:47 PM UTC

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…

Pretty well, thanks. What I'm wondering is: The attack is using the data fetched into the cache from a speculative indirect jump to do a timing attack and discover what's in the former, correct? Why can't the CPU mark the cache area it fetched in the speculative jump as "stale" and discard it? Why wouldn't that fix the problem?

Re: LLVM patch to fix half of Spectre attack

#139

Post by pwg » Thu, Jan 04, 2018, 4:48 PM UTC

peapicker wrote: post #78

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

Every modern compiler usually has extensions that allow for bits of assembly to be inserted alongside the usual C or C++ code.

Unless the compiler is also patched to either disallow inserted assembly, or to modify the inserted assembly (this being both hard and dangerous), someone who wants to exploit the bug will just add their own inserted assembly code that exploits the bug, and a patched compiler won't help one bit in that case.

Re: LLVM patch to fix half of Spectre attack

#140

Post by gmueckl » Thu, Jan 04, 2018, 4:48 PM UTC

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…

I'd rather have linkers go down a similar road that the Linux kernel went on a over a decade ago: provide binary patches in a table (essentially alternative machine code) and have the linker patch the correct alternative depending on the CPU and it's bugs. The Linux kernel already contains an "alternatives" segment which is exactly this kind of list of patches. It would be trivial to add such a table to ELF and PE formats and have the runtime linker process that while it's plowing through the code anyway.