Report: All Intel Processors Made in the Last Decade Might Have a Massive Security Flaw [Updated]

Photo: AP
Photo: AP

There’s small screwups and big screwups. Here is tremendously huge screwup: Virtually all Intel processors produced in the last decade have a major security hole that could allow “normal user programs—from database applications to JavaScript in web browsers—to discern to some extent the layout or contents of protected kernel memory areas,” the Register reported on Tuesday.


Essentially, modern Intel processors have a design flaw that could allow malicious programs to read protected areas of a device’s kernel memory (memory dedicated to the most essential core components of an operating system and their interactions with system hardware). This flaw could potentially expose protected information like passwords. Since the error is baked into the Intel x86-64 hardware, it requires an OS-level overwrite to patch—on every major operating system, including Windows, Linux, and macOS.

The exact details of the design flaw and to what extent users are vulnerable are being kept under wraps for now, per the Register, though since developers appear to be rushing towards patching systems in coming weeks it is likely very bad. In the absolute worst-case speculative scenario, something as simple as JavaScript running on a webpage or cloud-hosted malware could gain access to some of the most sensitive inner workings of an Intel-based device.

Because the fix entails severing kernel memory entirely from user processes, patched OSes could potentially see a massive performance hit of “five to 30 percent slowdown, depending on the task and processor model”:

These KPTI [Kernel Page Table Isolation] patches move the kernel into a completely separate address space, so it’s not just invisible to a running process, it’s not even there at all. Really, this shouldn’t be needed, but clearly there is a flaw in Intel’s silicon that allows kernel access protections to be bypassed in some way.

The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. These context switches do not happen instantly, and they force the processor to dump cached data and reload information from memory. This increases the kernel’s overhead, and slows down the computer.

Your Intel-powered machine will run slower as a result.

Five to 30 percent is a jaw-dropping number, but because of all the secrecy right now it’s difficult to tell how noticeable the impact will actually be for consumer use—enterprise-scale systems like cloud computing are likely to be the hardest hit. For the average user, it’s possible that the impact will be negligible. It’s also possible that a better implementation of the solution in future patches could reduce the performance hit.

“Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel” in redacted form, “and a similar mitigation began appearing in NT kernels in November,” the Python Sweetness blog wrote on Monday. “In the worst case the software fix causes huge slowdowns in typical workloads ... There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine.”

One problem with exploits is that even if this one is buried so deep it took ten years to find it, there’s no putting the cat back in the bag post-discovery. At the very least, the tiny slice of the market running AMD processors has some grounds to feel pleased about themselves.


Update 1/3/17 3:15 PM

Intel has released a statement regarding this vulnerability. (You can read the statement in full here.)


The most significant part is that Intel claims this vulnerability is not unique to Intel CPUs. The statement says (bold is Gizmodo’s emphasis):

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.


This would mean the flaw could be found in computers containing AMD and even Qualcomm and ARM processors. We’ve reached out to those CPU manufacturers for comment and clarification and will update when we hear back.

Update 1/3/17 4:50 PM

Intel CEO Brian Krzanich just appeared on CNBC’s closing bell where he said Intel was “notified by Google a couple months ago” about the security vulnerability. 


[The Register/Hot Hardware]



In case anyone’s wondering about the technical details of this that we can piece together from Intel’s grudging admissions... This is very non-technical, forgive me if I skip over some details that make you froth. And of course I only know what’s leaked, so hard specifics are in short supply, but I think this is generally right.

Semi-modern processors have a pipeline, where they try to fetch things from RAM and execute things ahead because RAM is much slower than the CPU. Unfortunately, ‘if x then y else z’ can really put a wrench in your pipeline, because if you fetch y and it’s really z you just ground the clutch - the entire pipeline is flushed and you start over. This is why the original Pentium 4 was such a piece of shit CPU. The speeds were entirely based on deeeeeep pipeline, but if you ever guessed wrong it grinds to a halt.

So modern processors (last decade) do what’s called ‘speculative execution’. In the case of ‘if x then y else z’ it does BOTH y and z and just uses whichever one was right. Pretty cool idea!

But... modern processors are so complex they act like an operating system. Virtual memory processes should never, ever be able to access the hypervisor (the thing that manages the VMs) RAM. User processes should never be able to access kernel RAM.

For speed reasons in Linux, MacOS, Windows, the kernel is present in every user process, like a ghost. Whenever you need to do something at system level, like handle an interrupt because your disk access finished, the user process says a prayer to the kernel which picks up and does its stuff invisibly. This stuff happens hundreds or thousands of times a second, so it pays to optimize the handoff from user to kernel to userspace. The CPU makes sure your user stuff can’t look at the kernel RAM.

Now combine these two things - when the Intel processors do speculative execution they don’t properly check the permissions so you can look at kernel memory by doing ‘if x then y else naughty_thing’ and check the page fault side effects. The way to ‘fix’ this is by taking the kernel process completely out of the user address space and/or flushing your caches after every kernel call - either way is a giant performance hit.

tl;dr It lets user processes look at kernel (and hypervisor!) memory and the ‘fix’ is to laboriously clear the caches for every single kernel call.