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

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

#81

Post by otabdeveloper4 » Sat, May 01, 2021, 5:02 AM UTC

userbinator wrote: post #73

baybal2 wrote: post #34

Earlier quoted context omitted.

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.

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", and that means cryptic, incomprehensible and pointless "frontend frameworks".

It provides to value to business or users, but management puts up with it because it fixes the problem of employee churn. (Frontend positions are a big pain in the ass.)

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

#82

Post by Salgat » Sat, May 01, 2021, 5:39 AM UTC

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…

Will this even be an issue when we have CPUs with hundreds/thousands of cores that can just sandbox processes to their own set of cores/cache with exclusive unshared memory?

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

#83

Post by miloignis » Sat, May 01, 2021, 5:41 AM UTC

addaon wrote: post #54

mikewarot wrote: post #49

Earlier quoted context omitted.

These are timing attacks, if you can guarantee code runs deterministically, and deny access to timing information, you can defeat the attack.

Timing attacks are only a subset of side channel attacks, though. One can also imagine thermal attacks -- the amount of power you consume leaks information about what you're doing. And if I share a processor with you, there's various ways I can imagine estimating your power usage. On a processor that has dynamic clocking, the clock speed I'm running at is an indicator of the operations you're doing. Even without dyna…

Determining what clockspeed you're running seems like it would also require access to timing information though, right? RAM errors is an interesting idea for sure, but I think that can and should be shored up at the RAM level. I think a strong sandbox, WebAssembly and the like, should be pretty reasonable to run untrusted.

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

#84

Post by ChuckMcM » Sat, May 01, 2021, 5:52 AM UTC

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.

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

#85

Post by Woodi » Sat, May 01, 2021, 5:55 AM UTC

Simplest way around all of this is back to one-core MULTI-SOCKET systems for "civilian" computers like x86 is.

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

#86

Post by Causality1 » Sat, May 01, 2021, 6:09 AM UTC

I expect this to be just like Spectre. The media sizes it as a tool to use fear to drive engagement, vendors partially cripple their hardware to guard against it, and literally nobody ever bothers trying to actually use it against innocent people.

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

#87

Post by Bancakes » Sat, May 01, 2021, 6:12 AM UTC

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…

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

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

#88

Post by pm90 » Sat, May 01, 2021, 6:15 AM UTC

Uehreka wrote: post #45

lanstin wrote: post #31

Earlier quoted context omitted.

I usually end up over provisioning because I need something that is billed along with CPU; for example I have super good C or Go code to run proxies on, they use like 2% of the CPU when they max out the network connection. I add more so the bandwidth goes up.

This. I run into this all the time with WebRTC infrastructure. My SFUs run out of bandwidth long before they’re at 100% CPU. It’d be great if I could easily provision VMs based on bandwidth, but of course cloud providers are always real coy and say things like “this VM size class has Medium bandwidth, but this one has 25Gbps, no we won’t say which of those is bigger.”

Its possible that there are technical reasons related to virtual networks that may be restricting what kind of configurations are possible on their infrastructure. I would expect them to disclose it as such, but cloud providers haven't been very open about sharing those details.

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

#89

Post by jcelerier » Sat, May 01, 2021, 6:26 AM UTC

ljhsiung wrote: post #16

totallyabstract wrote: post #5

There are separate micro op caches per core however they are typically shared among hyperthreads. I wonder if this could be another good reason for cloud vendors to move away from 1vCPU = 1 hyperthread to 1vCPU = 1 core for x86 when sharing machines (not that there weren't enough good reasons already).

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

When doing audio processing I'm getting ~20/25% more oomph with HT enabled

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

#90

Post by tylerhou » Sat, May 01, 2021, 6:32 AM UTC

miloignis wrote: post #83

addaon wrote: post #54

Earlier quoted context omitted.

Timing attacks are only a subset of side channel attacks, though. One can also imagine thermal attacks -- the amount of power you consume leaks information about what you're doing. And if I share a processor with you, there's various ways I can imagine estimating your power usage. On a processor that has dynamic clocking, the clock speed I'm running at is an indicator of the operations you're doing. Even without dyna…

Determining what clockspeed you're running seems like it would also require access to timing information though, right? RAM errors is an interesting idea for sure, but I think that can and should be shored up at the RAM level. I think a strong sandbox, WebAssembly and the like, should be pretty reasonable to run untrusted.

I can still determine timing information by measuring how long it takes to execute a program. The only way to prevent this is to enforce constant-time programs by delaying a response until a specific amount of time (see constant time comparison functions in cryptography). That's not feasible for many applications, especially operations on a latency-sensitive critical path.