Specter of Spectre is Back, in New Micro-Op Cache Vuln

It’s been three years, but researchers have disclosed new attacks on speculative execution in Intel and AMD chips. Just be thankful they didn’t give it a catchy name.

This time, the flaws are in the cache that speeds up micro operations. As before, clever code can intuit secret data by watching the speed of cache accesses. For example, one cloud tenant might be able to read the private encryption keys of another tenant.

There’s a lot to worry about in branch prediction. In today’s SB Blogwatch, we think happy thoughts.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: moviememes.

Worry, Worry—Super Scary

What’s the craic? Michael Larabel reports—“New Spectre Variants Discovered By Exploiting Micro-op Caches”:

Not protected”

University of Virginia and University of California San Diego researchers have discovered multiple new variants of Spectre attacks that … could yield both Intel and AMD CPUs leaking data. [You] are not protected by existing Spectre mitigations.

Among the potential mitigations would involve flushing the micro-op cache at domain crossings and/or privilege level-based partitioning of the caches. … The researchers will be presenting at ISCA next month on their findings.

And Anton Shilov adds—“New Spectre Exploits Beat All Mitigations: Fixes to Severely Degrade Performance”:

Heavy performance consequences”

Researchers from two universities have discovered several new variants of Spectre exploits that affect all modern processors from AMD and Intel. … Existing Spectre mitigations do not protect the CPUs against potential attacks. … Researchers believe that mitigating these vulnerabilities will cause more significant performance penalties than the fixes for previous types of Spectre exploits.

Since modern CPUs need to flush the Instruction Translation Lookaside Buffer (iTLB) to flush the micro-op cache, frequent flushing of both will ‘lead to heavy performance consequences.’ … To partition micro-op caches based on privileges … would translate into heavy underutilization. [And] performance counter-based monitoring that detects anomalies … is prone to misclassification errors [and] performance degradation.

Who discovered it? Xida Ren, Logan Moody, Mohammadkazem Taram, Matthew Jordan, Dean M. Tullsen and Ashish Venkat say they “see dead µops”:

Cannot be detected”

Modern … processors translate complex instructions into simpler internal micro-ops that are then cached in a dedicated on-chip structure called the micro-op cache. [We can] exploit the micro-op cache as a timing channel to transmit secret information … breaking several existing invisible speculation and fencing-based solutions that mitigate Spectre [and] cannot be detected by performance counter monitors unless they specifically target the micro-op cache.

Frightened yet? akersten is:

It scares me”

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 … cannot rigorously prove [this, but] it is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects.

[Maybe] cloud hosting providers … have to buy a lot more CPUs so every client can have their own. … We’re going to wind up undoing the last 20 years of performance gains in the name of ‘security’, and it scares me.

Is it time for a colorful metaphor? The lead researcher, —Prof. Ashish Venkat stacks strange simile upon abused analogy upon mixed metaphor:

We have to make it work”

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

It is really unclear how to solve this problem in a way that offers high performance to legacy hardware, but we have to make it work. … Securing the micro-op cache is an interesting line of research and one that we are considering.

So here we are again. Paul Teich—@PaulRTeich—feels déjà vu:

Did Intel and AMD take this seriously”

It’s been 3 years since Spectre and Meltdown debuted. It takes a minimum of 3-4 years to design a completely new CPU microarchitecture and bring it to market. … Did Intel and AMD take this seriously in 2018?

So Intel and AMD—but what about ARM? Here’s hotaru.hino:

ARM processors may be affected”

Even though they’ve only tested on Zen and Skylake, if the fundamental flaw is with how to use micro-ops caching, then ARM processors may be affected as well.

But what if this is deliberate collusion between the chip firms? TemplarGR doesn’t mind if you call them a conspiracy theorist:

It has been years”

Now that Moore’s law is dead, CPU manufacturers have found a new way to push for costly upgrades: Just have some researchers publish new holes to fix that butcher the performance on older chips and force people to upgrade sooner.

Call me a conspiracy theorist, I don’t care. Both Intel and AMD have shown little care for actually fixing their damn architectures, and it has been years since the first Spectre/Meldown reveals.

Meanwhile, performance versus security is always a trade-off, right? thegarbz shares this real-life example:

National security”

I also have a front door and a window made of glass, vulnerable to a brick. But I prefer light in my room and the ability to leave the house quickly and easily rather than need to open a bank vault in a cement bunker.

People somehow seem to think that their PCs are storing national security relevant data.

And Finally:

A tiny bit too much stream-crossing?

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. E&OE. 30.

Image sauce: Toa Heftiba (via Unsplash)

Featured eBook
The Dangers of Open Source Software and Best Practices for Securing Code

The Dangers of Open Source Software and Best Practices for Securing Code

More and more organizations are incorporating open source software into their development pipelines. After all, embracing open source products such as operating systems, code libraries, software and applications can reduce costs, introduce additional flexibility and help to accelerate delivery. Yet, open source software can introduce additional concerns into the development process—namely, security. Unlike commercial, or ... Read More
Security Boulevard

Richi Jennings

Richi Jennings is a foolish independent industry analyst, editor, and content strategist. A former developer and marketer, he’s also written or edited for Computerworld, Microsoft, Cisco, Micro Focus, HashiCorp, Ferris Research, Osterman Research, Orthogonal Thinking, Native Trust, Elgan Media, Petri, Cyren, Agari, Webroot, HP, HPE, NetApp on Forbes and CIO.com. Bizarrely, his ridiculous work has even won awards from the American Society of Business Publication Editors, ABM/Jesse H. Neal, and B2B Magazine.

richi has 320 posts and counting.See all posts by richi