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

101–110 of 203 posts

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

#101

Post by Randor »

tester756 wrote: post #2

>"Intel's suggested defense against Spectre, which is called LFENCE, places sensitive code in a waiting area until the security checks are executed, and only then is the sensitive code allowed to execute," Venkat said. "But it turns out the walls of this waiting area have ears, which our attack exploits. We show how an attacker can smuggle secrets through the micro-op cache by using it as a covert channel." >"In the…

The best part of the new "defense against Spectre" is that the LFENCE instruction has been around for ~20 years. It's not even not a defense against all variants.

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

#102

Post by varispeed »

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…

The thing is most project could successfully run on a single dedicated server plus have a one or two spares. There is absolutely no need for a slow virtual nodes. I always thought of those cloud solutions as a clever scam.

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

#103

Post by feffe »

hajile wrote: post #55
ljhsiung wrote: post #16

Earlier quoted context omitted.

Even putting aside security aspects aside, in general I've been seeing research pop up over the years criticizing SMT's performance claims of ~30%. Hell, even Amazon's Graviton CPUs don't have it (though I'm sure that's a product of being ARM derived rather than a design decision).

The performance claims are true for all the worst reasons. Let's say you can queue up 100 instructions. This yields the following 1 port 100% of the time 2 ports 60% of the time 3 ports 30% of the time 4 ports 10% of the time 5 ports 2% of the time Increasing the buffer to 200 instructions yields the following 2 ports 80% of the time 3 ports 40% of the time 4 ports 15% of the time 5 ports 4% of the time As in that ma…

The memory latency hiding also works with 2-way SMT. I worked on a networking software doing per packet session lookup in large hash tables. SMT with a Sandybridge core in this application gave 40% better performance which is higher than usually mentioned. So for memory bound (as in cache misses) applications, SMT is a boon.

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

#104

Post by mort96 »

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…

But JavaScript bloat is allowed to stay (by product managers, middle managers, UX designers, etc) because the website is still fast. If the JS bloat actually caused the site to become too slow on fast machines, people with power to change stuff would demand change.

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

#106

Post by the-smug-one »

kdma wrote: post #91
akersten wrote: post #35

Earlier quoted context omitted.

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 + JI…

How would the statically typed WASM open an even wider hole? Assuming you mean that the size of wasm's hole is larger than js, not that their combined holes are larger than either one.

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

#107

Post by pabs3 »

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

Reminds me of the Mill ISA:

https://millcomputing.com/

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

#108

Post by jarcane »

mort96 wrote: post #104
otabdeveloper4 wrote: post #81

Earlier quoted context omitted.

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…

But JavaScript bloat is allowed to stay (by product managers, middle managers, UX designers, etc) because the website is still fast. If the JS bloat actually caused the site to become too slow on fast machines, people with power to change stuff would demand change.

People with the power to change stuff thought Java applets were a good idea in 1995, when most computers in wide circulation could barely run the JVM at any acceptable speed.

Never trust the tech industry to make optimal decisions, you are only in for a bad time.

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

#109

Post by lilSebastian »

baybal2 wrote: post #36
dataflow wrote: post #24

Earlier quoted context omitted.

Spectre could too, but again, my point was that I didn't hear of actual attacks on people in the wild, at least not on any scale that seemed to make the news. Is there a reason to believe this will be different?

The first known Spectre-like concept was actually traced to Pentium 3 times in nineties. It took 2 decades for everybody to forget about it before the vulnerability dismissed as "not exploitable in the practice" came back with a vengeance.

I'd really appreciate a link to this, sounds really interesting.

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

#110

Post by gpderetta »

hajile wrote: post #55
ljhsiung wrote: post #16

Earlier quoted context omitted.

Even putting aside security aspects aside, in general I've been seeing research pop up over the years criticizing SMT's performance claims of ~30%. Hell, even Amazon's Graviton CPUs don't have it (though I'm sure that's a product of being ARM derived rather than a design decision).

The performance claims are true for all the worst reasons. Let's say you can queue up 100 instructions. This yields the following 1 port 100% of the time 2 ports 60% of the time 3 ports 30% of the time 4 ports 10% of the time 5 ports 2% of the time Increasing the buffer to 200 instructions yields the following 2 ports 80% of the time 3 ports 40% of the time 4 ports 15% of the time 5 ports 4% of the time As in that ma…

The reorder buffer size is practically limited by branch prediction probability, not decode bandwidth though.
Post reply on HN