Update 1/3/2018 2:20 PM: Intel has issued a statement regarding this potential vulnerability. The company claims its CPUs are not uniquely affected by the root cause that has provoked the changes to the virtual memory layouts in common operating systems, that reports attributing this issue to a "bug" or a "flaw" in Intel CPUs are incorrect, and that it is working with ARM, AMD, and operating system vendors to "develop an industry-wide approach to resolve this issue promptly and constructively." Intel's statements would appear to directly contradict statements from AMD employees regarding the nature of this potential vulnerability, so we await further details of the security issue to be disclosed next week. The original post continues below.
Like many TR readers, we are following news regarding a potential hardware-level security flaw in a range of Intel CPUs. Absent an official statement from Intel or operating system vendors, however, we are holding off on attempting a detailed report on this issue or issues because the cart seems to have gotten in front of the horse on what exactly is going on and the people in the know may be bound by a non-disclosure agreement.
What we do know from initial reports around this vulnerability is that a series of Linux kernel patches to implement kernel page table isolation (KPTI) are in the works. The goal of KPTI is to segregate user and kernel memory mappings in virtual address space in order to prevent a number of side-channel attacks on x86 systems that can potentially break kernel address-space layout randomization (KASLR). KASLR is a method of preventing attackers from being able to reliably pinpoint the locations of core operating system information in memory.
According to the paper that inspired this change, both kernel and user memory mappings currently sit alongside each other in virtual address space for a given process to improve performance. This approach is used in all x86 operating systems, not just Linux, according to Ars Technica's excellent write-up on this subject, and it's apparently fundamental to getting the best performance out of x86 CPUs because of the limited space available in those chips' translation lookaside buffers (or TLBs).
With the new layout, processes will only have the minimum number of kernel addresses mapped that are necessary in order to facilitate context switches between user and kernel memory during execution. As a result, this group of patches is claimed to have anywhere from a 5% to a 30% impact on Linux performance, depending on the number of system calls a given process needs to make in order to function. That's because the CPU's translation lookaside buffer will now need to cache the kernel's memory mapping upon every switch from user to kernel address spaces (and vice versa) instead of being able to rely on its presence alongside every user process. System calls might include I/O requests or file operations, to name just a couple such privileged functions.
In the process of developing a mitigation for these side-channel attacks, our best guess is that a hardware bug in Intel CPUs was uncovered somewhere along the line. The severity of the bug appears to stem from the way Intel CPUs in particular handle speculative execution. Although no details of this apparent hardware vulnerability are publicly available yet (and would presumably be the information protected by any NDA that exists, in order to prevent exploitation), it appears that user code can be crafted in such a manner that the CPU can be coerced into leaking data from kernel memory.
That exploit would break the fundamental security model of CPUs by allowing user code (at ring 3) to extract the contents of memory that should only be accessible to the kernel (at ring 0). That information could include encryption keys, passwords, or perhaps even information in other virtualized operating systems running on the same CPU.
An AMD contributor to the Linux kernel may have inadvertently tipped off the nature of this hardware hole by arguing that AMD CPUs don't allow less-privileged code to perform even speculative memory accesses to more privileged memory locations when those accesses would result in a page fault—a key element of some of the side-channel attacks that KPTI is meant to prevent.
Linux is not the only operating system that is implementing changes in an apparent response to this vulnerability. Developer Alex Ionescu has pointed out changes in the Windows and macOS kernels on Twitter that suggest a similar memory model is or will be implemented in those operating systems. Planned updates for Microsoft's Azure cloud infrastructure around the impending Patch Tuesday could mark a natural time for the NDA around this bug to lift. We'll be keeping our eyes open for further updates on this issue from Intel or other vendors.