Understanding Meltdown & Spectre: What To

Know About New Exploits That Affect Virtually

All CPUs
By: Ryan Smith

It seems only fitting that one of the two hardware based exploits to rock the CPU world this week was named
Meltdown. Because for the last 24 hours or so, it feels like I’ve been on the verge of one just trying to keep up
with all of the new information that has come out on this and the also aptly named Spectre exploit. Suffice it to
say, it’s the kind of week we haven’t seen for a long time in the technology industry. But I’m getting ahead of
myself, so let’s start at the beginning.

Security researchers working for Google’s Project Zero group, along with other research groups and academic
institutions, have discovered a series of far-ranging security risks involving speculative execution. Speculative
execution is one of the cornerstones of high-performance execution on modern CPUs, and is found in
essentially all CPU designs more performant than an embedded microcontroller. As a result, essentially every
last high-performance CPU on the market or that has been produced in the last couple of decades is vulnerable
to one or more of a few different exploit scenarios.

1
The immediate concern is an exploit being called Meltdown, which primarily affects Intel’s CPUs, but also has
been confirmed to affect some ARM CPU designs as well. With Meltdown it is possible for malicious code to
abuse Intel and ARM’s speculative execution implementations to get the processor to leak information from
other processes – particularly the all-knowing operating system kernel. As a result, Meltdown can be readily
used to spy on other processes and sneak out information that should be restricted to the kernel, other
programs, or other virtual machines.

Meanwhile a second class of attacks is being called Spectre, and the number of processors at risk for
exploitation is even wider. Essentially every high-performance processor ever made – Intel, AMD, ARM,
and POWER – is thought to be vulnerable here. Like Meltdown, a Spectre attack abuses speculative execution
in order to glean information that should be restricted. What makes Spectre different however is that it’s a less-
straightforward but much more insidious attack; whereas Meltdown is based on abusing specific
implementations of speculative execution, Spectre can be thought of as a (previously unknown) fundamental
risk of speculative execution, one that can now be weaponized. Spectre requires more setup work to coerce a
target application to leak information, but the fundamental nature of the risk means that Spectre is currently
considered harder to mitigate, and in general is not as well understood.

Between Meltdown and Spectre, the end result is that prior to patching and mitigation efforts, virtually every
PC and every mobile device is thought to be vulnerable to these attacks. And because the root causes are based
in hardware architecture rather than software, these are not as easily fixed as software bugs. The good news is

2
that it looks like the worst of these attacks can be mitigated in a combination of software and CPU microcode
updates. However the scale of the problem – virtually all computers and mobile devices currently in use –
means that it will take quite a bit of effort to mitigate.

An Early Release Leads To An Incomplete Picture

The way that the news about Meltdown and Spectre have been released was unplanned, and as a result
researchers, hardware vendors, software vendors, and the public at large have been trying to catch up on
everything that is going on. We now know that the Meltdown and Spectre attacks were discovered last
summer, and since then vendors and security researchers have been coordinating their response in order to
better understand the ramifications of the exploits and to ensure everyone had time to develop the necessary
fixes and guidance. Until yesterday, information on Meltdown and Spectre was not intended to be published
until Tuesday, January 9th, which would have been the first Patch Tuesday of the year.
Instead, what happened is that as the mitigation patches for the exploits were committed to the Linux kernel
repository, people quickly began piecing together the idea that something was wrong. With both correct and
incorrect speculation quickly taking over, the vendors moved up their information and patch releases on the
exploits to yesterday. The result, as you might expect from a premature publication, was somewhat haphazard
– I was reading new advisories well into the evening – and even now not everyone has published advisories (or
at least, not published that would be normal for full advisories).

As a result, I’m still piecing together information, and it’s likely by the time I’ve finished writing this,
something in this article will be out of date or wrong. But as of right now, this is everything we know as of this
morning.

DON’T PANIC
It is said that despite its many glaring (and occasionally fatal) inaccuracies, the Hitchhiker's Guide to the
Galaxy itself has outsold the Encyclopedia Galactica because it is slightly cheaper, and because it has the
words 'DON'T PANIC' in large, friendly letters on the cover.

Before diving into some of the deeper technical aspects of Meltdown and Spectre, I think it’s best to start with
a high level overview of where things stand. This includes the risks posed by these exploits, how they’re being
mitigated, and what individual users need to do (if anything) about the issue.

The good news is that unless you're a cloud service provider, the immediate risk from these attacks is very low.
The bad news is that because these exploits are based on hardware vulnerabilities, they will take some time to
fix. And there are a lot of devices running a lot of different OSes out there that need to be fixed.

