New Micro-Op Cache Vulnerability Evades All Previous Fixes For Spectre-Like Attacks

ffkom writes: Modern x86 and ARM CPUs translate opcodes into ops, which are usually stored in a cache of their own for later re-use. Researchers from the university of Virginia have found a way to exploit this for side-channel attacks, where malicious code exfiltrates information from other processes or virtual machines based on measurable characteristics of the op-cache state, which they describe in their scientific paper.. This side-channel attack evades all previous fixes for SPECTRE-like attacks, and poses yet another difficult-to-address risk to all software that runs on CPUs that are used by possibly malicious code at the same time -- like code running on other people's computers ("the cloud") or code running on CPUs that at the same time run "sandboxes" with code from some untrusted sources on the Internet.

Ha

[ArchieBunker]

I'm using a SPARC cpu you insensitive clod!

Re:

[spth]

Indeed RISC (e.g. SPARC, MIPS, RISC-V) is a way to avoid this vulnerability since it doesn't need a microarchitecture separate from the ISA, and thus no micro-op cache.

Re:

[Ostracus]

Timing attacks however are the issue regardless of how executed.

Re:

[amp001]

Agreed. In fact, while the paper's introduction and the summary above both mention ARM, this attack does not appear to apply to it. "ARM" appears only once in the paper (in the introduction), and the paper's conclusion makes it clear this applies to Intel and AMD processors.

Re: Ha

[NagrothAgain]

According to a statement by Intel, it doesn't affect them. And from what I've seen, all the major hypervisor vendors previous patches would already eliminate this attack.

AMD has been suspiciously silent so far, indicating that they either are vulnerable or simply don't care enough to check.

Re:

[DamnOregonian]

Not relevant.
ARM-A77+ CPUs use micro-op caches, the target of the paper.
It's a newer feature in ARMs, so they didn't focus on it, but they correctly included it in the summary.

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[amp001]

It isn't. The paper's introduction mentions ARM, but it doesn't use micro-ops or SMT. The rest of the paper focuses on Intel and AMD processors.

Re:

[DamnOregonian]

Incorrect.
Superscalar ARMs (ARMv8+) are do in fact use micro-operations in their execution pipelines.
It allows better utilization of execution resources.

Re: Ha

[BAReFO0t]

What is Thumb then?
Not an instruction set that is translated?

Re:

[amp001]

Thumb is just a more compact encoding. It's implemented entirely in the instruction decoder. No micro-ops required.

Re:

[DamnOregonian]

This statement is false, unless you evaluate it tautologically.
Since RISC is not a boolean, but a gradient, many RISC processors can in fact have a microarchitecture that diverges from their ISA (and in fact all ARM microarchitectures newer than 2011 do)
The 3 you listed are very strict RISC, and do not do not in fact have micro-ops, but they are not the definition of RISC.

Re:

[drinkypoo]

SPARC CPUs were vulnerable to the base SPECTRE attacks initially reported, though they have seen microcode updates for mitigation.

Same Song, Same Dance?

[dowhileor]

How old is branching, speculative branching, off die execution? All features mind you of just about all cpu's?

Re:

[DarkOx]

You pretty much have to go back to i486 and chips from that era. Obviously the stuff is therefor older but it was in some case in first gen Pentiums and around that time where most of those things started to appear in forms you'd recognize today and in mass market produts.

Re:

[drinkypoo]

In PCs, speculative execution first appeared in the Pentium (Intel) and K6 (AMD). POWER1 (1990) was the first commercial out-of-order microprocessor, though the first known full OoO computer was the IBM System/360 Model 91 (1966).

Not much of a threat really

[olsmeister]

At least to the average person. These types of attacks would be extremely difficult to pull off. And honestly any type of fix is likely to include a performance hit, so I don't expect any back-fixes to be released for them.

Re:

[fennec]

I think the paper is based on similar attack as demonstrated by Google here: https://leaky.page/ [leaky.page] I'm using Chrome 90 and this attack still works. It can extract data from one page to another using pure JS and while it's only reading an array of bytes, it could probably read a password field or even an auth cookie.

Re:

[rv6502]

There is one saving grace with those "spectre" types of attack is they rely on measuring tiny changes in timing over a relatively long time to gather one single bit out of statistical noise.
And they need the system to be very "quiet".

It's like listening to a mouse's noises inside a cabinet to infer how many cans of food are in there without opening the door.
It stops working when the neighbor is throwing a trash-metal party, drowning everything in noise.

The proof-of-concepts fails when programs other than th

Re:

[hcs_$reboot]

These types of attacks would be extremely difficult to pull off. And honestly any type of fix is likely to include a performance hit

