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

241–248 of 248 posts

Re: LLVM patch to fix half of Spectre attack

#241

Post by lorenzq »

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?

I read an ars technica article that this would be a possible solution but isn’t right now because the hardware to check access rights isn’t fast enough yet

Re: LLVM patch to fix half of Spectre attack

#242

Post by strongholdmedia »

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…

>>Worth noting that many of the claims around Spectre are wholly un-demonstrated.

>This is untrue.

Anything that is not demonstrated in a reproducible way (that is, some downloadable PoC code) is wholly un-demonstrated. To date, afaik, that goes for Spectre in whole.

Re: LLVM patch to fix half of Spectre attack

#243

Post by strongholdmedia »

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…

> - browsers like Chrome & Firefox have to compile with new defensive compilation flags because it runs untrusted Javascript

Not meaning to be that rude, yet this itself summarises (and the issue perhaps will shed more light on) how stupid an idea is to let everybody run untrusted code from other peoples, let alone third party stuff like "privacy-intrusion-as-a-service" startups et aliae.

Re: LLVM patch to fix half of Spectre attack

#244

Post by strongholdmedia »

manol74 wrote: post #208
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.

Qubes OS [1] does something like that [1]: https://www.qubes-os.org/

Yet Meltdown nuked exactly that.

Re: LLVM patch to fix half of Spectre attack

#245

Post by bsdetector »

fyi1183 wrote: post #236
bsdetector wrote: post #213

Earlier quoted context omitted.

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.

Yes thanks to HN being so quick to freeze comments I was unable to fix the example.

Point is, a JavaScript program in isolation cannot read anything, it has to interact with the other target code somehow. If that interaction (the data passed over the API call) can't fail after a certain point and can't be used to read data before that point, then the JS can't read anything.

Re: LLVM patch to fix half of Spectre attack

#246

Post by strongholdmedia »

As Alex Ionescu has put it:

> We built multi-tenant cloud computing on top of processors and chipsets that were designed and hyper-optimized for

> single-tenant use. We crossed our fingers that it would be OK and it would all turn out great and we would all profit.

> In 2018, reality has come back to bite us.

This is the root of all the problems.

Re: LLVM patch to fix half of Spectre attack

#247

Post by paulmd »

leoc wrote: post #84
paulmd wrote: post #76

Earlier quoted context omitted.

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…

I can’t help wondering what igodard’s day is like so far...

"I'm walking on sunshine..."

Re: LLVM patch to fix half of Spectre attack

#248

Post by danjoc »

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.

Surprisingly, this is how chromium(chrome?) works. You can set it to block JS by default, then you get a symbol in the address bar. If you want to enable JS on a domain, right click it and enable. Now all the JS on that domain loads normally. It isn't as fine grained as NoScript, and there's not an easy way to temporarily allow. However, it's probably more normie friendly than NoScript that way.
Post reply on HN