Ubuntu Wiki

Speculative Store Bypass (CVE-2018-3639 aka GPZ Variant 4)

Ken Johnson of the Microsoft Security Response Center (MSRC) and Jann Horn of Google Project Zero (GPZ) independently discovered another variant of a cache speculation timing side channel attack, similar to the issues previously disclosed under the names Spectre and Meltdown.

With this variant, currently known as Variant 4, systems with microprocessors utilizing speculative execution and speculative execution of a memory read, before the addresses of all prior memory writes are known, may allow unauthorized disclosure of information to an attacker with local user access via a side channel analysis. More colloquially, in one example, Variant 4 can reveal the value of stored data when a load following a store speculatively retrieves the earlier value.

Mitigations

Some mitigations for Spectre v2 also help to mitigate some of the effects of this vulnerability, for example, the reduction in timer precision in browsers renders this variant much more difficult to exploit.

The Speculative Store Bypass vulnerability can be mitigated by setting the newly defined Speculative Store Bypass Disable (SSBD) bit in the IA32_SPEC_CTRL Model-Specific Register (MSR) of x86 processors. Support for this mitigation requires updated microcode for Intel processors. New microcode is not needed for AMD processors.

In Ubuntu, SSBD is OFF by default because it is not needed by most programs and carries a notable performance impact. A prctl() has been added (PR_SPEC_STORE_BYPASS) that enables developers to opt into the mitigation on a per process basis. Applications using a seccomp filter will be implicitly opted into the mitigations. This means that strict and devmode snaps, processes inside of LXD containers, sandboxed processes of the Firefox and Chromium browsers, among some other processes running in a default Ubuntu install on x86 processors, will have the SSBD mitigation enabled out of the box.

Users can explicitly opt-in to SSBD mitigations, on a system-wide basis, by booting with the spec_store_bypass_disable=on boot parameter. See the Mitigation Controls page for details on available boot options.

Update Status

Ubuntu users are recommended to update to the latest kernel, qemu, libvirt, and intel-microcode packages. Ubuntu 18.04 LTS, 17.10, 16.04 LTS, and 14.04 LTS were affected. 12.04 ESM remains affected but updates are in progress.

Bare Metal and Virtual Machines with Intel Processors

QEMU and kernel updates were released to allow bare metal Ubuntu systems to make use of SSBD. Additionally, these updates allow virtualized Ubuntu systems to make use of SSBD with x86 Intel processors. Consult the following table for version information:

The required intel-microcode updates are not available at this time. Canonical will continue to work with Intel and release intel-microcode updates once they're production ready. In the meantime, you may be able to access updated microcode for your processor in the form of OEM firmware updates.

Virtual Machines with AMD Processors

Additional QEMU, libvirt, and kernel updates were released to allow virtual machines to make use of SSBD support with x86 AMD processors. Consult the following table for version information:

ARM64 Processors

Kernel updates were released to Ubuntu 18.04 LTS to address CVE-2018-3639 on some ARM64 processors. The updated kernels will dynamically mitigate the speculative store bypass vulnerability on Cortex-A76 and the Cavium ThunderX2 processor family with the appropriate firmware update. Consult the following table for Ubuntu kernel version information:

Verifying Your System

To check if your system is protected against CVE-2018-3639, you can run the following command and compare the output:

  $ cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
  Mitigation: Speculative Store Bypass disabled via prctl and seccomp

The example above shows a system that is mitigated against CVE-2018-3639.

A system that is not running an updated kernel will not have the file indicating the vulnerability status and the system should be considered vulnerable:

  $ cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
  cat: /sys/devices/system/cpu/vulnerabilities/spec_store_bypass: No such file or directory

If the file exists but the system does not have updated microcode, or an updated hypervisor in the case of a virtual machine, the output will indicate that the system is vulnerable:

  $ cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
  Vulnerable

Configuration as a Hypervisor

IMPORTANT: As outlined above using ssbd is not strictly required, but as a hypervisor you might want/need to leave the decision to opt into this feature to your guests. To be able to do so you need to make the ssbd feature available to them.

QEMU/KVM

From QEMUs point of view the ssbd 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 ssbd feature used to mitigate this issue with:

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

If the above is true then the ssbd 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 would then have look like:

    -cpu Haswell,+ssbd

Libvirt

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

$ virsh domcapabilities kvm | grep ssbd
    <feature policy='require' name='ssbd'/>

If the above is true then the ssbd 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 guests CPU element. While the rest of the CPU model specification depends on your case, adding the ssbd feature is the same and will look like

<cpu ...
    <feature policy='require' name='ssbd'/>
</cpu>

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

References

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

• Google Project Zero bug describing the issue

• Intel's Security Advisory

• Speculative Execution Side Channel Mitigations

• Intel Analysis of Speculative Execution Side Channels

• AMD Recommendations for Speculative Store Bypass Mitigations

Timeline

• 2018 May 21 at 21:00 UTC: the issue is made public
• 2018 May 21: Linux kernel updates are released
• 2018 May 21: QEMU updates are released
• 2018 Jun 11: Linux kernel updates are released that allow SSBD to be used in KVM based virtual machines when using an AMD processor
• 2018 Jun 12: QEMU and libvirt updates are released that allow SSBD to be used in KVM based virtual machines when using an AMD processor
• 2018 Aug 27: intel-microcde omnibus update to add SSBD and L1TF support is released
• 2018 October 1: Linux kernel updates for ARM64 SSBD support are released for 18.04 LTS and HWE 16.04 LTS.