QEMU-Vulneratilibites_and_Mitigations

You should read this!
This is deeper information, you may ignore.
This is a CPU vulnerability!
This is a mitigation technique.
This is a CPU flag to advertise Kernel and/or Hypervisor.

Notes:

Sometimes the mitigation name is the acronym for the CPU flag, example: Indirect Branch Prediction Barrier - ibpb. And sometimes some CPU flag might mitigate more than 1 vulnerability.
Downloading the HTML from the wiki (through the proper Download link at the top) and opening it locally will make it better for reading (no CSS themes). You can also print it to PDF if you'd like.

Also, do check articles dates and look for newer ones not yet updated in this document. Newer side channel attack techniques might have been discovered by the time this page was created. If you feel this page should be updated, please send us an e-mail at: ubuntu-server@lists.ubuntu.com mentioning what should be updated and why.

Related CPU Vulnerabilities (CVEs)

Side Channel Attacks - Spectre and Meltdown

Side Channel Attacks - Others

L1 Terminal Fault (L1TF)

Microarchitectural Data Sampling (MDS)

This CVE topic structure is used in the same order in all subsequent sections of this document.
The idea is to allow reader to map:

CPU Vulnerability

<->

Firmware/Kernel/OS Mitigation

<->

CPU Flags to Guest

CPU Vulnerabilities, HW / Firmware, Kernel and OS Mitigations

Side Channel Attacks - Spectre and Meltdown

CVE-2017-5753 - Bounds Check Bypass (Variant 1 / Spectre)
_user pointer sanitization
To mitigate this exploit technique in the Linux kernel, we first identify instruction sequences that can be tricked into exploitable behavior. Since a sequence must fit a specific pattern and operate on untrusted data before any potential exploit, not all conditional branches are exploitable. Techniques such as static analysis or manual inspection can identify these sequences.
CVE-2017-5715 - Branch Target Injection (Variant 2 / Spectre)

The branch target injection exploit targets a processor’s 'indirect branch predictor'. Indirect branches are used very differently than the conditional branches that the first exploit may target. In Linux, indirect branches are used relatively rarely compared to conditional branches, but they are used in critical locations. In addition, the compiler may insert indirect branches without the programmer ever being aware.

Since the compiler generates these branches, mitigation against this exploit is the most straightforward when the compiler can simply avoid generating vulnerable branch sequences. A software construct called retpoline can be deployed to help ensure that a given indirect branch is resistant to exploitation. The compiler, automatically, or the programmer, manually, can insert the retpoline logic in binary code. Retpoline deliberately steer the processor’s branch prediction logic to a trusted location, preventing a potential exploit from steering them elsewhere.

OS and Kernel Mitigation: Retpoline
Retpoline needs code (kernel and/or userland) to be recompiled by a compiler with this feature enabled. If not using retpoline, firmware microcode might ALSO mitigate against Spectre Variant 2 on several different platforms.

Firmware Mitigations
for Spectre Variant 2 are also provided by different CPU microcodes. Taking amd64 by example, there are MORE THAN 1 mitigation included in more recent microcodes AND about to (or being, or recently done) be included in newer CPUs internal logic.

Enhanced Indirect Branch Restricted Speculation (IBRS): Restricts speculation of indirect branches
With enhanced IBRS, the predicted targets of indirect branches executed cannot be controlled by software that was executed in a less privileged predictor mode or on another logical processor. As a result, software operating on a processor with enhanced IBRS need not use WRMSR to set IA32_SPEC_CTRL.IBRS after every transition to a more privileged predictor mode. Software can isolate predictor modes effectively simply by setting the bit once.

Single Thread Indirect Branch Predictors (STIBP): Prevents indirect branch predictions from being controlled by the sibling HW thread
STIBP is an indirect branch control mechanism that restricts the sharing of branch prediction between logical processors on a core. ... as the logical processors sharing a core may share indirect branch predictors, allowing one logical processor to control the predicted targets of indirect branches by another logical processor of the same core.

Enabling IBRS prevents software operating on one logical processor from controlling the predicted targets of indirect branches executed on another logical processor. For that reason, it is not necessary to enable STIBP when IBRS is enabled.

Indirect Branch Predictor Barrier (IBPB): Ensures earlier code's behavior does not control later indirect branch predictions. Complements Enhanced IBRS
IBPB is an indirect branch control mechanism that establishes a barrier, preventing software that executed before the barrier from controlling the predicted targets of indirect branches executed after the barrier on the same logical processor. A processor supports IBPB if it enumerates CPUID.(EAX=7H,ECX=0):EDX[26] as 1.

IBPB does not define a new mode of processor operation that controls the branch predictors, unlike Indirect Branch Restricted Speculation (IBRS) and Single Thread Indirect Branch Predictors (STIBP). As a result, it is not enabled by setting a bit in the IA32_SPEC_CTRL MSR. Instead, IBPB is a “command” that software executes when necessary.
CVE-2017-5754 - Rogue Data Cache Load (Variant 3 / Meltdown)

The rogue data cache load exploit targets a processor’s speculative data loading mechanisms. Even though the processor’s access control may protect a piece of data, it may still be read speculatively before an illegal access is determined to exist. The first two exploits require manipulating the kernel to do something for an attacker, while this exploit occurs entirely within code which is under the control of an attacker. This means we cannot modify the kernel to mitigate this exploit, we must fundamentally change where kernel data is available.
Kernel Mitigation: Kernel Page Table Isolation
The mitigation for this is conceptually very simple: instead of relying on a processor’s access-control mechanisms to protect data, simply remove the data instead.

In Linux, this mitigation is referred to as Kernel Page Table Isolation (PTI). This mitigation removes the data from the reach of exploits by having the kernel maintain two independent copies of the hardware page tables. One copy contains the minimal set of data and code needed to run an application and enter or exit the kernel, but it does not contain valuable kernel data. The other set of page tables, active only while the kernel is running, contains everything needed for the kernel to function normally, including its private data.

Side Channel Attacks - Others

L1 Terminal Fault (L1TF)

Microarchitectural Data Sampling (MDS)

QEMU/KVM ONLY - Mitigations and CPU Flags

Spectre and Meltdown mitigation detection tool

Ubuntu Wiki

QEMU-Vulneratilibites_and_Mitigations

Introduction

Related CPU Vulnerabilities (CVEs)

CPU Vulnerabilities, HW / Firmware, Kernel and OS Mitigations

QEMU/KVM ONLY - Mitigations and CPU Flags

Spectre and Meltdown mitigation detection tool