In this blog post, Oracle Linux kernel developer Konrad Wilk gives an update on the state of speculative execution vulnerabilities and mitigations in 2019.

In early 2018, researchers announced a novel mechanism to extract sensitive data from CPU cores using the processor's own speculative execution engine. These exploits are termed Speculative Execution Side Channel Vulnerabilities and were described in the meltdown.pdf and spectre.pdf papers. An additional side channel attack was released later in the year, called L1TF.

Speculative execution side channel vulnerabilities exploit a race condition in the complicated out-of-order architecture of CPUs. This post describes the state of the art mitigations for such vulnerabilities.

A Brief Review of Mitigations

First, a brief review of the existing mitigations for speculative execution side channel vulnerabilities.

The Linux mitigation for Meltdown is known as KPTI, also known as KAISER:

• Kernel page table isolation - the window of kernel code that each application has to have mapped is shrunk.

For Spectre_v2, there are two existing mitigations:

• Updated microcode and use a new Model Specific Register (MSR) opcode to frob the CPU to flush it's branch predictors. This is known as Indirect Branch Restricted Speculation (IBRS) albeit the MSR in the documentation is called SPEC_CTRL.

• A software only mitigation known as retpoline where the branch predictor is slogged through the rodeo so that its predictions are always incorrect.

Either mitigation is used on every transition to the kernel. Because they are called so often, these mitigations can have a serious impact on system performance.

The L1TF mitigations for applications are much simpler and require changes in handling applications page tables. Mitigations to run VMs also required another microcode update and usage of a new MSR.

Note that upstream Linux has not accepted IBRS mitigations - however Oracle (along with other Linux distributions) provides this support so that systems with Skylake CPUs can be mitigated. Read more about that in our blog post on retpoline.

EIBRS, you're my only hope

When this started (January of 2018), Intel added a flag which would tell the operating system whether any or some of these mitigations would be necessary.

If the CPU exposes that it is impervious to Rogue Data Cache Load (RDCL) then this CPU is not affected by L1TF and Meltdown attacks.

Great!

The Spectre_v2 story is much more complicated. Recall that there are two mitigations:

• Updated microcode and usage of a new MSR called SPEC_CTRL.

• Using retpoline - a software construct generated by the compiler.

There is a third one that is called the Enhanced Indirect Branch Restricted Speculation or EIBRS. This has only to be activated once, not on every every transition to a more privileged mode like the prior Spectre_v2 mitigations.

This means that there are now three mitigations against Spectre_v2:

• IBRS,
• Retpoline,
• EIBRS

Oracle's X8 Generation of Engineered Systems and x86 Servers

The Oracle's X8 generation of Engineered Systems and x86 servers machines are powered by a Intel Cascade Lake CPUs.

This family of CPUs are also known as EIBRS-capable and not susceptible to Rogue Data Cache Load (RDCL) attacks. Simply put, this means that the CPU is not affected by Meltdown or L1TF exploits and that it can pick the fastest of the Spectre_v2 mitigations.

The Unbreakable Enterprise Kernel (UEK) takes advantage of that and reports this using both SysFS and using the kernel ring buffers:

• Using SysFS:

$ cat /sys/devices/system/cpu/vulnerabilities/meltdown   
Not affected   
$ cat /sys/devices/system/cpu/vulnerabilities/l1tf   
Not affected   
$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2   
Mitigation: Enhanced IBRS, IBPB: conditional  

• Kernel ring buffer:

# dmesg | grep Spectre
[    0.085762] Spectre V2 : Options: IBRS(enhanced) IBPB retpoline
[    0.085763] Spectre V2 : Mitigation: Enhanced IBRS
[    0.085765] Spectre V2 : Spectre v2 mitigation: Filling RSB on context switch
[    0.085778] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier

• Or /proc/cpuinfo bugs flags:

$ cat /proc/cpuinfo | grep bugs | uniq
bugs        : spectre_v1 spectre_v2 spec_store_bypass

The spectre_v2 flag is still visible as what EIBRS offers is a hardware mechanism to squash branch prediction attacks. Folks can toggle to use retpoline or Enhanced IBRS on these CPUs. You can confirm this by looking at the kernel ring buffer output:

[    0.085762] Spectre V2 : Options: IBRS(enhanced) IBPB retpoline

The same output on X7 (Skylake) would be:

Spectre V2 : Options: IBRS(basic) IBPB retpoline

What about the Spectre v1

A keen observer might notice that the list of bugs still includes Spectre_v1. However, a mitigation is in place for this as well:

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: __user pointer sanitization

N.B. UEK4 will report lfence mitigation.

Solving Spectre_v1 attacks, also know as code gadgets, is a continuing effort.

Oracle is using an internally developed static analyzer called Parfait along with an open source static analyzer known as smatch documentation to find them and fix them as they are discovered.

The story doesn't end here, though. There is on-going research in the compiler communities to come up with a better solution to this problem. However, it is a very difficult one to solve completely.

Resources

Documentations that go in details:

• Reading privileged memory with a side-channel
• Retpoline: a software construct for preventing branch-target-injection
• Retpoline: A Branch Target Injection Mitigation
• Deep Dive: Retpoline: A Branch Target Injection Mitigation
• Speculative Execution Side Channel Mitigations v3.0
• Intel Analysis of Speculative Execution Side Channels
• SOFTWARE TECHNIQUES FOR MANAGING SPECULATION ON AMD PROCESSORS
• L1TF
• Deep Dive: Indirect Branch Restricted Speculation-a
• Linux kernel boot parameters
• L1TF - L1 Terminal Fault