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

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

#61

Post by [deleted] » Sat, May 01, 2021, 2:24 AM UTC

baybal2 wrote: post #39

mikewarot wrote: post #37

Earlier quoted context omitted.

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

[deleted]

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

#62

Post by baybal2 » Sat, May 01, 2021, 2:25 AM UTC

mikewarot wrote: post #49

baybal2 wrote: post #39

Earlier quoted context omitted.

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

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

You can't run code deterministically in a multi-tenant system.

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

#63

Post by 1cvmask » Sat, May 01, 2021, 2:49 AM UTC

This quote from the article explains the danger quite well:

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

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

#64

Post by benlivengood » Sat, May 01, 2021, 2:57 AM UTC

baybal2 wrote: post #62

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.

You can't run code deterministically in a multi-tenant system.

You can run algorithms deterministically in a multi-tenant system. Only allow tenants to run deterministic algorithms and side-channels are eliminated. Algorithms with provable time bounds can be run and the output delayed until the known time bound to eliminate timing attacks.

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

#65

Post by tachyonbeam » Sat, May 01, 2021, 2:59 AM UTC

londons_explore wrote: post #3

The solution will be "do not share the micro-op cache between different address spaces". Which for old hardware will translate to "flush the micro op cache every time the address space changes". I would guess that can be done with a microcode update and that the performance hit wont be too massive.

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 or less pinned to other cores where they are rarely interrupted.

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

#66

Post by titoCA321 » Sat, May 01, 2021, 3:07 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…

Stop spreading these ideas. Have to keep the academic gravy train churning. Have to publish glorified book report to finish PhD. Vulnerabilities do not stop at processor execution. I have published book report showing how to capture username and password logins from electromagnetic emissions. Please protect yourself and buy my faraday-cage-as-a-service subscription.

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

#67

Post by mikewarot » Sat, May 01, 2021, 3:10 AM UTC

tolbish wrote: post #59

mikewarot wrote: post #37

Earlier quoted context omitted.

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

Wouldn't the OS code doing the privilege checking be susceptible to vulnerabilities?

Yes, but it wouldn't include code that exploits those vulnerabilities, by design, and it wouldn't trust any other code, so in effect, it would shield the system from it.

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

#68

Post by baybal2 » Sat, May 01, 2021, 3:30 AM UTC

benlivengood wrote: post #64

baybal2 wrote: post #62

Earlier quoted context omitted.

You can't run code deterministically in a multi-tenant system.

You can run algorithms deterministically in a multi-tenant system. Only allow tenants to run deterministic algorithms and side-channels are eliminated. Algorithms with provable time bounds can be run and the output delayed until the known time bound to eliminate timing attacks.

Don't you think this is just too much?

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

#69

Post by brutal_chaos_ » Sat, May 01, 2021, 3:42 AM UTC

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…

To add more to the hairy part: WASM. And that's growing rapidly.

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

#70

Post by [deleted] » Sat, May 01, 2021, 4:04 AM UTC

baybal2 wrote: post #68

benlivengood wrote: post #64

Earlier quoted context omitted.

You can run algorithms deterministically in a multi-tenant system. Only allow tenants to run deterministic algorithms and side-channels are eliminated. Algorithms with provable time bounds can be run and the output delayed until the known time bound to eliminate timing attacks.

Don't you think this is just too much?

[deleted]