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

221–230 of 248 posts

Re: LLVM patch to fix half of Spectre attack

#221

Post by foota »

bsdetector wrote: post #211
jcranmer wrote: post #101

Earlier quoted context omitted.

I think the main takeaway should be "speculative execution creates exploitable side-channels, and you should assume your hardware is exploitable until proven otherwise." AMD and ARM are probably still exploitable with unknown exploits, possibly even at Meltdown-levels of exploitability, but people haven't taken the time to reverse-engineer the microarchitecture enough to find the exploits. If I were developing proces…

> main takeaway should be "speculative execution creates exploitable side-channels, and you should assume your hardware is exploitable until proven otherwise." Speculative execution does not create side-channels in and of itself, side effects of speculative execution does that. In this case the side effect of cache state. Just don't change the cache during speculative execution and there's no problem.

Why can't the processor isolate those cache lines during speculative execution?

Re: LLVM patch to fix half of Spectre attack

#222

Post by kllrnohj »

cthalupa wrote: post #219
kllrnohj wrote: post #214

Earlier quoted context omitted.

Other than javascript in a browser there does not appear to be much in the way of actual spectre attack vectors, though. So once browsers are patched spectre appears to be basically "fixed" for most practical purposes. Worth noting that many of the claims around Spectre are wholly un-demonstrated. The PoC only involves reading memory from within the same process (aka, the PoC read memory through a side channel that i…

>Worth noting that many of the claims around Spectre are wholly un-demonstrated. This is untrue. https://googleprojectzero.blogspot.com/2018/01/reading-privi... Variant 2 is Spectre. "This section describes the theory behind our PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific version of Debian's distro kernel runnin…

Note that variant 2 of spectre has not been demonstrated on AMD and AMD claims to be unaffected ( http://www.amd.com/en/corporate/speculative-execution )

However, the description of spectre from spectreattack.com is this:

"Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets."

That, however, is not demonstrated by any of these PoC, not that I can find.

Re: LLVM patch to fix half of Spectre attack

#223

Post by wglb »

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…

I like to think of a lot of vulnerability discovery and research as solving a puzzle. In the sense that this puzzle has so many far reaching implications makes it totally compelling to me. tqbf says "glorious", and I couldn't disagree.

[Edit] Or, how far down does the rabbit hole go?

Additionally, it is quite fascinating to me to compare the complexity of modern CPRUs with, say, a compiler.

Re: LLVM patch to fix half of Spectre attack

#224

Post by senatorobama »

s4vi0r wrote: post #133
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?

Uh, isn't this what AMD does?

Re: LLVM patch to fix half of Spectre attack

#225

Post by ece »

crb002 wrote: post #129
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…

CPUs should have a single instruction that wipes branch prediction caches. I would have it off by default, and add to the C/C++ spec this as a standard library macro or pragma. Easy peasy. You only need to wipe between syscalls that have side effects. Number crunching AVX heavy subroutines should never have to deal with safety once entered.

This is what KPTI does, wipe caches, and if you did this often in user code, performance degradation would be all over the place. Also, heavy AVX routines that use encryption keys... would be great to attack.

Re: LLVM patch to fix half of Spectre attack

#226

Post by ece »

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…

More likely, this is a shift back to in-order processors, if the solutions aren't workable. If you're in an embedded scenario, sure you can make more trade-offs and have more control, but it's not going to look great when it happens to get hacked.

Re: LLVM patch to fix half of Spectre attack

#227

Post by comicjk »

tzahola wrote: post #217
comicjk wrote: post #181

Earlier quoted context omitted.

Or, as a compromise, no third-party javascript. Google can easily code up the 100 most common javascript ad formats and let advertisers pick from a menu.

Why would you need a Turing-complete language to describe advertisements ? Why can't they be static images? Or static HTMLs?

From the advertiser's perspective, it wouldn't be a Turing-complete language, since they would only have access to standardized templates. Such a system would probably have to be implemented in Javascript at the browser level though, unless you could do it all with CSS animations.

Re: LLVM patch to fix half of Spectre attack

#228

Post by phyzome »

tptacek wrote: post #122
gpm wrote: post #89

Earlier quoted context omitted.

To the extent that he exploits computers for a living (e.g. pentesting) and not stops exploits for a living, it seems more like a (presumably law-abiding) arsonist calling houses burning glorious.

Arsonists set fires. Vendors create vulnerabilities, not pentesters.

Ooooh, I dunno, I might argue that vendors have their role in creating pentesters. ;-)

Re: LLVM patch to fix half of Spectre attack

#230

Post by ant6n »

gmueckl wrote: post #145
ant6n wrote: post #116

Earlier quoted context omitted.

New CPUs could just convert the retpoline back to the original jump in microcode, and enable the now timing-attack safe branch predictor.

But even then a performance hit remains due to the increased code size of the instruction sequence.

There's a lot of space left in code already to insert trampolines later. And in the end of the day most memory is data, not code.

And eventually, this code will get replaced anyway (just like today there are often multiple code paths in binaries, and a lot of code is compiled for host anyway).

In any case, the performance impact of a couple extra bytes per indirect call is small compared to disabling branch target prediction.

Post reply on HN