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

Re: LLVM patch to fix half of Spectre attack

#171

Post by sandworm101 » Thu, Jan 04, 2018, 5:38 PM UTC

ufo wrote: post #132

sandworm101 wrote: post #90

Earlier quoted context omitted.

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.

Im less worried about my steam client reading my chat cache than something inside my web browser reading the keys that encrypt my home directory. Short of abandoning all sharing, the least we can do is isolate kernel cache.

Re: LLVM patch to fix half of Spectre attack

#172

Post by jacksmith21006 » Thu, Jan 04, 2018, 5:40 PM UTC

ufo wrote: post #132

sandworm101 wrote: post #90

Earlier quoted context omitted.

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.

Why one solution is put secrets in kernel and use meltdown mitigation to protect.

Re: LLVM patch to fix half of Spectre attack

#173

Post by jacksmith21006 » Thu, Jan 04, 2018, 5:42 PM UTC

JshWright wrote: post #157

tlrobinson wrote: post #79

Earlier quoted context omitted.

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

How many firefighters do you know? I guarantee you every one of them gets excited at the prospect of a "good" structure fire.

Maybe more like a meteorologist excited by a really bad storm.

Re: LLVM patch to fix half of Spectre attack

#174

Post by lousken » Thu, Jan 04, 2018, 5:45 PM UTC

what about performance impact after new CPU architecture arrives? how is that going to work?

Re: LLVM patch to fix half of Spectre attack

#175

Post by ahh » Thu, Jan 04, 2018, 5:45 PM UTC

StavrosK wrote: post #138

tptacek wrote: post #58

Earlier quoted context omitted.

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?

I don't know any way to leave enough breadcrumbs to do that in four clock cycles, do you?

Re: LLVM patch to fix half of Spectre attack

#176

Post by Matthias247 » Thu, Jan 04, 2018, 5:49 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?

Hmm, interesting question. On the hand JITs do devirtualization, so that on lots of code paths the indirect calls are replaced with direct ones. Which should mitigate the performance issues. However I think the JITs also need to insert the logic and branches for re-jitting and spectreulative execution. These might be additional indirect calls.

Would be interesting how it balances out in total.

Re: LLVM patch to fix half of Spectre attack

#177

Post by jacksmith21006 » Thu, Jan 04, 2018, 5:49 PM UTC

badrequest wrote: post #8

I, for one, am eternally grateful for the incredibly bright people who take the time to patch this sort of stuff.

Also to Google for finding and documenting it so well. Google security team really should be given an award.

Re: LLVM patch to fix half of Spectre attack

#178

Post by Klathmon » Thu, Jan 04, 2018, 5:52 PM UTC

xigency wrote: post #168

Klathmon wrote: post #119

Earlier quoted context omitted.

It's not just "untrusted code" any more. The "true secure" way is not running any untrusted code, not connecting to any untrusted networks, and not accepting or storing any untrusted data. At that point you can't run a computer. It's just not an answer to say "don't let bad things in" because bad things are always going to get in. And with side channel exploits getting more and more common, and with them being worse…

Eliminating out of order execution completely would result in much more than a 15% performance reduction.

That's what I was trying to say a bit more tongue in cheek...

Re: LLVM patch to fix half of Spectre attack

#179

Post by puzzle » Thu, Jan 04, 2018, 5:58 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…

I'd be surprised if other Googlers like Christian Ludloff (also of sandpile.org fame) and Dean G were not involved. They know x86 better than many engineers at Intel/AMD, having been in charge of the most performance/cost critical code (e.g. tuning search serving down to the last cycle), as well as qualifying new platforms and identifying a steady stream of CPU bugs.

Re: LLVM patch to fix half of Spectre attack

#180

Post by phkahler » Thu, Jan 04, 2018, 6:00 PM UTC

Keyframe wrote: post #72

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.

From one of the papers:

>> While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruc- tion set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak.