New x86 micro-op vulnerability breaks all known Spectre defenses • Hacker News Board

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

#161

Post by sitkack » Sat, May 01, 2021, 4:09 PM UTC

the8472 wrote: post #127

tachyonbeam wrote: post #65

Earlier quoted context omitted.

The micro-op cache is very small, on the order of ~1.5K uops AFAIK. It can also be repopulated quite fast. So yes, the performance hit should be quite small. You should presumably also be able to reduce the performance hit if you reduce the frequency of context switches, which should get easier the more cores you have, if I'm not mistaken. That is, the OS can have its own dedicated core, and some programs can be more…

> You should presumably also be able to reduce the performance hit if you reduce the frequency of context switches, which should get easier the more cores you have, if I'm not mistaken. Context switches don't happen that often due to preemption unless your CPU is oversubscribed. Most context switches are due to syscalls, especially the ones used to wait for contended locks. Reducing those takes a lot more optimizatio…

Given the hockey stick number of cores coming at us, I see pinning and better temporal avoidance being solutions. High security code will be pinned to its own core, running in its own memory area.

So much more scheduler work to do.

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

#162

Post by iggldiggl » Sat, May 01, 2021, 4:14 PM UTC

yjftsjthsd-h wrote: post #145

Bancakes wrote: post #87

Earlier quoted context omitted.

20 years ago, computer magazines wrote about single-core 10GHz CPUs. Billions of transistors. What we have can barely be described as performance gains more than "add SIMD and more cores, and performance hacks".

> 20 years ago, computer magazines wrote about single-core 10GHz CPUs Yeah, because they didn't realize how terribly the power consumption / heat output would scale; a 10GHz CPU will just melt itself.

For a humorous take on that, see also James Mickens' The Slow Winter: https://scholar.harvard.edu/files/mickens/files/theslowwinte...

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

#163

Post by sitkack » Sat, May 01, 2021, 4:15 PM UTC

marcan_42 wrote: post #52

wmf wrote: post #43

Earlier quoted context omitted.

Apple Firestorm is even wider but it doesn't have SMT. I guess they just don't care.

Probably because they have an 8-wide decoder and a massive reorder buffer, so they can actually keep the backend fed. The problem with x86 is decoding is hell and requires increasingly large transistor counts to parallelize, so you end up with a bottleneck there. ARM doesn't have that problem.

This the single largest driver of M1 performance.

Variable length, over lapping instructions has made x86 instruction decoding intractable. The obvious answer is make it tractable, the unobvious answer is how to do that and hopefully remain backward compatible.

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

#164

Post by grishka » Sat, May 01, 2021, 4:16 PM UTC

mhh__ wrote: post #141

grishka wrote: post #130

Earlier quoted context omitted.

So ARM CPUs do have microcode after all?

Microcode != Using micro-ops. Microcode has been around for half a century at least, much longer than micro-ops.

Uh. I thought that micro-ops were literally microcode instructions/operations?

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

#165

Post by mort96 » Sat, May 01, 2021, 4:25 PM UTC

otabdeveloper4 wrote: post #151

mort96 wrote: post #104

Earlier quoted context omitted.

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.

Management can't make these sorts of decisions. They can set metrics on quality, but those can be easily gamed. (E.g. measuring average TTFB for a site instead of the real wall time to show visible content for the user.)

Management has the power to say that something isn't good enough and make it a priority. They also have the power to hire employees or consultants if the current team isn't capable of doing it.

Project management _definitely_ has the power to dedicate time to fixing performance issues.

Metrics can be gamed, but certain metrics - such as time to interactive, and time to fully loaded - are fairly well in line with what users actually care about. Even if they're gamed, a project manager can say, "This still feels slow to use. Dedicate the next (sprint|cycle|month|whatever) to performance work."

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

#166

Post by Bancakes » Sat, May 01, 2021, 4:39 PM UTC

mhh__ wrote: post #138

Bancakes wrote: post #87

