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

231–240 of 248 posts

Re: LLVM patch to fix half of Spectre attack

#231

Post by QAPereo »

ufo wrote: post #143
tptacek wrote: post #123

Earlier quoted context omitted.

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…

As someone specializing on a different field, this comment reads to me as if you were an astronomer being excited about discovering a gigantic meteor heading towards the Earth :)

Some of us would be terrified, but also excited about the prospect of studying a supermassive black hole from the inside. You know what I mean? Some things are just so singular and incredible, and so to the heart of a given field of interest, that “glorious” is a perfect word to describe it. An alien invasion of Earth would be a nightmare, but for some it would be the moment they could finally move past the realm of the hypothetical.

Passion is passion, even when it’s terminal.

Re: LLVM patch to fix half of Spectre attack

#232

Post by rphlx »

smt88 wrote: post #124
dingo_bat wrote: post #96

Earlier quoted context omitted.

How about not running untrusted code? That seems to be much easier to do and won't kill performance. Kill js on the web. Run only apps signed by Microsoft. Develop ML based malware fingerprinting that can recognise timing attack patterns. Throwing OO execution away shouldn't be an option in the long term.

"Kill JS on the web" is easy and only mildly inconvenient using NoScript, but that doesn't mean most laypeople are going to do it. Chrome and FF need "execute JS" to be an explicit per-site permission, similar to the permissions model of native smartphone apps. Google will never do this because they're an ad company and care more about targeting ads than protecting Chrome users.

> need "execute JS" to be an explicit per-site permission

I would personally like that, but it's too optimistic to think that the average user would gain much security from it. Most of them will discover that things work fine when they click OK/Accept, and sometimes break when they don't, and so they become conditioned to just click OK/Accept all the time to avoid potential hassle. So in the end it just reduces productivity without increasing security much.

Re: LLVM patch to fix half of Spectre attack

#233

Post by earenndil »

bem94 wrote: post #71
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 i…

My understanding is that meltdown is due to the implementation, but spectre occurs due to issues with the specification.

Re: LLVM patch to fix half of Spectre attack

#234

Post by zacmps »

foota wrote: post #221
bsdetector wrote: post #211

Earlier quoted context omitted.

> 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?

And roll them back? It can, but it doesn't for performance reasons. What the performance impact would be is unknown but this requires a silicon change so unless you work at Intel you'll probably never know.

Re: LLVM patch to fix half of Spectre attack

#235

Post by boltzmann_brain »

ars wrote: post #207
kllrnohj wrote: post #202

Earlier quoted context omitted.

Meltdown is far worse in practice than Spectre. Spectre needs a more perfect storm of factors to lead to exploitation. No hardware is immune to it, but not all software is vulnerable, either. You need code execution and you need a vulnerable target and you need to somehow trigger the vulnerable targets path and that vulnerable target needs data you want. Meltdown just needs code execution and you have full read acces…

> Meltdown is far worse in practice than Spectre. Far worse for an unpached system, yes. But in terms of fixing the problem, Spectre is much worse, with a larger impact. It's so bad that I suspect some people will deliberately run without Spectre protection.

They're both leveraging speculative execution - Meltdown by executing instructions after exception has been raised, Spectre by running them when branch prediction failed. Meltdown method is simpler - just access kernel addresses, so the fix was to remove kernel mapping. But branch prediction methods are a lot more involved and fixing them has so much wider impact as you say -- I mean we're going to have live with even slower virtual calls from now on!

Re: LLVM patch to fix half of Spectre attack

#236

Post by fyi1183 »

bsdetector wrote: post #213
sempron64 wrote: post #212

Earlier quoted context omitted.

Javascript is theoretically fixable -- what's needed is less fine-grained timing capabilities. I think it would be very hard to completely eliminate the possibility of controlling speculative execution as long as you can predictably invalidate the CPU branch predictor, which can be done even at a high level with if statements. Unless you get rid of the notion of contiguous arrays (making predictable word-aligned cach…

Why does it matter if they can cause the CPU's predictors to guess incorrectly if they can't control the target address of the branch or memory access? Example: "if (a I concede that safely checking all data coming from JS code to the browser would be a huge task, but pretty sure it would work to fix the problem for JavaScript although not in general, between processes with shared IO pages and such.

Honestly, you probably don't even need the barrier in your example. Getting data[a] into the cache is no information leak if the attacker already knows a. That's why the example in the Spectre paper uses an additional level of indirection.

Re: LLVM patch to fix half of Spectre attack

#237

Post by rev_null »

comicjk wrote: post #181
tzahola wrote: post #165

Earlier quoted context omitted.

>javascript-enabled ads Good opportunity to get rid of them.

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.

Do they really need 100 formats?

1. Video ad that autoplays.

2. Punch the monkey.

3. ???

Re: LLVM patch to fix half of Spectre attack

#238

Post by imtringued »

ant6n wrote: post #41
jerf wrote: post #32

Earlier quoted context omitted.

That's bad. A single 5% hit might not be the end of the world, but 5% here and 10% there and another 5% over there in the common case adds up badly enough. Doubly-pathological cases (indirect calling-heavy code calling lots of syscalls)... a 50% slowdown and a 30% slowdown combines to a 60% total slowdown. Yeowch. Will be intrigued to see how processor manufacturers respond to this. If they were even slightly relaxed…

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!

Multicore performance is getting faster at a very high pace.

Ryzen 1700X has 3.3 times the multicore performance of my i5 3450 from 2012 for almost the same price. With 7nm we will see at least another 50% increase in multicore performance on top of that.

Re: LLVM patch to fix half of Spectre attack

#240

Post by JdeBP »

simias wrote: post #91
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…

Legitimate question: on any non-shared non-virtualized system is there any reason to enable these workarounds besides running sandboxed applications such as javascript in a web browser (or flash/java applets/Active X, but those are not really super popular nowadays)? For any other non-sanboxed application you pretty much have to trust the code anyway. Privilege escalation is always a bad thing of course, but for sing…

As the owner of gopher://jdebp.info/1/ and the author of gopher://jdebp.info/h/Softwares/djbwares/guide/gopherd.html , I disagree. GOPHER needs a lot of improvement merely to learn the lessons that people learned with FidoNet in the 1980s.
Post reply on HN