Today has not been a good day for anyone in the IT business, really. You might have caught wind of the storm that has swept up the industry that has resulted in a myriad of headlines talking about “severe” performance losses coming to Intel processors. There’s a lot of confusion about what the problem really is, how much of the processor market it affects, and how it’ll end up affecting end-users. I have answers to some of these questions, and hopefully this will help to clear up your worries. Well, it’ll help you. Not Intel or its partners much, unfortunately. That horse already bolted.
The Main Issue
In July 2017, researchers inside Google’s Project Zero security research team reached out to Intel, AMD, and other possibly affected partners with early samples and results of a vulnerability they had uncovered in just about every modern processor to date. That is, to say, that Intel, AMD, Microsoft, the Linux kernel development team, Amazon, Facebook, Google, and a host of other Fortune 500-level companies in the industry had known about this for half a year. The patches for the issues were developed in secret on the Linux kernel team, and for the past six months, there was speculation about what the patches did, what the redacted comments were all about, and why developers had to sign NDAs.
Now that the cat is out of the bag, meet two critical security vulnerabilities that have seen 2018 get off to a grand start. Meltdown and Spectre are a pair of attacks on the ways in which memory is managed on the processor, targeting Out-of-Order (OoO) and Speculative Execution respectively, in order to gain access to protected memory run and managed by the operating system kernel, or by other programs running on the system. OoO and Speculative Execution are modern features of just about every processor made after 1995, with exception to some Atom processors and Intel’s Itanium family. On-the-fly analysis by the processor’s OoO fixed-function hardware determines if workloads required by the code in future can be executed during downtime on another core or with unused CPU resources, and it is speculatively executed if that code is assumed to be trusted and possibly required by the program or current process. Multi-threading and parallel execution benefit a lot from this.
Attacking these components with code that appears trusted can allow an attacker to learn about the processor’s memory space management (also known as a page table), and allow it to view and even copy the contents of the virtual address space reserved for the kernel. For the last decade or so, operating systems have separated the page tables used by programs launched by the user from that of the kernel, primarily to stabilise things, but to also isolate and protect the kernel memory space from being examined by malicious code. The total pageable address space used in 32-bit or 64-bit operating systems is divided into virtual pools and then separated, never to mix.
Over time, this boundary has proved both useful and problematic. It keeps sensitive data locked away, but it is an additional hurdle for programs that call on contents of the kernel address space to function, like drivers and anti-virus software.
Meltdown & Spectre
Spectre is an attack on the OoO capabilities of modern processors. Without going into too much detail, it puts code in place of the trusted code that the processor expects to run from a program, and then is speculatively executed. Programs targeted by this attack then happily divulge any contents of the memory space they occupy, revealing contents from an arbitrary location. This vulnerability exists in every processor architecture designed after the Pentium MMX processor, and even affects ARM and PowerPC platforms. There’s nothing that can be done to fix it save for hardware changes, and it will remain with us for some years to come. There are ways to protect against these attacks, but the solution requires everyone in the chain, from the OS vendor, to the hardware manufacturers, to the programmers to manage their vulnerability to this attack.
Meltdown builds on Spectre’s foundations and specifically attacks the address space separation managed by the kernel, which is much more severe. Meltdown allows attackers to have their code executed without proper analysis first, and gives them a hook into the virtual memory managed by the kernel where they are able to view the contents of kernel memory. This allows them to see anything from encryption and decryption keys to usernames and passwords, hardware secrets, instructions sent to and from the secure platforms that manage random number generation, and so forth. There’s even a version of this attack that can read the operating memory and contents of virtual machines running on an affected host machine. It’s possible to spool up an Amazon virtual instance, use this attack on the processor, and get access to both the host kernel memory, as well as the contents of the other virtual address spaces used by other virtual machines.
Meltdown and Spectre have to be run on your system to work, but they can be delivered through malicious programs, trojans, rogue internet advertising, browser jacking, link hijacking, phishing emails, the works. There was, and still is, a number of ways in which to get these exploits working on your system.
The fix is already in, but…
Since July 2017, developers have been scrambling to mitigate these attacks and delayed the disclosure as long as they could to make a fix available. Anti-virus vendors started work on Spectre, training their software to look for programs that would use the exploit. The Linux Kernel team, Microsoft, Google’s Android department, and Apple all worked on mitigating Meltdown as much as possible. Today patches are available for Windows 10 machines and Linux distributions when you upgrade your kernel, and Apple will have their fixes in for MacOS and iOS very soon, as will Samsung for their Tizen operating system. IoT devices are also affected, just so you know. As if the IoT botnets of the world didn’t have enough ways to hijack your hardware and steal your data, now they have two more.
There’s only one problem. The fix for Meltdown is to simply disable the ability for software to access paged memory in the virtual address space managed by the kernel (in Linux, KPTI is a new kernel API that fixes this). This affects Intel’s processors quite heavily, in theory, and limits their ability to use Speculative Execution to gain a performance advantage for memory-heavy workloads. Depending on the workload, the range of the performance deficit as a result of this fix can be between 5% to 30% of the potential compute power assigned to it. While this doesn’t impact consumer applications that much (around 5% depending on the application, less for games), it heavily affects systems that manage databases, run websites and trading platforms, and generally anything that is intensive in terms of storage use. There’s the possibility that workstations with NVMe RAID arrays might see a drop in overall throughput in their scientific computing workloads, for example, or that API calls to the DirectX subsystem in Windows could be affected.
Anything that makes lots of system calls, references the kernel memory, or heavily relies on driver performance may see a drop in performance. One benchmark on Phoronix sees a 15% reduction in performance for the Postgre SQL benchmark. That’s just one example. CPU mining for Monero could be another, but there’s no real testing in that area at the moment. Virtual machine workloads and VM services, in general, will also see performance drops, which affects mainly things like Microsoft’s Azure services and Amazon Web Services. Consumers generally won’t see any noticeable performance deficits from these workarounds,
If there’s a silver lining to this, Windows might be considered more resilient in terms of these performance drops, because as of Windows 8.1 Microsoft made the decision to disallow drivers on Windows 8.1 and 10 to gain access to kernel memory to run in kernel mode. Issues that might stem from driver API calls and the like aren’t expected to be bogged down too much, but there is some evidence that NVIDIA’s CUDA performance is negatively affected by the changes, since GPUs also make kernel calls for general-purpose GPU workloads.
AMD and ARM are kinda immune
They are, kinda. While AMD and ARM do not make any products that can be attacked by Meltdown currently, that’s not to say they can’t be affected by something similar. Meltdown only affects Intel for now because of how aggressive the company’s use of speculative execution is, and because part of the problem lies in hardware. Given that every modern CPU architecture is affected by Spectre, every architecture is also vulnerable to an attack like Meltdown. When and where that happens is unknown at this point, and it may be the case that the patches issued for Intel won’t help to fix similar issues on other platforms.
You might see people running around cackling with glee at the thought of Intel and its stock price caving in from this point on, but that’s not likely to happen. With fixes for Meltdown already in place, the worst that can happen is that some people are affected by slowdowns in their software. The security hole is already patched and companies that use hosted virtual machines are in the clear. You’re safe. Unless someone figures out another way to implement Meltdown, this is on lockdown and under control. This isn’t going to cave Intel or their stock price. It probably won’t affect their CEO Brian Krzanich that much either, even though he’s just sold off almost all of his stock options as CEO before the disclosure. Meltdown and Spectre affected the entire software and hardware industry, not just Intel. It gives Intel’s competitors a leg up on them to sell hardware solutions to customers that aren’t affected by the bug, but that’s only a temporary advantage.
That’s it in a nutshell, really. There’s more to the disclosure around Meltdown and Spectre that is still under NDA, and everyone affected is being very careful not to make exact, conclusive statements. This might be fun to watch in the coming weeks.