UPDATE | Intel hardware flaw will cause a drop in performance for kernel heavy processes once fixed

UPDATE: Intel has responded regarding this CPU kernel vulnerability (they had originally planned to make a statement once the patches were released, but media coverage has brought their response forward). They say for average users under most use cases there will be a little-to-no impact on performance (Intel reports 0-2%), in line with our stance in the original article where the effect is heavily dependent on the level of kernel/OS interaction that the process needs. When Phoronix tested synthetic I/O benchmarks, they noticed a significant performance impcat, but when Phoronix tested gaming on a patched Linux system they found no difference in performance outside of the margin of error on OpenGL/Vulkan. Results might not be comparable to DirectX on Windows.

Intel also wants to make it clear that this isn’t a design flaw, as initially reported. The Processors are working as designed, so this is a new attack vector that has come about by a design that focuses on speed. They also point out that it affects AMD and ARM processors too, although AMD has said that there is zero to near-zero risk in two of the three exploits due to the difference in the way their processors handle speculative execution when compared to Intel’s CPUs. AMD has setup a page on their website detailing the interaction with AMD processors.

Finally, Intel also says that any performance impact will be mitigated over time. They will issue their own microcode update to address the issue, presumably with less risk of impacting performance than a solution issued via the operating system. Some of these fixes will be incorporated into hardware for future processors.

--Original Article Below--

A design flaw has been identified with the way in which Intel processors made in the last ten years handle kernel memory address space, which comes into play when software needs to hand off certain jobs to the kernel. This vulnerability could allow software (including Javascript running in a browser) to read the kernel memory and see the contents of protected files, login keys, etc.

John Leyden and Chris Williams of The Register succinctly describe the process “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.”

This exploit requires an operating-system kernel-level bypass. Microsoft and Linux kernel developers are releasing patches for each respective operating system shortly (no word yet on a solution for MacOS X - Apparenty MacOS X has been patched with 10.13.2 with more to come in 10.13.3) which acts to separate the kernel and processes into separate address spaces which can’t interact directly with each other. There is a performance impact from this change, which can vary based on how much the programme needs to access the kernel, it ranges from negligible through to 20 or 30% for scenarios that involve a lot of database read/write access.

We recommend reading here for more detail of the vulnerability and speculation on the cause, or here for more detail on the software engineering behind the flaw and solution.

Tom Lendacky, from AMD replied to a Linux kernel mail that said to assume that all x86 processors were affected with the following: “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.”

This is the second time in the last few months that Intel’s processors have come under scrutiny in regards to security risks. The design of Intel’s processors was the subject of controversy when researchers found vulnerabilities in the Intel Management Engine subsystem. Intel patched these exploits which could allow a malicious user to gain full remote access as long as they had access to a single USB port beforehand.