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.
SUSE Linux Enterprise Server 11
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
- IBM Power
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.
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
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.
The mitigation is disabled for the whole system.
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.
<feature policy='require' name='ssbd'/>
/sys/devices/system/cpu/vulnerabilities/spec_store_bypassIf this file is not present, the kernel does not support this mitigation.
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
# 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.
# 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
SLES 12 SP3
SLES 12 SP2 - LTSS
SLES 12 GA - LTSS
SLES 11 SP4
SLES 11 SP3 - LTSS
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 :
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: firstname.lastname@example.org