Researchers have identified another speculative execution vulnerability and this one isn't fixed by the current OS patches. It seems very likely that the era of making processors faster by being clever might  well be over.

A team of researchers at the University of Virginia School of Engineering led by Prof Ashish Venkat found the problem in the micro-op cache. This is a stage before the protection against speculative execution kicks in and currently it has been shown to affect AMD and Intel processors, although the principle is general.

The paper, amusingly called "I See Dead µops" is no joke. CISC machines like the x86 gain many of the advantages of a RISC machine by decomposing big instructions into micro-ops. These micro-ops are stored in a micro-op cache in another effort to speed things up.

x86 micro-op cache and decode pipeline

The processor actually runs micro-ops from the cache - ignoring the usual instruction pipeline - until a cache miss occurs. when it is reactivated and the CISC-to-RISC process restarts. This suggests that by stalling the cache you might be able to find out details of what it contains. This seems unlikely because the software we write has no direct access to the micro-op cache - it basically has no knowledge of it. However, despite this, the research team managed to find ways of using the regularities in the cache implementation to extract data from other processes:

"...framework for automatically generating high-bandwidth micro-op cache-based timing channel exploits in three primary settings – (a) across code regions within the same thread, but operating at different privilege levels, (b) across different co-located threads running simultaneously on different SMT contexts (logical cores) within the same physical core, and (c) two transient execution attack variants that leverage the micro-op cache to leak secrets, bypassing several existing hardware and software-based mitigations, including Intel’s recommended LFENCE.. "

It also seems to be difficult to fix by its very nature:

"...because the micro-op cache sits at the front of the pipeline, well before execution, certain defenses that mitigate Spectre and other transient execution attacks by restricting speculative cache updates still remain vulnerable to micro-op cache attacks."

You can read about the details in the paper - it also is an interesting guide to the x86 execution pipeline, much of which is undocumented.

What does Intel have to say about the problem? It suggests that the solution is for programmers to adopt "constant time programming". This basically means making sure that each alternative leg of your program should take the same amount of time to execute. This is more a problem for the compiler writers, but even then it isn't likely to be an effective solution.

Putting the problem into context, however, is a matter of seeing where the attack could originate. The most risky situation is when you are using cloud- or shared-computing. Who knows what apps are sharing the processor that your supposedly secure code is running on. In this situation there is little you can do, apart from using constant time programming. If you own the machine and don't share the processor with foreign code then you might think that the machine would have to be compromised in some way for the attacking program to  run on the same processor. However, when you allow access to the processor from code from the Internet, even if it runs in a sandbox, then you are vulnerable.

In the early days we achieved ever faster processors by increasing the clock speed plus a little architectural tinkering. When the clock speed increase reached its end-stop, and the signals refused to stay in the wires any more, all that was left was the tendency to increasingly clever architectures. When designers worked on these their first thought was about processing power and security was only an afterthought.

The idea that speculative execution, reordering and micro-op caches could result in extreme vulnerabilities must have seemed very far-fetched. Today, when you look at the way such techniques can leak information, it is hard not to conclude that the only secure processor is one that is either very simple, and hence very much slower than what we are used to, or one that only runs software that is 100% owned by the owner of the secrets.

More Information

I See Dead µops: Leaking Secrets via Intel/AMD Micro-Op Caches

Xida Ren University of Virginia, Logan Moody University of Virginia, Mohammadkazem Taram University of California, San Diego, Matthew Jordan University of Virginia, Dean M. Tullsen University of California, San Diego, Ashish Venkat University of Virginia.

Related Articles

How Spectre Works

How Meltdown Works

ROP Mitigations Bypassed

Rowhammer - Changing Memory Without Accessing It

ShellShock - Yet Another Code Injection Vulnerability

Heartbleed - The Programmer's View

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info