Over the past year, chip makers, operating system vendors, and browser makers have released multiple software updates addressing the two broad classes of flaws—Meltdown and Spectre—which attackers can abuse to access protected areas of a processor’s memory. It is becoming more apparent that side channel attacks affect all microprocessors with the speculative execution feature (which is most of them!), making them more widespread than was originally believed. A team of computer scientists from Google now believe that chip makers and operating system vendors won’t be able to resolve Spectre-class issues through just software. Hardware-based fixes will be necessary.
“As a result of our work, we now believe that speculative vulnerabilities on today's hardware defeat all language-enforced confidentiality with no known comprehensive software mitigations,” the researchers wrote in Spectre is here to stay: An analysis of side-channels and speculative execution.
A hardware design weakness in Intel x86 processors, Meltdown allowed attackers to read memory reserved by the operating system kernel. Spectre was a separate design weakness present in any modern processor using speculative execution, and allowed attackers to read other applications’ protected memory.
Speculative execution refers to how processors try to guess what actions programs would take, and to preemptively execute those instructions while waiting for slower tasks to complete. If the program doesn’t perform that action, the results of those instructions are trashed, but researchers have uncovered multiple methods (side-channel attacks) to access those results even though they are stored in protected memory. Modern processors adopted this feature to boost chip performance, but the fact remains that attackers can abuse the feature to trick the processor into giving up sensitive data.
Over the past decade, chip makers focused on performance when designing new microprocessors. Being able to perform calculations faster meant computers capable of handling powerful workloads. The mistake was in assuming that the information inside protected memory was safe and could not be accessed.
“Computer systems have become massively complex in pursuit of their seemingly number-one goal of performance,” the researchers wrote. “Our models, our mental models, are wrong; we have been trading security for performance and complexity all along and didn't know it. It is now a painful irony that today, defense requires even more complexity with software mitigations, most of which we know to be incomplete.”
The Google team—Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer, Toon Verwaest—built a generalized abstract model of the microarchitecture used in modern processors and found that any optimization to the architecture can be observed, making them all susceptible to side-channel attacks. The “universal read gadget” (implemented in JavaScript, C++,, and WebAssembly) running in a thread could read all memory in the same address space. For example, a webpage with malicious JavaScript code executing in the web browser thread would be able to see what another webpage’s JavaScript is doing. While major browsers have mitigations in place (Chrome has Site Isolation, and Edge and Firefox block JS object SharedArrayBuffer, for example) to stop JavaScript snooping, other applications that interpret external code would also need to implement similar mitigatitons.
There aren't many applications that interpret external code other than web browserrs, so the fact that browsers have implemented these mitigations address the immediate issues posed by Spectre and its siblings. That doesn't mean there can't be other applications, and doesn't change the fact that software is limited when it comes to addressing hardware design flaws.
Faster, Better, Power
As Spectre and related flaws have been identified, software and hardware makers have released several software updates to make timing data less accessible and make speculative execution attacks more difficult, but there are limits. Researchers have not yet found a software solution for Variant 4, Speculative Aliasing Confusion.
“Variant 4 defeats everything we could think of,” the researchers wrote.
Google experimented with disabling the speculation feature, disrupting the processor’s timer function to make it harder to perform a timing attack, and adding more safety checks to speculative execution. Spectre-defenses in Chrome’s V8 JavaScript virtual machine resulted in a significant performance penalty, but weren’t comprehensive enough. Timer mitigations shipped in previous versions of Chrome (Chrome 64 to 67) but they were only partially effective and required comprehensive code changes. Site isolation, which sandboxes code from different origins into different processes, provided more protection.
“None of these mitigations provide comprehensive protection against Spectre, and so the mitigation space is a frustrating performance / protection trade-off,” the researchers wrote.
When the initial software updates addressing Meltdown and Spectre were released, the biggest reaction came from the fact that once the updates were applied, there was a noticeable performance hit. Further work has confirmed that any attempt to add security impacted performance. The researchers argued that the trade-off wasn’t even worth it because the protections weren’t enough.
“We argue that mitigating timing channels by manipulating timers is impossible, nonsensical, and in any case ultimately self-defeating,” the researchers wrote.
While site isolation is helpful, the scientists said hardware-based separation using individual processes with their own individual virtual address spaces and hardware-enforced page tables would necessary to fully address the flaws.
The research paper echoed what Mike Davis, the principal research scientist at IOActive, said back in March. Davis said at the time that the vulnerabilities illustrated why it wasn't possible to have both performance and security. There had to be a choice, and the industry to-date had focused only on performance. An alternate approach would be to have specialized architectures appropriate for the intended workload, Davis had speculated. Servers in data centers and powerful machines that power cloud environments need performance, and would use chips that emphasized performance. TThose machines with those chips would still need extra mitigations and layers of protections to defend against side-channel attacks. For everyone else, the users whose machines don't need to be that fast, would have chips focused on security, Davis said.
The issues are part of the hardware, and affect too many different types of microprocessors that trying to update our way out of this problem makes no sense.
“This class of flaws are deeper—at the microarchitectural level of the processors—and more widely distributed—in essentially every high-performance processor—than perhaps any security flaw in history, affecting billions of CPUs in production across all device classes,” the scientists wrote.