Meltdown And Spectre, One Year Later

About this time last year, reports surfaced about security attacks on today’s most popular microprocessors (μPs). Researchers called them Meltdown, Spectre gaining widespread attention. Today, however, the industry and especially μP vendors have made some progress toward stemming these vulnerabilities. Here is my analysis as we enter into 2019.

When it comes to these vulnerabilities, we have to remember that we’re not dealing with the usual software bug where everybody recognizes it, somebody discloses it, somebody goes and fixes a line of code, and then finally, somebody pushes an update and you’re done. Having said that, there are certainly some initiatives that are gaining momentum. One involves the open-source work in hardware that now includes MIPS, which will be open-sourcing its architecture. In a way, that reflects off the RISC-V architecture, which has been open source from the beginning.

From another front, there is an increasing amount of research and academic attention being paid to hardware. To a significant degree, this reflects the fact that we’re considerably more dependent on hardware being right from the beginning than we are with software.

But the question remains: Has the industry become better at finding vulnerabilities over this past year? My take is that it’s going to take longer than a year for us to know whether some of the important lessons were learned or not. However, let’s give some credit where credit is due. Leading μP vendors are adding new security features as critical parts of their product roadmaps. Mitigations for side channel vulnerabilities are a significant part of those roadmaps.

It’s also worth noting that, to date, we’ve seen a range of different Spectre variations published. We’ve also seen a variety of other interesting hardware-related first results. But one must keep in mind that these “first results” take a number of years to materialize. That period spans from when the academic and research focus sets a direction on first results to the time when you start seeing a number of those results getting published.

As far as predicting where the next vulnerability or flaw is waiting to strike, we need to revisit an old traditional model. It’s that model where you think about security in terms of confidentiality, integrity, and availability (CIA). In that vein, an area attacker historically operates around systems that are temporarily or permanently unavailable.

An area creating anxiety for me is a number of vulnerabilities that haven’t yet been publicized. These are around software techniques that have a damaging effect to the hardware. This issue that destroys hardware in a cloud computing environment is quite serious. With computations increasingly going into the cloud, damage to the hardware and data centers we depend on to perform those critical computations start to become a much more frightening prospect than individual failures occurring in an uncoordinated manner.

To conclude, there are considerable factors that need to be defined and clarified about that contract between hardware and software. Longer term, one of the most important areas of research and development work that’s active right now is to come up with μP architectures and computing environments with sufficiently well-defined security properties. And within these μP architectures and computing environments, it’s practical for software to be implemented that can achieve security objectives.

Related Stories
Tech Talk: HW Security
How to minimize the risk of hardware attacks in the shadow of Meltdown and Spectre.
Finding Security Holes In Hardware
Emphasis on performance, backward compatibility and system complexity are creating vulnerabilities that are difficult to fix.
Building Security Into RISC-V Systems
Experts at the Table, part 2: Emphasis shifting to firmware, system-level architectures, and collaboration between industry, academia and government.
Open-Source RISC-V Hardware And Security
Experts at the Table, Part 1: The advantages and limitations of a new instruction set architecture.
Blockchain May Be Overkill For Most IIoT Security
Without an efficient blockchain template for IoT, other options are better.