Security Vulnerability: Spectre Variant 4 (Speculative Store Bypass) aka CVE-2018-3639
This document (7022937) is provided subject to the disclaimer at the end of this document.
Environment
SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 11
SUSE Linux Enterprise Server 11
Situation
A new variant of information leakage due to speculative execution was found by the Google Project Zero team.
If data store instructions are followed by another storage to the same address and a later read, the speculation of this later read could still speculatively operate on the first stored value, leaking this information to local attackers.
A common pattern where this happens would be leaks out of zeroed cryptographic material storage.
The issue happens due to a so called "Memory Disambiguation" CPU feature, where loads and stores are executed out-of-order with the purpose of increasing instruction-level parallelism in modern out-of-order cores.
The following CPU architectures are known to be affected by this problem:
If data store instructions are followed by another storage to the same address and a later read, the speculation of this later read could still speculatively operate on the first stored value, leaking this information to local attackers.
A common pattern where this happens would be leaks out of zeroed cryptographic material storage.
The issue happens due to a so called "Memory Disambiguation" CPU feature, where loads and stores are executed out-of-order with the purpose of increasing instruction-level parallelism in modern out-of-order cores.
The following CPU architectures are known to be affected by this problem:
- Intel and AMD x86
- ARM
- IBM Power
Resolution
The mitigating solution is to disable the "Memory Disambiguation" feature in the processor, either system-wide or selectively for single processes.
Mitigations need to be implemented for the Linux Kernel and for Hypervisors, both for passing through new CPU flags and MSR registers (on x86) and supporting of switching off/on the mitigation.
The updated SUSE kernel default is currently "seccomp" mode.
Per Process/Thread view:
If the mitigation is not globally enabled, it can be selectively enabled per process, either by using heuristics like seccomp() or setting explicitly via prctl(PR_SET_SPECULATION_CTRL,PR_SPEC_DISABLE) in the thread.
Every process/thread reports its own mitigation status, via
/proc/PID/status
Possible entries:
Speculation_Store_Bypass: not vulnerable
The processor is not vulnerable.
Speculation_Store_Bypass: thread force mitigated
Speculation_Store_Bypass: thread mitigated
Speculation_Store_Bypass: globally mitigated
The mitigation is enabled by either prctl/seccomp forcing or kernel commandline option "on".
Speculation_Store_Bypass: thread vulnerable
The mitigation is not enabled for this process/thread, it can be enabled when the process uses seccomp or prctl, or by force enabling it on the kernel bootline for all processes.
Speculation_Store_Bypass: vulnerable
The mitigation is disabled for the whole system.
The state of the mitigation can be seen in :
SLES 12 SP3
SLES 12 SP2 - LTSS
On Intel x86 systems, updated CPU microcode is required to enable this mitigation. This microcode is either supplied by your hardware / BIOS vendor or by SUSE using the official Intel released microcode packages.
Note :The minimum required Intel microcode base-level for this mitigation is the Intel 20180807 release (across all versions of SLES).
Mitigations need to be implemented for the Linux Kernel and for Hypervisors, both for passing through new CPU flags and MSR registers (on x86) and supporting of switching off/on the mitigation.
For the Linux kernel, on both bare metal and virtual machines, it can be enabled / disabled using the kernel boot command line and/or with a thread-specific prctl() system call.
Kernel boot options :
spec_store_bypass_disable=autoThe mitigation is enabled by default when needed, prctl() is enabled for a per-process selection, and "seccomp" users are also enabled.
spec_store_bypass_disable=seccompThe mitigation is by default disabled, and can be enabled by user programs using the prctl() system call, and is default enabled for applications using "seccomp" filtering, like openssh, vsftpd and chromium.
nospec_store_bypass_disable and spec_store_bypass_disable=offThe mitigation is disabled.
spec_store_bypass_disable=onThe mitigation is enabled by default system-wide.
spec_store_bypass_disable=prctlThe mitigation is by default disabled, and can be enabled by user programs using the prctl() system call.
The updated SUSE kernel default is currently "seccomp" mode.
Per Process/Thread view:
If the mitigation is not globally enabled, it can be selectively enabled per process, either by using heuristics like seccomp() or setting explicitly via prctl(PR_SET_SPECULATION_CTRL,PR_SPEC_DISABLE) in the thread.
Every process/thread reports its own mitigation status, via
/proc/PID/status
Possible entries:
Speculation_Store_Bypass: not vulnerable
The processor is not vulnerable.
Speculation_Store_Bypass: thread force mitigated
Speculation_Store_Bypass: thread mitigated
Speculation_Store_Bypass: globally mitigated
The mitigation is enabled by either prctl/seccomp forcing or kernel commandline option "on".
Speculation_Store_Bypass: thread vulnerable
The mitigation is not enabled for this process/thread, it can be enabled when the process uses seccomp or prctl, or by force enabling it on the kernel bootline for all processes.
Speculation_Store_Bypass: vulnerable
The mitigation is disabled for the whole system.
For the Xen hypervisor, system-wide mitigation is disabled by default, but can be enabled using the following Xen hypervisor boot parameter :
spec-ctrl=ssbd
The mitigation at the hypervisor level is enabled, and the speculative store bypass is disabled on a system-wide level.
In this mode, mitigation is enforced for all guests.
Regardless of the hypervisor setting, Xen automatically provides the “SSBD” feature to PV and HVM guests. (Intel environments require an updated microcode). Guest user processes can then use the prctl() system call and “seccomp” filtering to provide mitigation, or tune the mitigation with the parameters available to bare-metal environments.
KVM environments are identical to bare-metal environments, with one exception. KVM guests do not automatically see the “SSBD” feature of Intel hosts using updated microcode. In order for a KVM guests to be able to use SSBD features, the guest’s CPU definition has to have the SSBD feature explicitly enabled, as in the following libvirt definition:
Regardless of the hypervisor setting, Xen automatically provides the “SSBD” feature to PV and HVM guests. (Intel environments require an updated microcode). Guest user processes can then use the prctl() system call and “seccomp” filtering to provide mitigation, or tune the mitigation with the parameters available to bare-metal environments.
KVM environments are identical to bare-metal environments, with one exception. KVM guests do not automatically see the “SSBD” feature of Intel hosts using updated microcode. In order for a KVM guests to be able to use SSBD features, the guest’s CPU definition has to have the SSBD feature explicitly enabled, as in the following libvirt definition:
<cpu mode='custom' match='exact' check='full'>Once enabled, mitigation within the guest is identical to bare-metal. User processes can use the prctl() system call and “seccomp” filtering, or system wide mitigation can be turned on with a kernel parameter.
<model fallback='forbid'>Skylake-Server-IBRS</model>
<feature policy='require' name='ssbd'/>
</cpu>
/sys/devices/system/cpu/vulnerabilities/spec_store_bypassIf this file is not present, the kernel does not support this mitigation.
Potential values here are :
Not affectedThe processor is not affected by this problem.
VulnerableThe processor is vulnerable.
Mitigation: Speculative Store Bypass disabledThe processor is vulnerable and the mitigation is enabled by default.
Mitigation: Speculative Store Bypass disabled via prctlThe processor is vulnerable and the mitigation needs to be enabled by using prctl().
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
The processor is vulnerable and the mitigation needs to be enabled by using prctl() or seccomp().
In Xen environments, the state of mitigation at the hypervisor level can be seen using :
# xl dmesg | grep -A5 SpeculativeIn the “Xen settings” line, the state of SSBD support is indicated as enabled using a plus (+) sign, or disabled using a minus (-) sign.
For example, the following output shows SSBD support enabled at the hypervisor level:
# xl dmesg | grep -A5 Speculative
(XEN) Speculative mitigation facilities:
(XEN) Hardware features: IBRS/IBPB STIBP SSBD
(XEN) Compiled-in support: INDIRECT_THUNK
(XEN) Xen settings: BTI-Thunk JMP, SPEC_CTRL: IBRS+ SSBD+, Other: IBPB
(XEN) Support for VMs: PV: MSR_SPEC_CTRL RSB, HVM: MSR_SPEC_CTRL RSB
(XEN) XPTI (64-bit PV only): Dom0 enabled, DomU enabled
KVM and Xen guest level mitigation matches that of the Linux kernel, and can be viewed through the sysfs interface (/sys/devices/system/cpu/vulnerabilities/spec_store_bypass).
SUSE has released updates to address this vulnerability in the following package versions :
SLES 12 SP3
- kernel-4.4.131-94.29.1
- qemu-2.9.1-6.16.1
- xen-4.9.2_06-3.32.1
SLES 12 SP2 - LTSS
- kernel-4.4.121-92.80.1
- libvirt-2.0.0-27.42.1
- qemu-2.6.2-41.40.1
- xen-4.7.5_04-43.33.1
SLES 12 SP1 - LTSS
SLES 12 GA - LTSS
SLES 11 SP4
SLES 11 SP3 - LTSS
- kernel-3.12.74-60.64.93.1
- qemu-2.3.1-33.9.4
- xen-4.5.5_24-22.49.1
SLES 12 GA - LTSS
- kernel-3.12.61-52.133.1
- qemu-2.0.2-48.40.2
- xen-4.4.4_32-22.68.1
SLES 11 SP4
- kernel-3.0.101-108.48.1
- kvm-1.4.2-60.12.1
- libvirt-1.2.5-23.15.1
- xen-4.4.4_32-61.29.2
SLES 11 SP3 - LTSS
- kernel-3.0.101-0.47.106.29.1
- kvm-1.4.2-53.20.1
- libvirt-1.0.5.9-21.9.1
Cause
Additional Information
Performance notes :
As Memory Disambiguation is a performance optimization in modern processors, disabling it to mitigate the security issue will cause a variable performance loss.
Contrary to the older Spectre variants and Meltdown, this performance loss is not dependent on the system call load. The "prctl" method can be used to only selectively enable the mitigation for processes that might operate sand-boxed malicious code, like web browsers or other just-in-time compiling run-times.
Related articles :
As Memory Disambiguation is a performance optimization in modern processors, disabling it to mitigate the security issue will cause a variable performance loss.
Contrary to the older Spectre variants and Meltdown, this performance loss is not dependent on the system call load. The "prctl" method can be used to only selectively enable the mitigation for processes that might operate sand-boxed malicious code, like web browsers or other just-in-time compiling run-times.
Related articles :
- TID 7022512 : Security Vulnerability: "Meltdown" and "Spectre" side channel attacks against CPUs with speculative execution.
- TID 7022514 : Security Vulnerability: "Meltdown" and "Spectre" - Hypervisor Information.
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:7022937
- Creation Date: 09-May-2018
- Modified Date:30-Mar-2022
-
- SUSE Linux Enterprise Server
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
