Meltdown and Spectre are bugs at a fundamental level that allow critical information stored deep inside computer systems to be exposed.
Who is affected? Quite nearly everybody.
It’s not a physical problem with the CPUs themselves, or a plain software bug you might find in an application like Word or Chrome. It’s in between, at the level of the processors’ “architectures,” the way all the millions of transistors and logic units work together to carry out instructions.
In modern architectures, there are inviolable spaces where data passes through in raw, unencrypted form, such as inside the kernel, the most central software unit in the architecture, or in system memory carefully set aside from other applications. This data has powerful protections to prevent it from being interfered with or even observed by other processes and applications.
Meltdown and Spectre are two techniques researchers have discovered that circumvent those protections, exposing nearly any data the computer processes, such as passwords, proprietary information, or encrypted communications.
Meltdown affects Intel processors, and works by breaking through the barrier that prevents applications from accessing arbitrary locations in kernel memory. Segregating and protecting memory spaces prevents applications from accidentally interfering with one another’s data, or malicious software from being able to see and modify it at will. Meltdown makes this fundamental process fundamentally unreliable.
Spectre affects Intel, AMD, and ARM processors, broadening its reach to include mobile phones, embedded devices, and pretty much anything with a chip in it. Which, of course, is everything from thermostats to baby monitors now.
Spectre essentially tricks applications into accidentally disclosing information that would normally be inaccessible, safe inside their protected memory area. This is a trickier one to pull off, but because it’s based on an established practice in multiple chip architectures, it’s going to be even trickier to fix.
Chips going back to 2011 were tested and found vulnerable, and theoretically it could affect processors as far back as those released in 1995.
Because Meltdown and Spectre are flaws at the architecture level, it doesn’t matter whether a computer or device is running Windows, OS X, Android, or something else — all software platforms are equally vulnerable.
A huge variety of devices, from laptops to smartphones to servers, are therefore theoretically affected. this assumes that any untested device should be considered vulnerable.
Meltdown in particular could conceivably be applied to and across cloud platforms, where huge numbers of networked computers routinely share and transfer data among thousands or millions of users and instances.
The good news is that the attack is easiest to perform by code being run by the machine itself — it’s not easy to pull this off remotely. So there’s that, at least.
Many, many devices are “affected” or “vulnerable” to these flaws, but that’s not the same thing as saying they’re totally open to attack. Intel, AMD, ARM and others have had months to create workarounds and “mitigations,” or “band-aids” if you will.
Meltdown can be fixed essentially by building a stronger wall around the kernel; the technical term is “kernel page table isolation.” This solves the issue, but there’s a cost. Modern CPU architectures assume certain things about the way the kernel works and is accessed, and changing those things means that they won’t be able to operate at full capacity. So far, the operating systems that showed no real signs of slowing after a patch was applied has been Linux based (Android and Linux Desktops and other associated Linux operated devices).
The Meltdown fix may reduce the performance of Intel chips by as little as 5 percent or as much as 30 — but there will be some hit. Whatever it is, it’s better than the alternative.
Spectre, on the other hand, is not likely to be fully fixed any time soon. The fact is that the practice that leads to this attack being possible is so hard-wired into processors that the researchers couldn’t find any way to totally avoid it. They list a few suggestions, but conclude:
While the stop-gap countermeasures described in the previous section may help limit practical exploits in the short term, there is currently no way to know whether a particular code construction is, or is not, safe across today’s processors – much less future designs.
What will actually happen is hard to say, but there will likely be a flurry of updates that carry out various software hacks to protect against the most obvious and damaging attacks. Microsoft has already issued one for Windows; ARM has a set of mitigations for its affected chips; Amazon is updating its many servers, and so it goes.
How broadly and quickly will these mitigation patches be applied, though? How many devices are out there, vulnerable, right now? These updates may not be pretty, perhaps requiring changes that will break other software, drivers, and components. And all will likely involve degrading performance.
A more permanent fix will require significant changes across the board — the circuit board, that is. Basic architecture choices that have been baked into our devices for years, even decades, will have to be rethought. It won’t be easy, and it won’t be fun.
For now, we might do well to stay in touch with the manufacturer of whatever processor and operating system you are using in order to stay current on whatever updates or patches they will provide in the future.