Not sure about that. The idea is not to break the optimization scheme (based on caching some known data), but rather detect the pattern of an attack. That can be done thanks to added logic running in parallel. That kind of attack is based on a lot of repetitive invalid accesses, rendering only a bit at a time, bit values which accuracy is only within a range of probabilities. This will be detected in the future ; a vector of defense could be to cut the optimization mechanism a very short time, repeatedly an

Re:

[Anubis IV]

Attacks like these are only difficult to pull off until someone writes a library or other code that anyone else can use. And given that there’s no honor among thieves, that really just means that someone just needs to post a proof of concept or early version of malware that uses the relevant vector for attack.

Re:

[Tablizer]

That's the idea behind "script kiddies": they swipe, barter, or buy existing snoop & hack routines and glue them together via cheapass scripts for their own deviousness.

Re:Not much of a threat really

[doug141]

The last patches had less than 1% hit to gaming performance, here are some testing links:
https://www.tomshardware.com/r... [tomshardware.com]
https://www.eurogamer.net/arti... [eurogamer.net]

Re: Not much of a threat really

[BAReFO0t]

Always this stupis black-eyer talking point.

The "average person" does not exist!
Everyone is an exception somewhere.
Like: Yes, the average person runs a VM. It's called a browser.
And any hostile entity does not actually give a fuck if you are a worthwhile target. It's easier to not add any exceptions and let your malware run free. Besides, every system is a good candidate for a proxy or a botnet.

Why do you need to calm yourself that way anyway? It's not even about that It's about a far-reaching extremely lo

x86 Yes, ARM No

[crunchy_one]

The paper, "I See Dead ops: Leaking Secrets via Intel/AMD Micro-Op Caches" gets it right, but the Abstract tacked onto it get it disturbingly wrong. Here's the deal: the x86 has a CISC instruction set architecture (ISA) while its micro architecture is decidedly RISC. To bridge this gap, x86 implements a just in time compiler (JIT) in hardware that rewrites x86 CISC ops into RISC ops. The cache it maintains of translated ops is the vulnerability. ARM, on the other hand, has a RISC ISA, so it does not have a op cache. Nowhere in the paper do its authors make mention of ARM, just in the abstract. I'm thinking someone other than the paper's authors wrote the abstract out of ignorance, which unfortunately is the only part that most people will read.

Re: x86 Yes, ARM No

[BAReFO0t]

What about ARM chips with more than one instruction set? Like "Thumb".

Re:

[Misagon]

Thumb is still a RISC instruction set, just able to do less per instruction.
Each instruction maps 1:1 to a 32-bit ARM instruction.

Re:

[gweihir]

Indeed. As withe everything faked, faking CISC on top on something else comes with some serious drawbacks. I do not think there is any other real fix besides getting rid of that abstraction layer. Maybe RISC-V will do the trick. There really is not much besides MS Windows that keeps the AMD64 architecture alive.

Re:

[godrik]

ARM, on the other hand, has a RISC ISA, so it does not have a op cache.

mmm, you know that modern ARM have an macro-operation cache, right?

The Cortex-a78 has an L0 MOP Cache of 1536-entry. Source: wikichip https://en.wikichip.org/wiki/a... [wikichip.org]

So does the Cortex-A77 https://en.wikichip.org/wiki/a... [wikichip.org]

Modern ARM have assembly instructions that get decoded to macro op and eventally get transformed to micro ops.

Now, is that macroop cache susceptible to the same problem, I am not sure. But ARMs DEFINITELY have macro operation caches.

Re:x86 Yes, ARM No

[crunchy_one]

The x86 microOp cache and the ARM macroOp cache rhyme, but they're not the same thing. In fact, x86 has both a microOp and a macroOp cache. That said, you do have a point that both types of caches contain cracked instructions, so they may suffer from a similar vulnerability. Key to the vulnerability described in the "I See Dead uOps" paper is the operation of the x86 LFENCE instruction, which does not flush the microOp cache, and so leaves instructions that should be secure extant in the microOp cache across task switches. As the paper points out, flushing the x86 iTLB will also flush the uOp cache, mitigating the vulnerability at the cost of performance. In fact, Intel SGX flushes the uOp cache automatically on enclave entry/exit, so using SGX will also mitigate the vulnerability. On the other hand, the AMD macroOp cache is automatically flushed when the ISB instruction is issued, so any vulnerability similar to that described in the paper involving the macroOp cache has already been mitigated.

"A VM is not a security solution."

[BAReFO0t]

A wise man once said.

Re:

[gweihir]

Already posted, so only a symbolic "+1, Insightful"

Re:

[lessSockMorePuppet]

Constant time execution is one path, another is fully homomorphic computing/host-proof computing, but you still need a separate trusted processor to select instruction code and perform encryption of inputs/ decryption of outputs. Maybe that one can be made very small and constant time.

Looks like CPUs need some new ideas

[gweihir]

Because the limits of caching become more and more obvious in connection with speculative execution and long pipelines.