Microarchitectural Data Sampling (MDS)

CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, and CVE-2019-11091

It was discovered that memory contents previously stored in microarchitectural buffers of an Intel CPU core may be exposed to a malicious process that is executing on the same CPU core via a speculative execution side-channel. A local attacker could access the stale contents of store buffers, load ports, and fill buffers which may contain data belonging to another process or data that originated from a different security context. As a result, unintended memory exposure can occur between userspace processes, between the kernel and userspace, between virtual machines, or between a virtual machine and the host environment.

MDS differs from other recent speculative execution side-channel attacks in that the attacker cannot target specific data. The attacker can periodically sample the contents in the buffers but does not have control over the data that is present in the buffers when the sample is taken. Therefore, additional work is required to fully collect and reconstruct the data into a meaningful data set.

Processors from other vendors are not known to be affected by MDS.

Four CVEs have been assigned to cover different variations of the data sampling flaw :

• CVE-2018-12126 for Microarchitectural Store Buffer Data Sampling (MSBDS)

• CVE-2018-12127 for Microarchitectural Load Port Data Samping (MLPDS)

• CVE-2018-12130 for Microarchitectural Fill Buffer Data Sampling (MFBDS)

• CVE-2019-11091 for Microarchitectural Data Sampling Uncacheable Memory (MDSUM)

This document will refer to the general set of data sampling flaws as MDS. The specific acronym will be used when referring to one of the individual data sampling flaws, such as MFBDS.

Mitigations

Intel has provided microcode updates which, in conjunction with updated kernels, mitigate the vulnerabilities in some situations. The underlying technique used to remediate all four issues is the same. The kernel executes a specific instruction which causes all affected microarchitectural buffers to be cleared. The kernel must execute the instruction at different times for each data sampling vulnerability. In some situations, clearing the buffers will prevent adversaries from accessing the data that was present.

The kernel and corresponding intel-microcode package updates fully address the MDS flaws if your processor does not support Hyper-Threads, also known as Symmetric Multi-Threading (SMT).

MDS is not fully mitigated if your processor supports Hyper-Threads and Hyper-Threads are enabled.

Ubuntu recommends disabling Hyper-Threads on affected systems if the system is used to execute untrusted or potentially malicious code. Some example workloads that warrant the need to disable Hyper-Threads are:

• A multi-user system with a potentially malicious user. A malicious user could leverage MDS to extract secrets from other users on the system.
• A system that runs programs which come from questionable sources. This could occur if a user on the system regularly makes use of new versions of programs that are published by an individual or group that they don't fully trust. A malicious software publisher could leverage MDS to extract secrets from the system.
• A system that hosts virtual machines from varying security domains and/or that the system owner does not fully trust. A malicious program in one virtual machine could extract secrets from other virtual machines or from the virtualization host itself.

Please see the Configuration section below for configuration details, including how to disable Hyper-Threads.

The upstream Linux kernel community is working on process scheduling improvements that may allow existing systems with Hyper-Thread support to be fully mitigated against MDS attacks. The changes are referred to as Group, or Core, scheduling. The Ubuntu kernel may support such scheduling changes in a future release.

IMPORTANT: There is no software fallback mechanism available for processors that have not received microcode updates from Intel. Mitigation is only possible if Intel has provided a microcode update for your processor.

Updates

Ubuntu users are recommended to update to the latest kernel, intel-microcode, and qemu packages. The majority of users should ensure that the following kernel packages are installed:

Users of other Ubuntu kernels should consult the Ubuntu Security Notices for specific version information.

Due to the complexity of the changes involved in mitigating this hardware vulnerability, a livepatch will not be available via the Canonical Livepatch Service.

Ubuntu users with Intel processors should ensure that the following intel-microcode packages are installed:

Ubuntu users with Intel processors that use KVM virtualization should also ensure that the following qemu packages are installed:

Ubuntu users with Intel processors that use libvirt to manage KVM virtualization should also ensure that the following libvirt packages are installed:

Configuration

MDS Configuration

MDS mitigation is enabled by default after booting the system with updated kernel and intel-microcode packages. In this configuration, MDS attacks are fully prevented if the processor does not support Hyper-Threads.

The following kernel boot option can be used to disable Hyper-Threads of affected processors. This configuration provides full mitigation on updated systems:

  mds=full,nosmt

IMPORTANT: Whilst the above is provided as a generic solution to disable Hyper-Threads, instead it is recommended to disable Hyper-Threads in your BIOS settings rather than disabling them with the kernel boot option. The processor will not need to dedicate certain resources to multiple threads within a single processor core when Hyper-Threads are disabled in the BIOS. This could result in a small performance improvement when compared to disabling Hyper-Threads in the kernel.

MDS mitigation does incur some performance overhead. You may use the following kernel boot option to disable MDS mitigations entirely:

  mds=off

