Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New x86 micro-op vulnerability breaks all known Spectre defenses

sciencedaily.com

Post reply on HN
Print view View original

91–100 of 203 posts

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#91

Post by kdma »

akersten wrote: post #35
MarkSweep wrote: post #27

Earlier quoted context omitted.

> if I have untrusted code running on my CPU, I've already lost Don’t forget about JavaScript, a common way for people to run untrusted code on their computers. Not all of micro-architectural data sample are exploitable in JavaScript, but some are.

Yeah, JS is the only hairy part. I considered mentioning it, since I know it was going to come up. But luckily, all I've seen so far are basic demos (like leaky.page) that read data from a carefully-crafted array that the page itself populated. I've yet to be convinced that you could realistically exfiltrate meaningful data at any sort of scale with in-browser JS, especially now that more blatant bugs like Meltdown a…

https://googleprojectzero.blogspot.com/2019/04/virtually-unl... one of the many public browser RCE. Or look for the ps5 jailbreaks, the browser is the common denominator for most systems and its leaky as hell given that JS is dynamically typed and everything gets JIT-ed to hell (https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/) most exploits I've seen are about tricking webkit into type mismatching + JIT "invalidation". WASM open this hole even wider

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#92

Post by bonzini »

smasher164 wrote: post #75

Maybe EPIC [1] architectures need a revival. Rely on compilers to take advantage of explicit instruction-level parallelism, and keep the CPU dumb. [1] https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...

That failed for good reasons. Itanium processors ended up using out of order execution and speculation just like everyone else, because the compilers just don't have enough information compared to an out of order execution engine.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#94

Post by fauigerzigerk »

ChuckMcM wrote: post #84
akersten wrote: post #25

I've been saying this from the start: the well of issues is infinitely deep as soon as you decide that multiple tenants running on the same physical hardware inferring something about another is a vulnerability. I assert, but cannot rigorously prove, that it is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects, especially if the CPU is speculating. I don't know…

I think we will eventually see a return to company 'data centers' away from IaaS plays. That said, its a pretty amazing time if you're a computer architect since you now have the transistors to spend on pretty much any crazy scheme you can dream up. So perhaps we'll see 'code safe' computer architectures emerge.

> I think we will eventually see a return to company 'data centers' away from IaaS plays

I don’t see why. Cloud providers have been offering dedicated hardware for a long time. If this problem isn‘t reliably fixable then more customers will make use of these options.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#95

Post by indigochill »

akersten wrote: post #25

I've been saying this from the start: the well of issues is infinitely deep as soon as you decide that multiple tenants running on the same physical hardware inferring something about another is a vulnerability. I assert, but cannot rigorously prove, that it is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects, especially if the CPU is speculating. I don't know…

> We're going to wind up undoing the last 20 years of performance gains in the name of 'security', and it scares me.

This actually excites me. When the foundation is shown to be rotten, it's time for a new foundation.

I'm optimistic, though, that the future holds a fork, with some devices insecure-but-fast and others secure-but-slow. Because there's a market for both. I don't care if my gaming hardware is vulnerable to Spectre because ideally there's nothing worth stealing there anyway. Email/messaging hardware can afford to be a -lot- slower than my gaming rig without any appreciable impact on the experience.

Perhaps the future holds motherboards that look like the physical embodiment of Qubes OS, with secure and insecure chips running compartmentalized features based on their security/speed requirements. We already do something like this for performance with the divide between CPUs and GPUs.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#96

Post by tannhaeuser »

otabdeveloper4 wrote: post #81
userbinator wrote: post #73

Earlier quoted context omitted.

It sounds like a dream, but going back towards interpreted JS instead of JIT may finally stem the insanity of bloat that JS has evolved in an environment of increasingly fast implementations.

The problem of Javascript bloat doesn't have a technical solution. Javascript bloat exists because of a social problem: the guy who fixes the corporate webpage's javascripts is called a "webdesigner", and "webdesigners" are the lowest rung on the corporate IT ladder, maybe only a bit above first-tier techsupport. If you want to make some sort of career you need to upgrade from "webdesigner" to "frontend developer", a…

No reason to insult web developers in general. The simpler explanation is that webapps exist because of an economical problem: that you can make more money (have lower barriers) by either recurring payments for services, or by selling your user's attention, or both.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#97

Post by failwhaleshark »

The act of loading code into memory, be it a hypervisor or a guest OS, should've been gated by sanitation and validation callbacks. Building all of these macro- and micro-op runtime defenses and mitigations in the processor and slowing down the OSes for every possible runtime edge-case are a waste of speed that can be avoided by establishing trust of code pages.

The morphing of data into code pages with JITs like JS should also be subject to similar restrictions.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#98

Post by tehbeard »

akersten wrote: post #25

I've been saying this from the start: the well of issues is infinitely deep as soon as you decide that multiple tenants running on the same physical hardware inferring something about another is a vulnerability. I assert, but cannot rigorously prove, that it is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects, especially if the CPU is speculating. I don't know…

Honest question, what's the "Explain like I'm a Freshman" for what they can work out/leak from all the spectre stuff?

I see alot about private keys etc etc, but is just a blind attack? Or do you need more info on the target? How quickly can you attack to get info?

In essence, is this something Joe Public needs to worry about their $5 vps, or something nefarious using against $CORP's public cloud infrastructure?

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#99

Post by kaba0 »

baybal2 wrote: post #34
MarkSweep wrote: post #27

Earlier quoted context omitted.

> if I have untrusted code running on my CPU, I've already lost Don’t forget about JavaScript, a common way for people to run untrusted code on their computers. Not all of micro-architectural data sample are exploitable in JavaScript, but some are.

Chrome had 7 exploits caught in the wild within 7 weeks in 2020. I believe it is going towards JIT being disabled, or most severely limited.

That would pretty much instantly kill the web, no matter how lean they make websites.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#100

Post by kaba0 »

willis936 wrote: post #58
paulmd wrote: post #57

Earlier quoted context omitted.

I've been saying since this initially came up that big.LITTLE is the long-term solution for this. In the grand scheme of things, high-intensity tasks are only infrequently high-security tasks - those two sets of workloads are mostly disjoint. So the long-term solution is to have "fast cores" and "secure cores". The fast cores can have all the OoO, speculation, all of that good stuff. That's where you run anything tha…

>In the grand scheme of things, high-intensity tasks are only infrequently high-security tasks - those two sets of workloads are mostly disjoint. The most intense thing my phone does is decrypt my password database, and it does this dozens of times a day.

I’m fairly sure that all around the GUI is way more intense than that.
Post reply on HN