There can’t be any doubt about what the biggest news in tech was, so I’ll join in on discussing Meltdown and Spectre.

This will mostly serve as a way for me to get my head around what this all means and how it works, so don’t expect any new insights.

Meltdown vs Spectre

Both of these vulnerabilities were discovered last year by independent groups¹ and subsequently reported. Both Meltdown and Spectre are similar in nature, but Meltdown is mostly limited to Intel and high end ARM architectures while Spectre affects most modern architectures.

What are the attacks?

This all seems to be based around speculative execution. Speculative execution basically means that the processor will already calculate possible paths based on what it expects to happen next. Spectre and Meltdown show 3 ways in which this can be exploited. Below are short descriptions, but I highly recommend reading the Project Google Zero whitepaper about this.

First is an out of bounds issue where it becomes possible from vulnerable code to access privileged memory by using caching. The code can basically cause memory cache to be loaded by making the CPU run speculative paths over unknown array sizes (by ensuring the size of the array is not cached). The loaded data will then in turn be in the cache at a known place and retrieved. This part of Spectre is at the binary level, and therefore possible to exploitation even through JavaScript running in a browser.

The second part of Spectre involves applications polluting the branch prediction tables that are used for the speculative execution. That way the exploiting code can run the same out of bounds code as the first variant in a different application or even user level. This is therefore especially dangerous on shared hypervisors such as in virtual machines running in data centers or cloud providers where this could grant access to the memory used by other VM owners.

The last of these, Meltdown, is basically a permission check issue where the CPU will already execute the command before it has verified that the caller has permissions to do so. By the time the verification is completed, the result of the command is passed on to the next instructions which means that a possible privilege escalation has occurred, granting access to kernel level memory.

Resolutions and status

Because the researchers did a good job with disclosure and helping vendors create mitigations most systems are already patched. There is a chance of performance impact for some of these patches however, with some people claiming an up to 30% performance hit. This is likely to be highly dependent on your workload however so this might be minor or a big issue.

There are likely to be more attacks in the future that are based on Spectre however, as it is based on the hardware. The major cloud vendors at least have done a good job with rolling out their own fixes for this, with statements from AWS, Google, and Azure on how they dealt with this and where you may need to take action yourself.

LWN has a publicly available article describing the impact on the Linux Kernel, and an overview of what other OS providers and chip makers are doing can be found at Ars Technica. Additionally, aside from the whitepaper, Google’s security blog and regular blog have some more information about the vulnerabilities.