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

211–220 of 248 posts

Re: LLVM patch to fix half of Spectre attack

#211

Post by bsdetector »

jcranmer wrote: post #101
voidmain wrote: post #27

Earlier quoted context omitted.

And I fear there's little reason to think that the "three variants" from project zero's announcement are the full scope of the problem. They were just the variants that the few people in on this found time to develop exploits for. There can now be security bugs in things your program doesn't do; it seems like there is room for nearly unlimited creativity in finding them. From the spectre paper: "A minor variant of th…

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.

Re: LLVM patch to fix half of Spectre attack

#212

Post by sempron64 »

bsdetector wrote: post #206
simias wrote: post #91

Earlier quoted context omitted.

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…

Followup legitimate question: the only way to read data is to control the results of a speculative execution or fetch right? For JavaScript won't it be sufficient to check all the calls out of it so that they can't pass data that controls an exploitable speculative execution, and also generate JIT code so the JS itself can't create exploitable instructions. The API will have to be heavily scrutinized and the JS will…

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 cache manipulation nearly impossible) and potentially remove the JIT completely in favor of an interpreter, it's hard to completely be rid of this class of an attack when executing any sort of code on the processor. Those steps are probably possible, but the JS performance hit that ensues would be the death knell of any browser.

That said, without some way of extracting timing at the granularity of 10s of instructions, this attack is moot. So that's likely going to be the mitigation. Unfortunately, the web frames used in some apps are infrequently if ever updated, so JS engine updates there are gonna be hard.

Re: LLVM patch to fix half of Spectre attack

#213

Post by bsdetector »

sempron64 wrote: post #212
bsdetector wrote: post #206

Earlier quoted context omitted.

Followup legitimate question: the only way to read data is to control the results of a speculative execution or fetch right? For JavaScript won't it be sufficient to check all the calls out of it so that they can't pass data that controls an exploitable speculative execution, and also generate JIT code so the JS itself can't create exploitable instructions. The API will have to be heavily scrutinized and the JS will…

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.

Re: LLVM patch to fix half of Spectre attack

#214

Post by kllrnohj »

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.

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 it had full ability to read anyway). Trying to exploit this in a different process is entirely undemonstrated, and there's not even any real discussion in the paper of how it would work. In theory it's doable, but the issues around how you do this once process switching and IPC enters the picture seems substantial yet the paper does not make any attempt to tackle any of that.

Re: LLVM patch to fix half of Spectre attack

#215

Post by dzdt »

pubby wrote: post #117
dzdt wrote: post #34

Earlier quoted context omitted.

I guess he means the retpoline. On the 6502 there is no indirect jump instruction, so you need such tricks just to achieve an indirect jump at all.

There's an indirect jump instruction. It's not very good though, and has a notorious bug with addresses ending in 0xFF.

Gah, you're right. Guess my memory is fading. There is indirect JMP, but no indirect JSR or indirect branches. And the indirect JMP as you say is not very useful.

Re: LLVM patch to fix half of Spectre attack

#216

Post by gpderetta »

FLUX-YOU wrote: post #15
coldcode wrote: post #11

I remember doing tricks like this in 6502 assembly and in other early processors. Amazing that to stop these attacks you have to come up with clever tricks again. Back in the 80's I would have never imagined this type of attack being something to worry about.

>early processors Early processors had speculative execution? I thought this had been added to Intel/AMD/ARM about 20 years ago?

Speculative execution is as old as branch prediction, which is very, very old.

Re: LLVM patch to fix half of Spectre attack

#217

Post by tzahola »

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.

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

Re: LLVM patch to fix half of Spectre attack

#218

Post by pixl97 »

js2 wrote: post #52
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…

CPUs have been vulnerable to this attack since 1995. How did it collectively take us 22 years to figure this out? I know it's a highly esoteric complex attack, but there's no shortage of clever hackers in the world.

Honestly we knew about this in the 70s. Mainframe/time share systems had lots of protections against attacks like this. The problem is mainstream computing when cheap/single user and attempted to build a multi user/untrusted code execution environment on top of it. Now it's come back to bite us in the ass.

Re: LLVM patch to fix half of Spectre attack

#219

Post by cthalupa »

kllrnohj wrote: post #214
ars wrote: post #207

Earlier quoted context omitted.

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

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 running on the host, can read host kernel memory at a rate of around 1500 bytes/second."

Re: LLVM patch to fix half of Spectre attack

#220

Post by pixl97 »

leeoniya wrote: post #126
Piskvorrr wrote: post #115

Earlier quoted context omitted.

Jan 9, 2019? 2050? How much longer is long _enough_?

i guess at minimum it's worth asking how many major hosting providers have been fully patched at the time of disclosure. in addition to browsers and OSes.

You don't "think infosec". If I'm an attacker and I notice both amazon and azure rebooting all their systems I know something is up. When I see that both Microsoft and Redhat employees are working overtime it gives away more information. All I have to do is crack on of their patched systems and I can bin diff it and figure out what is up.

Then I sell it off to blackhats before the rest of the world is aware.

Post reply on HN