Things We Know
These are local attacks: Both Meltdown and Spectre are local attacks that require executing malicious code
on a target machine. This means that these attacks are not (directly) drive-by style remote code execution
attacks – think Nimda or Code Red – and that systems cannot be attacked merely by being connected to a
network. Conceptually, these are closer to privilege escalation attacks, a class of attacks that help you get
deeper into a system you already have access to. With that said however, researchers have shown that they can

3
perform Spectre-based attacks using JavaScript, so it is possible for a web browser to pull a malicious
JavaScript file and then attack itself in that fashion.

These are read-only (information disclosure) attacks: Along with not directly being remotely exploitable,
even if Meltdown and Spectre attacks are executed on a local system, the nature of the exploit is that these are
read-only attacks. That is, they can only read information from a system. They cannot directly force code
execution in the OS kernel, in other virtual machines, or other programs. These sort of information disclosure
attacks can still be devastating depending on what information is leaked – and there is always the risk of using
that information to then chain it into a code execution attack – which is why they’re still concerning. But the
real risk is in hostile parties using these attacks to steal information, not to control a system.

The principal threat is to shared hosting environments: Given the above, these attacks are most threatening
to shared hosting environments, where multiple users are all capable of executing code on a single system. As
a result, cloud service providers like Amazon and Microsoft have already deployed attack mitigation efforts to
their services. Individual systems and devices, by comparison, have a much lower practical risk. An attacker
still needs to get malicious code executing on an individual system before they can run an attack; and if an
attacker can do that, then an individual system is already in a bad position to begin with.

Meltdown and Spectre can be mitigated in software: Because the root issues at the heart of Meltdown and
Spectre are at the hardware level, ideally, that hardware needs to be replaced. As replacing 20 years of systems
isn’t remotely practical however, like other CPU errata it can be mitigated in a combination of CPU microcode
and operating system updates. Vendors like Microsoft, Apple, and the Linux distros are already in the process

4
of rolling out some of these fixes, including an ultra-rare out of band security update from Microsoft
Wednesday evening.

…but it will take some time: However because information on the exploit was released earlier than planned,
not all mitigation efforts are ready. Full mitigation requires both software and microcode updates, and as Intel
has noted in their own announcements, mitigation efforts will take days and weeks.

Mitigating Meltdown will have a variable performance impact: In a nutshell, the mitigation efforts for
Meltdown involve better separating user space programs from the OS kernel. As a result, context switches
between the user space and the kernel will get more expensive. However the actual performance impact of this
process is going to vary with the workload and the CPU architecture.

It’s a bad week to be Intel: Intel has been the dominant CPU supplier for cloud service providers, whom in
turn are at the greatest risk from Meltdown and Spectre. Coupled with the fact that Intel is far more broadly
affected by the more pressing Meltdown attack than any other vendor, and this means that Intel’s high margin
server customers are shouldering the brunt of the risk of these attacks. And that in turn reflects poorly on Intel.
Meanwhile, as for what CPUs are affected, Intel's most recent note confirms that everything Core architecture-
based back to the first generation (Nehalem) is affected. Note that this doesn't exclude earlier processors either.

It’s a better week to be AMD (but not great): Conversely, AMD is having a much better week. As best as
can be determined, their CPUs aren’t vulnerable to Meltdown attacks – the only vendor among the Big 3 not to
be impacted by it. And with Meltdown being the more pressing risk, this means that AMD and its users aren’t

5
nearly as exposed as Intel users. However AMD’s CPUs are still vulnerable to Spectre attacks, and in the long
run there are still a lot of unknowns about how dangerous Spectre really is, and how well it can be mitigated.

Things We Don’t Know

When the full mitigation updates will be available for any one platform: As noted above, rolling out
updates to mitigate the exploits will take days and weeks. On the PC side of matters, Microsoft’s update is just
one piece of the puzzle – though arguably the most important one – as it can mitigate Meltdown without a
microcode update. However we’re still waiting on microcode updates to better mitigate Spectre on Intel
processors (and it looks that way for AMD processors as well).

Otherwise on the mobile side of manners, Google has announced that they’ve already rolled out Android
updates with ARM’s recommended mitigations to supported Nexus and Pixel devices, but these updates don’t
include all of the necessary upstream fixes from the Linux kernel.

The performance impact of these mitigations is unclear: Following up on the point about mitigating
Meltdown, it’s not clear what the full performance impact of this will be. Individual operations and workloads
could potentially be upwards of 30% slower, but it heavily depends on how often a task is context switching to
the kernel. I expect the average real-world impact to be less, particularly for desktop users. However server
users and their unique-but-narrowly-focused workloads could be much more affected if they're particularly
unlucky.

