Meltdown and Spectre: The 2018 CPU Flaws That Shook Shared Servers
In January 2018 researchers revealed Meltdown and Spectre, flaws in how modern CPUs work. See what they allow and why they matter for hosting and isolation.
Most famous security bugs live in software someone wrote badly. On 3 January 2018, the world learned of a different kind: flaws in the way modern processors are designed. Called Meltdown and Spectre, they affected chips from Intel, AMD and ARM that had been sold for many years, and they raised an uncomfortable question for anyone running software on shared machines: can one program spy on another?
Why processors guess
To run faster, modern processors do not wait to find out which instruction comes next. They guess and carry on, a technique called speculative execution. If the guess was right, time is saved. If it was wrong, the processor throws away the results and carries on down the correct path. This all happens invisibly and was thought to be safe because discarded work leaves no trace in what programs can see.
The researchers showed that it does leave a trace. Speculative work can change the contents of the processor's cache, which is a small, fast memory. A program can then measure how long certain memory accesses take, and from the timing infer what data was touched. This is called a side channel. In effect, a program could learn secrets it was never allowed to read.
The two flaws
| Meltdown | Spectre | |
|---|---|---|
| What it breaks | The barrier between user programs and the operating system's memory | The barrier between different programs, and sandboxes such as a browser |
| Chips affected | Mostly Intel processors, and some ARM and IBM designs | Intel, AMD and ARM processors |
| Ease of fixing | Software fixes in the operating system, with a performance cost | Harder; multiple mitigations and ongoing research |
Who found them
The flaws were found independently by several teams: Jann Horn of Google Project Zero, researchers at the security firm Cyberus Technology and a group at Graz University of Technology, along with the cryptography researcher Paul Kocher. They told the chip makers in 2017, and the details were coordinated for a public announcement that was brought forward from 9 January to 3 January 2018 after press reports began to appear.
Why hosting providers cared
On a shared server or in a cloud environment, many customers' programs run on the same physical processor. The operating system and the hypervisor, which divides a physical machine into virtual ones, are supposed to keep them apart. Meltdown and Spectre suggested that a malicious program could, in principle, read memory belonging to another customer or to the system itself. The practical difficulty of doing it reliably was real, but the theoretical risk meant that every provider had to respond.
Operating system vendors released updates within days. On Linux, the main fix was called kernel page-table isolation, which separates the kernel's memory from user programs more strictly. Cloud providers patched their hypervisors, and browser makers reduced the precision of timers that JavaScript could use, because Spectre could be triggered from a web page.
The performance question
The fixes were not free. Early estimates varied: some workloads saw little change, while others that make many calls into the operating system, such as heavy database or storage work, could slow down noticeably. Over time, newer processors and better software reduced the impact. Intel's first microcode updates also caused unexpected reboots on some systems and were withdrawn and replaced. This was a reminder that patches themselves need testing, and that patching quickly and patching carefully pull in different directions.
A new class of bugs
Meltdown and Spectre were not a one-off. Researchers went on to find a series of related issues, each affecting different features of processors. The lasting message was that the hardware underneath your software is also software of a kind, with bugs, and that isolation between tenants should never be treated as perfect.
What it means for different kinds of hosting
The risk is not the same for every setup. On a machine where only you run code, a side-channel attack needs a way to execute code on it first, which is already a serious compromise. The concern is greatest in environments where unrelated customers share hardware, because a hostile tenant is part of the normal threat model there. This is why providers that run shared infrastructure invest in patching quickly, and why some customers with strict requirements prefer to keep their workloads on hardware that is not shared.
It also matters for your own visitors. Spectre could be attacked through JavaScript in a web page, which is the reason browsers changed how they handle timers and memory. Keeping browsers updated, on the computers you use to run your business, is therefore part of the same defence.
The practical lesson for site owners
You cannot patch a processor yourself, but you can choose carefully who runs it. Pick a host that keeps the operating system and hypervisor up to date, apply updates to anything you manage and be cautious about what you run on a shared machine. Sensitive workloads benefit from stronger separation, for example a dedicated environment where nobody else runs code on your hardware.
A VPS gives you your own virtual server with its own operating system to keep updated, and a dedicated server gives you the whole machine. For everyday sites, shared hosting is a reasonable choice, and our security page explains the layers we use.
