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

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

#31

Post by lanstin » Sat, May 01, 2021, 1:08 AM UTC

londons_explore wrote: post #29

baybal2 wrote: post #26

You cannot realistically make a CPU invulnerable to performance analysis And you don't need to. There is really very few uses for real multi-system vs multi-process shared systems. Take a look on that whole "cloud" thing. All people I knew who worked in cloud hosting tell that most system are ridiculously overprovisioned, effectively nullifying any economic justification for a shared system

One day, when margins shrink for cloud compute, we'll see less and less overprovisioning...

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.

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

#32

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

dataflow wrote: post #24

1e-9 wrote: post #22

Earlier quoted context omitted.

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

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?

It can take months or even years for proof-of-concepts to become widespread in the wild, particularly by those sloppy enough to be easily detected.

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

#33

Post by panny » Sat, May 01, 2021, 1:12 AM UTC

dataflow wrote: post #24

1e-9 wrote: post #22

Earlier quoted context omitted.

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

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?

>I didn't hear of actual attacks on people in the wild

You never would. It's a passive attack. It's measuring response time to normal operations to discover secrets.

https://mlq.me/download/netspectre.pdf

"Software based side-channel attacks are particularly unsettling since they do not require physical access to the device."

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

#34

Post by baybal2 » Sat, May 01, 2021, 1:13 AM UTC

MarkSweep wrote: post #27

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…

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

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

#35

Post by akersten » Sat, May 01, 2021, 1:13 AM UTC

MarkSweep wrote: post #27

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…

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

If anyone can show a proof-of-concept ("this page grabs your password manager extension's data") I'll eat my words. But I feel confident that most of these issues are purely academic and, while interesting, serve more to provide content for PhD theses than represent urgent hazards on the web.

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

#36

Post by baybal2 » Sat, May 01, 2021, 1:18 AM UTC

dataflow wrote: post #24

1e-9 wrote: post #22

Earlier quoted context omitted.

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

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.

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

#37

Post by mikewarot » Sat, May 01, 2021, 1:20 AM UTC

baybal2 wrote: post #30

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…

You are completely correct. The safe execution of any untrusted Turing complete code is a pipe dream. You, at least, need a clean sheet CPU design starting from ISA, and basic logic operations formally validated against instruction level analysis to have a fighting chance. But even such chip do get pwned, as shown by key recovery from credit cards in the wild.

>The safe execution of any untrusted Turing complete code is a pipe dream.

The safe execution of any code requires an operating environment that never trusts the code with more than the least privilege required to complete a task. It has worked in mainframes that way for decades.

The IT zeitgeist these days makes me sad. Things can be better, but almost everyone is pushing in counterproductive directions, or has given up hope.

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

#38

Post by mikewarot » Sat, May 01, 2021, 1:23 AM UTC

tux3 wrote: post #9

PopePompus wrote: post #8

I don't understand this at all; I didn't think the mico-op cache was visible to code written for the x86 ISA at all. Can anyone explain to an idiot (me) how something in micro-op cache can become visible to the outside world?

I'm simplifying a bit (edit: quite a bit =]), but the way these attacks work is generally by exploiting the difference in timing between something being in cache, and something not being in cache. Or some resource being contended vs not contended. If something is in cache, and you also have access to that cache, accessing that thing will be fast and few CPU resources will be used. So you can tell that something is in…

The fix is simple, don't allow access to clocks or timing information in anything other than the microkernel that runs the OS.

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

#39

Post by baybal2 » Sat, May 01, 2021, 1:26 AM UTC

mikewarot wrote: post #37

baybal2 wrote: post #30

Earlier quoted context omitted.

You are completely correct. The safe execution of any untrusted Turing complete code is a pipe dream. You, at least, need a clean sheet CPU design starting from ISA, and basic logic operations formally validated against instruction level analysis to have a fighting chance. But even such chip do get pwned, as shown by key recovery from credit cards in the wild.

>The safe execution of any untrusted Turing complete code is a pipe dream. The safe execution of any code requires an operating environment that never trusts the code with more than the least privilege required to complete a task. It has worked in mainframes that way for decades. The IT zeitgeist these days makes me sad. Things can be better, but almost everyone is pushing in counterproductive directions, or has give…

> The safe execution of any code requires an operating environment that never trusts the code with more than the least privilege required to complete a task. It has worked in mainframes that way for decades.

It has nothing to do with any OS level security features. We are talking about things happening below the level of what software can see.

You just cannot see any sign of such attack by looking at any register the OS can see.

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

#40

Post by jiggawatts » Sat, May 01, 2021, 1:29 AM UTC

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

One sneaky thing I've noticed them doing is slowly switching their licensing over to 1 vCPU = 1 CPU, even though you're now only getting one hyperthread instead of one core.

For Microsoft, this means that they've literally doubled their software licensing revenue relative to the hardware it is licensed to.

This kind of false incentive worries me a lot, because while I like the technical concepts like infrastructure-as-code enabled by the public cloud, I feel like greed will eventually destroy what they've built and we'll all be back to square one.

Ask your cloud sales representative these questions next time you have coffee with them:

- What incentive do you have to make your logging formats efficient, if you charge by the gigabyte ingested?

- If your customers are forced to "scale out" to compensate for a platform inefficiency, what incentive do you have to fix the underlying issue?

- What incentive do you have to make network flows take direct paths if you charge for cross-zone traffic? Or to put it another way: Why does load balancer team refuse to implement same-zone-preference as a default?

Etc...

Once you start looking at the cloud like this, you suddenly realise why there are so many user voice feedback posts with thousands of upvotes where the vendor responds with "willnotfix" or just radio silence.