Earlier quoted context omitted.

20 years ago, computer magazines wrote about single-core 10GHz CPUs. Billions of transistors. What we have can barely be described as performance gains more than "add SIMD and more cores, and performance hacks".

As opposed to the billion transistors we have now?

20 years later, yes. Silicon is endgame. We'll never see 1970s-1990s levels of progress again.

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

#167

Post by mhh__ » Sat, May 01, 2021, 4:40 PM UTC

grishka wrote: post #164

mhh__ wrote: post #141

Earlier quoted context omitted.

Microcode != Using micro-ops. Microcode has been around for half a century at least, much longer than micro-ops.

Uh. I thought that micro-ops were literally microcode instructions/operations?

In a modern processor they are however microcode as a general term is a catch-all term which basically means non-trivial configuration logic stored in somewhere not meant to be touched by people other than the vendor. I think IBM have millicode.

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

#168

Post by 1e-9 » Sat, May 01, 2021, 5:12 PM UTC

kllrnohj wrote: post #125

1e-9 wrote: post #22

Earlier quoted context omitted.

Yes. It could undermine your browser if you allow a malicious site to run JavaScript.

Not really. So far these mostly haven't been able to cross process boundaries, and most browsers have tripled-down on process-sandboxing by this point (iframe sandboxing was the last major push here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if... ) So process-based sandboxing will continue to be the defense here, and process switching will just get a little bit slower as increasingly more caches are…

This is a threat that won’t be fully mitigated until one’s browser is updated to flush the Micro-Op cache.

Of course in the meantime, safe browsing practices such as avoiding untrusted Javascript will provide protection. But then, we should always be doing that anyway, so it's not as if this should be changing behavior of the average, security-conscious person. It's just another in an unending series of threats.

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

#169

Post by smasher164 » Sat, May 01, 2021, 5:50 PM UTC

zokula wrote: post #129

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

> Rely on compilers to take advantage of explicit instruction-level parallelism, and keep the CPU dumb. This very much is never going to be feasible for consumer and general purpose computing.

The ML folks are pulling themselves out of that rut now. There’s lots of interesting work going on for the next generation of compilers.

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

#170

Post by peter_d_sherman » Sat, May 01, 2021, 6:00 PM UTC

yjftsjthsd-h wrote: post #145

Bancakes wrote: post #87

Earlier quoted context omitted.

20 years ago, computer magazines wrote about single-core 10GHz CPUs. Billions of transistors. What we have can barely be described as performance gains more than "add SIMD and more cores, and performance hacks".

> 20 years ago, computer magazines wrote about single-core 10GHz CPUs Yeah, because they didn't realize how terribly the power consumption / heat output would scale; a 10GHz CPU will just melt itself.

>Yeah, because they didn't realize how terribly the power consumption / heat output would scale; a 10GHz CPU will just melt itself.

Tesla, it was claimed, discovered something called "cold electricity" -- that is (according to the claim) -- when you ran it through a circuit -- it cooled rather than heated the circuit!

Now, today we have something sort of like this as thermocouples/Peltier Junctions (see https://en.wikipedia.org/wiki/Thermoelectric_cooling for more/better info on this) -- although it is not known if Tesla's "cold electricity" -- was talking about this effect and/or related -- or not.

Nonetheless -- it seems to me that IF (and it's a big if!) -- IF Tesla's "Cold Electricity" existed, IF it could be rediscovered, and IF it could somehow be integrated on a CPU either as part of or as auxilliary to the main CPU circuitry -- then the CPU cooling problem could be solved(!) -- or at least mitigated somewhat, to the point of allowing/permitting CPU's with higher thermal envelopes/tolerances/CPU speeds...

Again, there are some seriously big IF's there -- but I think it would be a great place for someone to do more research, or for researchers that might have an interest in this area...

It seems to me that Intel and AMD (or heck, any chipmaker for that matter!) -- might (or should!) -- have an interest for more research in this area...