Meltdown

Meltdown [6] breaks the security barriers between userspace programs and the kernel. A process prepared by the attacker can cause the CPU to speculatively load data and then access the kernel area directly by levering out access control – for example, using untrusted JavaScript code executed via a web browser.

The problem is that many CPUs do not check access rights when accessing memory during speculative execution. Attackers can therefore load data into the cache that should not actually be accessible. There is no direct way to read the data from the cache; however, differences in the execution times of data in the cache and out of it can be used to read individual bits in memory. By repeating the procedure, malicious code can read the memory at a rate of up to 1.5KBps – fast enough to access passwords and other security-relevant data stored there.

To prevent this attack, the developers of Kernel 4.15 and higher separate the page tables formerly shared by the kernel and user space into two completely separate sets. Thanks to kernel page table isolation (KPTI), after you apply the appropriate patches, a process can only see the memory area assigned to it; no longer can it see the memory of the operating system kernel [7]. This restriction prevents an unprivileged process from accessing the kernel space memory area.

AMD in Luck

The Meltdown gap has plagued almost all Intel processors since 1995, with the exception of the Itanium architecture, the Atom processors produced before 2013, and some ARM64 chips based on the Cortex A75. AMD CPUs, on the other hand, are not affected by Meltdown. The Linux kernel already benefited from Meltdown patches at the end of the year, so that protection has existed as of Linux 4.15-rc7, from January 6.

The developers then backported the fix to the LTS 4.4 and 4.9 kernels, as well as Linux 4.14.12; Kernel 4.16 protects affected ARM64 CPUs and the s390 port for Linux on IBMs Z-systems and LinuxONE servers. The 3.18, 4.4, and 4.9 branches of the Android Common Kernel were patched. Kernel 4.15 offers fundamental protection against Meltdown, although it is still vulnerable to Spectre v1 (Figure 3). Kernel 4.15.4 from February 16 closes the Spectre v1 vulnerability (Figure 4). This is by no means the end, as 4.17 and beyond will further stabilize and expand the existing patches.

Figure 3: The Spectre and Meltdown mitigation and detection tool shows Spectre v1 as a vulnerability with Kernel 4.15.0. Meltdown and Spectre v2 are closed.

Figure 4: With Kernel 4.16, the Spectre v1 vulnerability is now mitigated. The patches will be further expanded and cleaned up with 4.17.

Spectre

Defensive measures against Spectre [8] cause considerably more work than defenses that target Meltdown. Spectre also affects AMD processors and the PowerPC platform. Initial patches for Spectre v2 were available in kernel 4.15; they are successively extended and perfected in Kernel 4.16.

The two variants of the Spectre vulnerability can only be prevented by the interaction of a patched kernel, an adapted compiler, and microcode from Intel or AMD. In addition, many thousands of applications have to be patched separately; Firefox 57.0.4, Chrome 64, and other web browsers already have updates.

Linux uses a software construct from Google to combat Spectre, which the developers named Retpoline ("Return Trampoline") [9]. This fix allows indirect branches to be excluded from speculative execution via an endless loop. Retpoline needs an adapted compiler, which is now available in the form of GCC 7.3.

At the same time, Intel released new microcode to contain Spectre v2 with the Indirect Branch Prediction Barrier (IBPB), Single Thread Indirect Branch Predictors (STIBP), and Indirect Branch Restricted Speculation (IBRS) measures. These changes are what unleashed Linus Torvalds' criticism. He expressed the opinion that the changes were "absolute rubbish" and a "dirty hack" that would result in severe performance loss. Intel indirectly proved him right by hastily withdrawing the microcode and discouraging its use. The updates led to crashes and spontaneous reboots on Broadwell and Haswell CPUs.

The kernel community, on the other hand, relies on Google's Retpoline fix, which does not compromise performance. The only potential addition to the Linux kernel fix is Intel's IBPB, which serves as a barrier for context changes to prevent the CPU from reusing already known branch targets. However, before the kernel community can integrate IBPB, CPU manufacturers must first make revised microcode available.

The last of the three vulnerabilities the kernel developers need to patch is Spectre v1. On February 4, the first basic patches designed to contain Spectre v1 were submitted; they have already been included in Kernel 4.15.4. Further improvements will follow for kernel 4.16, expected at the beginning of April, and later kernel versions. These code patches affect both the x86 platform and ARM64.