Intel chips have a huge security flaw, and the fix will slow down Windows and Linux machines
A design flaw has been discovered in Intel chips that will require major changes to be made to the Windows and Linux kernels. While patches are being worked on -- and in the case of Windows Insiders, have already rolled out -- users of both operating systems can expect to experience something of a performance hit. macOS machines running on Intel chips are also affected.
Intel is -- for the moment -- remaining tight-lipped about the specifics of the flaw that has been unearthed, but it is believed to affect processors produced in the past decade. Developers are currently estimating that systems could experience slow downs of between 5 and 30 percent.
For Linux, work is underway in the open source community to patch the problem which affects the kernel's virtual memory system. Some patches have already been produced, but there's currently an embargo in place that means precise details of what's being patched are not being discussed. The embargo is due to lift this month, and there is speculation that it could come before, or coincide with, Microsoft's Patch Tuesday for January.
Although we don't know very much about the problem, we know that it is certainly something that could be exploited. The Register has been able to piece together a few snippets to give something of an overview:
The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.
Whenever a running program needs to do anything useful – such as write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes' virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel's code and data remains out of sight but present in the process's page tables.
Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.
These KPTI 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.
AMD chips are, it seems, not affected. Tom Lendacky from the chip-maker said in an email:
AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.
Disable page table isolation by default on AMD processors by not setting the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI is set.
But the impact of the flaw is going to be widespread, as noted by software developer Python Sweetness:
There is presently an embargoed security bug impacting apparently all contemporary CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. 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, and additional hints the exact attack may involve a new variant of Rowhammer.
For now, though, all we can do is sit back and wait for more details to emerge.