Live data from Hacker News

New x86 micro-op vulnerability breaks all known Spectre defenses

sciencedaily.com

1–10 of 203 posts

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

#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 case of the previous Spectre attacks, developers have come up with a relatively easy way to prevent any sort of attack without a major performance penalty" for computing, Moody said. "The difference with this attack is you take a much greater performance penalty than those previous attacks."

>"Patches that disable the micro-op cache or halt speculative execution on legacy hardware would effectively roll back critical performance innovations in most modern Intel and AMD processors, and this just isn't feasible," Ren, the lead student author, said.

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

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

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

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

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

#9

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 cache. And you know you didn't put it there. So some other thread that you're sharing a CPU core with must have put it there.

To exploit those attacks, you're going to intentionally watch the other thread as it, for example, (speculatively) takes a branch, and either puts something in cache or doesn't. Now you know whether the other thread (speculatively) took a branch or not! Just from measuring timings of the cache.

From that, you work back to what the branch condition (that was still only speculatively executed) must have been, and if this branch is based on (speculatively loaded) data, you just leaked one or more bits of the data.

Suddenly, things are not speculative anymore. You guessed data that wasn't yours, because speculatively using it had an effect on the cache, and you could measure that effect. Here, they use the micro-op cache (I haven't read the paper, so I don't know the details, but this is broad strokes).

Any mechanism that you can use during speculation, and that you can extract timing information from is potentially a problem. And these are everywhere.

That's why the Spectre problem is so hard to fix now that pandora's box is open.

Post reply on HN