Meanwhile, the performance impact of Spectre mitigations is even less understood, in part because efforts to
mitigate Spectre are ongoing. Based on what the hardware vendors have published, the impact should be

6
minimal. But besides the need for empirical testing, that could change if Spectre requires more dramatic
mitigation efforts.

On our end we’re still waiting on some microcode updates, and even then it’s a process of trying to figure out
what an average case will even entail. It’s definitely something we intend to dig into in true AnandTech style
once we have the requisite updates.

Finally, for their part, Microsoft's Azure group has published their own figures in their advisory to customers,
noting that the performance impact they've found thus far is quite limited.

The majority of Azure customers should not see a noticeable performance impact with this update. We’ve
worked to optimize the CPU and disk I/O path and are not seeing noticeable performance impact after the fix
has been applied. A small set of customers may experience some networking performance impact.

It’s not clear just what the full security ramifications of Spectre are: While Meltdown is the more
immediate threat, how it works and how to mitigate it are fairly well documented. Spectre however is a
definite wildcard right now. There are multiple proof of concept attacks as it stands, but more broadly
speaking, Spectre attacks are a new class of attacks not quite like anything vendors have seen before. As a
result no one is completely confident that they understand the full security ramifications of the exploit. There is
a risk that Spectre attacks can be used for more than what’s currently understood.

It’s also not clear just how well Spectre can be mitigated: The corollary to not fully understanding the
attack surface of Spectre is that defending against it is not fully understood either. The researchers behind the
attack for their part are not convinced that software or microcode updates are enough to fully resolve the
problem, and are advising that they should be treated as stop-gap solutions for now. Specific types of Spectre
attacks can be mitigated with care, but those protections may not help against other types of Spectre attacks.
It’s an area where a lot more research needs to be done.

What Can Users Do Right Now?

Finally, there’s the question of what system and device owners should do about the Meltdown and Spectre
attacks. The fundamental weakness that allows these speculative execution attacks is in the hardware itself, so
short of replacing devices, the problem cannot be truly solved. The only thing that can be done right now is to
mitigate the problem with software and microcode patches that attempt to work-around the problem.

7
The solution then is a double-edged sword for users: there’s not much they can do, but there’s also not much
they have to do. The software and microcode updates to mitigate these exploits will be distributed as software
updates, so keeping your systems and mobile devices up-to-date with the latest OS version is the single
most important step one can take. As mentioned earlier, everyone has or is in the process of rolling out the
necessary software updates to help mitigate this. The flip side is that, short of a focused ion beam tool, there’s
not much else for users to do. This is a problem whose resolution is going to be vendor-driven.

More to Come
Be sure to check back later today for some additional information on these attacks. In particular, I’m looking to
further explore the importance of speculative execution, and why an attack against it may have some
significant ramifications for CPU designs down the line. Speculative execution is a rather important feature for
boosting performance on modern processors, but as these attacks have shown, even when (seemingly) ideally
implemented, it can have some security tradeoffs. Which in this current era of computing, may no longer be
acceptable tradeoffs.

I’ll also be taking a deeper look at Meltdown and Spectre, and how although both of them are attacks on
speculative execution, they are very different kinds of attacks. Meltdown is the biggest concern right now due
to its relative ease in exploiting it. But as the authors of the Spectre paper note, Spectre is a more fundamental
vulnerability that will be with us a lot longer. Just what it means for system security remains to be seen, but
from a computer science point of view, I expect these latest discoveries are going to have a big impact on how
future CPUs are designed.

8
About AnandTech
There's a spectrum of coverage when it comes to any product or technology. Go too far to
one side and you end up with superficial content that's hardly better than a press release.
End up too far on the opposite side however and you end up with an article that either takes
too long to produce or isn't accessible to the majority of readers. Our goal is to end up
somewhere in between, erring on the side of being extremely thorough wherever possible.

Our reviews incorporate a mixture of objective and subjective based analysis, the balance
varying where appropriate. We are not a site that exclusively relies on data based
comparisons but also deliver honest user experience evaluations as well. Some reviews
lend themselves to data driven analysis more than others (e.g. CPU review vs. smartphone
review), but we always attempt to provide both in our coverage.

We fundamentally believe that you need both to accurately portray any product. Numbers
are great for comparative analysis, but without context they can be meaningless. Similarly,
personal opinions are great to help explain what owning a product may be like, but without
data to back up some claims the review lacks authority (e.g. average vs. good battery life
begs to be quantified).

To learn more about us, visit our website: www.anandtech.com