The Next Vulnerability: Looking Back on Meltdown and Spectre One Year Later
This entry was posted on Wednesday, January 30th, 2019.
By Paul Kocher, Senior Technology Advisor, Rambus
Around this time last year, two vulnerabilities known as Meltdown and Spectre became public. Discovered independently by multiple research teams, each flaw exposed critical vulnerabilities across a wide range of modern processors, including ones from major chip makers Intel and AMD, as well as several designs based on the ARM architecture.
Unsurprisingly, Meltdown and Spectre gained widespread attention. While they were not the first high-profile semiconductor security flaws that affected consumers, they represented a new class of vulnerability. Spectre, in particular, arises from vulnerabilities inherent in performance optimizations that have been widely taught and deployed in high-performance microprocessors.
These vulnerabilities highlight fundamental trade-offs between performance and safety, a notion considered obvious in other industries. For example, the amount of time taken to accomplish a typical car trip, construction project, or medical procedure is routinely several times larger than could be easily achieved if safety did not matter. In contrast, today’s computers maximize efficiency, with few significant sacrifices in favor of security. Even though vastly different security/performance trade-offs might be appropriate for video gaming versus banking, the same processors have traditionally been used for both.
The industry is clearly in need of better ways to protect security-critical computations, ideally without the slowing of less sensitive performance-critical tasks. One year later, are we closer to achieving that goal?
The short answer is yes. Processor design teams are radically rethinking the relationship between hardware and software. The one-size-fits-all philosophy that has historically limited thinking for computing architectures has been replaced with excitement about tailored designs. Looking toward 2019 and beyond, we’re going to see processors that are tailored for specific requirements, including security.
Accelerating Security by Design
Historically, market dynamics presented significant challenges to innovation in hardware security. Licenses to adapt the widely-used processor architectures were either entirely unavailable or included provisions that made it legally and/or economically impractical to sell modified designs to chipmakers. At the same time, the cost of commercializing a new architecture had very high costs due to the need to develop compilers and to port operating systems and other software.
These challenges are going away as chipmakers and innovators collectively leverage open-source to develop better solutions and reduce time-to-market. The open source RISC-V architecture is particularly notable for its availability of unencumbered reference implementations and compiler/software support. As a result, RISC-V greatly reduces the amount of ancillary work required for a processor security project, allowing design teams to move more quickly and focus on areas of innovation – including security.
How will security-optimized processors be different? For example, unlike today’s performance-optimized designs, engineers can justify the inclusion of safety margins. In addition to reducing errors, these margins enable anti-tamper features to detect fault injection (glitch) attacks which push operating circuits outside their normal operating conditions. Likewise, secure cores can integrate more aggressive protections against cache attacks, differential power analysis (DPA), and other side channel attacks. Hardware designs can also help reduce the impact of software bugs, for example using capabilities-based approaches such as Capability Hardware Enhanced RISC Instructions (CHERI). Cryptographic capabilities, such as attestation and key management can be implemented much more safely than is possible on designs based on today’s gigantic high-speed CPUs.
While security improvements are needed in many aspects of computer architecture, some of the largest initial gains will come adding separate security processors onto chips. For example, instead of building a chip with 16 identical performance-optimized cores, a chip designer can integrate 15 fast cores and one security-optimized core. The software stack for the secure core(s) can also be independent from the main processor, helping reduce software-related risks as well. These heterogeneous “fast / secure” architectures side-step the difficult (and probably impossible) problem of correcting all known and unknown vulnerabilities affecting legacy designs. This isolation of sensitive cryptographic and security functions from the main CPU and operating system enables a strong root-of-trust for a wide range of applications and verticals.
While the initial panic over Meltdown and Spectre may be behind us, full hardware design cycles take several years. In addition, some mitigation strategies assume complex software upgrades that have yet to be completed. At a more basic level, there is no clear consensus as to what security guarantees should be provided by computer architectures, suggesting that security vulnerabilities involving the hardware-software interface will be a long-term headache for developers rather than a discrete task that can be completed.
We also need to set realistic expectations. The semiconductor industry’s capability to manufacture complex systems far exceeds our ability to secure them, so architects need to limit design complexity and incorporate redundancy instead of hoping that outlandishly complex designs can be made bug-free. Likewise, teams tasked with maximizing performance, manufacturing cost, power efficiency, or time-to-market will invariably find these requirements conflict with security.
Spectre also won’t be the last big hardware vulnerability. We will see new ways that malicious actors can steal information via side channel attacks, corrupt computations, crash systems, and permanently destroy devices. We’ll see hardware vulnerabilities that impact the smallest embedded systems up to entire data centers. Some problems will be fixable through software or microcode patches, while others will leave long-term vulnerabilities that result in significant liabilities and regulatory responses.
The fact that serious problems are inevitable does not mean that security efforts are futile. Quite the opposite, the choices made by hardware engineers, designers, purchasers, and regulators represent opportunities to shape the likelihood or severity of problems in the years ahead.