IMPORTANT: Vulnerability mitigations should only be disabled in carefully controlled environments where all of the code being executed is known and trusted. Disabling any of these mitigations in situations where untrusted code can be executed is not recommended.

Please see the Linux kernel MDS Admin Guide for more information on configuration options.

General CPU Mitigation Configuration

A new boot option is included in the updated kernels that mitigate MDS. The new option allows the system administrator to configure all CPU vulnerability mitigations with a single option.

The following kernel boot option can be used to enable all mitigations and disable Hyper-Threads for processors affected by L1TF and/or MDS:

  mitigations=auto,nosmt

CPU side-channel mitigations do incure some performance overhead. You may use the following kernel boot option to disable all mitigations:

  mitigations=off

IMPORTANT: Vulnerability mitigations should only be disabled in carefully controlled environments where all of the code being executed is known and trusted. Disabling any of these mitigations in situations where untrusted code can be executed is not recommended.

Please see the Linux Kernel Parameters Admin Guide for more information on the mitigations= kernel boot option.

Configuration as a Hypervisor

QEMU/KVM

From QEMU's point of view, the md-clear CPU feature is not part of any pre-defined CPU models. On a host with the required CPU microcode to support the feature, it can be explicitly turned on to be usable by the guest.

You can check if the host system has the md-clear feature used to mitigate this issue with:

$ grep 'md_clear' /proc/cpuinfo
  flags           : ... md_clear

If the above is true then the md-clear feature will automatically be passed to the guest when using the CPU model host. For all other CPU models the feature needs to be added explicitly. For example, if before you had used the CPU model Haswell, the respective part of the command line should look like:

    -cpu Haswell,+md-clear

Libvirt

You can check your stack of Firmware, Kernel, QEMU and Libvirt is ready to expose the md-clear flag to guests by checking the capabilities.

$ virsh domcapabilities kvm | grep md-clear
    <feature policy='require' name='md-clear'/>

If the above is true then the md-clear feature will automatically be passed to the guest in the CPU modes host-passthrough and host-model.

In all other cases the definition of the CPU that is presented to the guest needs to be modified. You can do so in the guest's CPU element. While the rest of the CPU model specification depends on your use case, adding the md-clear feature is the same and will look like

<cpu ...
    <feature policy='require' name='md-clear'/>
</cpu>

IMPORTANT: Even if you have a configuration - for example using host-passthrough - that does not need a configuration change, guests needs to be fully shut down and restarted to pick up the new feature flags.

Checking System Status

Updated Ubuntu kernels have the ability to report how the system is currently affected by MDS. To check your system, read the contents of the /sys/devices/system/cpu/vulnerabilities/mds file. You must apply kernel updates and reboot if the file does not exist as that indicates that your kernel does not have mitigations in place for MDS.

Processors that aren't vulnerable to MDS will report the following:

  $ cat /sys/devices/system/cpu/vulnerabilities/mds
  Not affected

You may encounter a situation where you have an updated Ubuntu kernel but you don't have updated microcode. This could occur if you've not updated to the latest intel-microcode package or if Intel has not released new microcode for your processor. You'll see the following in this situation:

  $ cat /sys/devices/system/cpu/vulnerabilities/mds
  Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable

Processors that have Hyper-Threading support enabled will indicate that SMT is vulnerable:

  $ cat /sys/devices/system/cpu/vulnerabilities/mds
  Mitigation: Clear CPU buffers; SMT vulnerable

The file will contain the following contents for processors that do not support Intel Hyper-Threading or where Hyper-Threading has been disabled:

  $ cat /sys/devices/system/cpu/vulnerabilities/mds
  Mitigation: Clear CPU buffers; SMT disabled

The kernel is unable to reliably determine whether Hyper-Threading is enabled when running in a virtual environment. Updated host kernel packages, updated host qemu packages with proper configuration to pass through the host CPU type to the guest, and updated guest kernel packages will show the following status inside of the virtual environment:

  $ cat /sys/devices/system/cpu/vulnerabilities/mds
  Mitigation: Clear CPU buffers; SMT Host state unknown

The examples above cover the most common situations. Please see the Linux Kernel MDS Admin Guide for additional, less common situations.

References

For more information on these issues, please see the following reference documents:

• Intel Security Advisory INTEL-SA-00233

• Intel MDS Overview

• Intel MDS Deep Dive

• Intel Developer Guidance for MDS

• Intel Microcode Revision Guidance May 14, 2019 (pdf)

• Linux kernel MDS Admin Guide

• Linux kernel MDS Technical Information

Timeline

• 2019 May 14 at 17:00 UTC: the issue is made public
• 2019 May 22: updated intel-microcode packages published with additional microcodes
• 2019 June 20: updated intel-microcode packages published with mith microcode for Sandy Bridge processors