Loading Documentation/ABI/testing/sysfs-devices-system-cpu +6 −5 Original line number Diff line number Diff line Loading @@ -472,16 +472,17 @@ Description: information about CPUs heterogeneity. cpu_capacity: capacity of cpu#. What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/gather_data_sampling /sys/devices/system/cpu/vulnerabilities/itlb_multihit /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds /sys/devices/system/cpu/vulnerabilities/meltdown /sys/devices/system/cpu/vulnerabilities/mmio_stale_data /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/spectre_v1 /sys/devices/system/cpu/vulnerabilities/spectre_v2 /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit /sys/devices/system/cpu/vulnerabilities/mmio_stale_data Date: January 2018 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: Information about CPU vulnerabilities Loading Documentation/admin-guide/hw-vuln/gather_data_sampling.rst 0 → 100644 +109 −0 Original line number Diff line number Diff line .. SPDX-License-Identifier: GPL-2.0 GDS - Gather Data Sampling ========================== Gather Data Sampling is a hardware vulnerability which allows unprivileged speculative access to data which was previously stored in vector registers. Problem ------- When a gather instruction performs loads from memory, different data elements are merged into the destination vector register. However, when a gather instruction that is transiently executed encounters a fault, stale data from architectural or internal vector registers may get transiently forwarded to the destination vector register instead. This will allow a malicious attacker to infer stale data using typical side channel techniques like cache timing attacks. GDS is a purely sampling-based attack. The attacker uses gather instructions to infer the stale vector register data. The victim does not need to do anything special other than use the vector registers. The victim does not need to use gather instructions to be vulnerable. Because the buffers are shared between Hyper-Threads cross Hyper-Thread attacks are possible. Attack scenarios ---------------- Without mitigation, GDS can infer stale data across virtually all permission boundaries: Non-enclaves can infer SGX enclave data Userspace can infer kernel data Guests can infer data from hosts Guest can infer guest from other guests Users can infer data from other users Because of this, it is important to ensure that the mitigation stays enabled in lower-privilege contexts like guests and when running outside SGX enclaves. The hardware enforces the mitigation for SGX. Likewise, VMMs should ensure that guests are not allowed to disable the GDS mitigation. If a host erred and allowed this, a guest could theoretically disable GDS mitigation, mount an attack, and re-enable it. Mitigation mechanism -------------------- This issue is mitigated in microcode. The microcode defines the following new bits: ================================ === ============================ IA32_ARCH_CAPABILITIES[GDS_CTRL] R/O Enumerates GDS vulnerability and mitigation support. IA32_ARCH_CAPABILITIES[GDS_NO] R/O Processor is not vulnerable. IA32_MCU_OPT_CTRL[GDS_MITG_DIS] R/W Disables the mitigation 0 by default. IA32_MCU_OPT_CTRL[GDS_MITG_LOCK] R/W Locks GDS_MITG_DIS=0. Writes to GDS_MITG_DIS are ignored Can't be cleared once set. ================================ === ============================ GDS can also be mitigated on systems that don't have updated microcode by disabling AVX. This can be done by setting gather_data_sampling="force" or "clearcpuid=avx" on the kernel command-line. If used, these options will disable AVX use by turning off XSAVE YMM support. However, the processor will still enumerate AVX support. Userspace that does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM support will break. Mitigation control on the kernel command line --------------------------------------------- The mitigation can be disabled by setting "gather_data_sampling=off" or "mitigations=off" on the kernel command line. Not specifying either will default to the mitigation being enabled. Specifying "gather_data_sampling=force" will use the microcode mitigation when available or disable AVX on affected systems where the microcode hasn't been updated to include the mitigation. GDS System Information ------------------------ The kernel provides vulnerability status information through sysfs. For GDS this can be accessed by the following sysfs file: /sys/devices/system/cpu/vulnerabilities/gather_data_sampling The possible values contained in this file are: ============================== ============================================= Not affected Processor not vulnerable. Vulnerable Processor vulnerable and mitigation disabled. Vulnerable: No microcode Processor vulnerable and microcode is missing mitigation. Mitigation: AVX disabled, no microcode Processor is vulnerable and microcode is missing mitigation. AVX disabled as mitigation. Mitigation: Microcode Processor is vulnerable and mitigation is in effect. Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in effect and cannot be disabled. Unknown: Dependent on hypervisor status Running on a virtual guest processor that is affected but with no way to know if host processor is mitigated or vulnerable. ============================== ============================================= GDS Default mitigation ---------------------- The updated microcode will enable the mitigation by default. The kernel's default action is to leave the mitigation enabled. Documentation/admin-guide/hw-vuln/index.rst +1 −0 Original line number Diff line number Diff line Loading @@ -16,3 +16,4 @@ are configurable at compile, boot or run time. multihit.rst special-register-buffer-data-sampling.rst processor_mmio_stale_data.rst gather_data_sampling.rst Documentation/admin-guide/hw-vuln/spectre.rst +16 −5 Original line number Diff line number Diff line Loading @@ -479,8 +479,16 @@ Spectre variant 2 On Intel Skylake-era systems the mitigation covers most, but not all, cases. See :ref:`[3] <spec_ref3>` for more details. On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced IBRS on x86), retpoline is automatically disabled at run time. On CPUs with hardware mitigation for Spectre variant 2 (e.g. IBRS or enhanced IBRS on x86), retpoline is automatically disabled at run time. Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at boot, by setting the IBRS bit, and they're automatically protected against Spectre v2 variant attacks, including cross-thread branch target injections on SMT systems (STIBP). In other words, eIBRS enables STIBP too. Legacy IBRS systems clear the IBRS bit on exit to userspace and therefore explicitly enable STIBP for that The retpoline mitigation is turned on by default on vulnerable CPUs. It can be forced on or off by the administrator Loading @@ -504,9 +512,12 @@ Spectre variant 2 For Spectre variant 2 mitigation, individual user programs can be compiled with return trampolines for indirect branches. This protects them from consuming poisoned entries in the branch target buffer left by malicious software. Alternatively, the programs can disable their indirect branch speculation via prctl() (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`). target buffer left by malicious software. On legacy IBRS systems, at return to userspace, implicit STIBP is disabled because the kernel clears the IBRS bit. In this case, the userspace programs can disable indirect branch speculation via prctl() (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`). On x86, this will turn on STIBP to guard against attacks from the sibling thread when the user program is running, and use IBPB to flush the branch target buffer when switching to/from the program. Loading Documentation/admin-guide/kernel-parameters.txt +30 −13 Original line number Diff line number Diff line Loading @@ -823,10 +823,6 @@ debugpat [X86] Enable PAT debugging decnet.addr= [HW,NET] Format: <area>[,<node>] See also Documentation/networking/decnet.txt. default_hugepagesz= [same as hugepagesz=] The size of the default HugeTLB page size. This is the size represented by Loading Loading @@ -1310,6 +1306,26 @@ Format: off | on default: on gather_data_sampling= [X86,INTEL] Control the Gather Data Sampling (GDS) mitigation. Gather Data Sampling is a hardware vulnerability which allows unprivileged speculative access to data which was previously stored in vector registers. This issue is mitigated by default in updated microcode. The mitigation may have a performance impact but can be disabled. On systems without the microcode mitigation disabling AVX serves as a mitigation. force: Disable AVX to mitigate systems without microcode mitigation. No effect if the microcode mitigation is present. Known to cause crashes in userspace with buggy AVX enumeration. off: Disable GDS mitigation. gcov_persist= [GCOV] When non-zero (default), profiling data for kernel modules is saved and remains accessible via debugfs, even when the module is unloaded/reloaded. Loading Loading @@ -2584,22 +2600,23 @@ Disable all optional CPU mitigations. This improves system performance, but it may also expose users to several CPU vulnerabilities. Equivalent to: nopti [X86,PPC] Equivalent to: gather_data_sampling=off [X86] kpti=0 [ARM64] nospectre_v1 [PPC] kvm.nx_huge_pages=off [X86] l1tf=off [X86] mds=off [X86] mmio_stale_data=off [X86] no_entry_flush [PPC] no_uaccess_flush [PPC] nobp=0 [S390] nopti [X86,PPC] nospectre_v1 [PPC] nospectre_v1 [X86] nospectre_v2 [X86,PPC,S390,ARM64] spectre_v2_user=off [X86] spec_store_bypass_disable=off [X86,PPC] spectre_v2_user=off [X86] ssbd=force-off [ARM64] l1tf=off [X86] mds=off [X86] tsx_async_abort=off [X86] kvm.nx_huge_pages=off [X86] no_entry_flush [PPC] no_uaccess_flush [PPC] mmio_stale_data=off [X86] Exceptions: This does not have any effect on Loading Loading
Documentation/ABI/testing/sysfs-devices-system-cpu +6 −5 Original line number Diff line number Diff line Loading @@ -472,16 +472,17 @@ Description: information about CPUs heterogeneity. cpu_capacity: capacity of cpu#. What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/gather_data_sampling /sys/devices/system/cpu/vulnerabilities/itlb_multihit /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds /sys/devices/system/cpu/vulnerabilities/meltdown /sys/devices/system/cpu/vulnerabilities/mmio_stale_data /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/spectre_v1 /sys/devices/system/cpu/vulnerabilities/spectre_v2 /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit /sys/devices/system/cpu/vulnerabilities/mmio_stale_data Date: January 2018 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: Information about CPU vulnerabilities Loading
Documentation/admin-guide/hw-vuln/gather_data_sampling.rst 0 → 100644 +109 −0 Original line number Diff line number Diff line .. SPDX-License-Identifier: GPL-2.0 GDS - Gather Data Sampling ========================== Gather Data Sampling is a hardware vulnerability which allows unprivileged speculative access to data which was previously stored in vector registers. Problem ------- When a gather instruction performs loads from memory, different data elements are merged into the destination vector register. However, when a gather instruction that is transiently executed encounters a fault, stale data from architectural or internal vector registers may get transiently forwarded to the destination vector register instead. This will allow a malicious attacker to infer stale data using typical side channel techniques like cache timing attacks. GDS is a purely sampling-based attack. The attacker uses gather instructions to infer the stale vector register data. The victim does not need to do anything special other than use the vector registers. The victim does not need to use gather instructions to be vulnerable. Because the buffers are shared between Hyper-Threads cross Hyper-Thread attacks are possible. Attack scenarios ---------------- Without mitigation, GDS can infer stale data across virtually all permission boundaries: Non-enclaves can infer SGX enclave data Userspace can infer kernel data Guests can infer data from hosts Guest can infer guest from other guests Users can infer data from other users Because of this, it is important to ensure that the mitigation stays enabled in lower-privilege contexts like guests and when running outside SGX enclaves. The hardware enforces the mitigation for SGX. Likewise, VMMs should ensure that guests are not allowed to disable the GDS mitigation. If a host erred and allowed this, a guest could theoretically disable GDS mitigation, mount an attack, and re-enable it. Mitigation mechanism -------------------- This issue is mitigated in microcode. The microcode defines the following new bits: ================================ === ============================ IA32_ARCH_CAPABILITIES[GDS_CTRL] R/O Enumerates GDS vulnerability and mitigation support. IA32_ARCH_CAPABILITIES[GDS_NO] R/O Processor is not vulnerable. IA32_MCU_OPT_CTRL[GDS_MITG_DIS] R/W Disables the mitigation 0 by default. IA32_MCU_OPT_CTRL[GDS_MITG_LOCK] R/W Locks GDS_MITG_DIS=0. Writes to GDS_MITG_DIS are ignored Can't be cleared once set. ================================ === ============================ GDS can also be mitigated on systems that don't have updated microcode by disabling AVX. This can be done by setting gather_data_sampling="force" or "clearcpuid=avx" on the kernel command-line. If used, these options will disable AVX use by turning off XSAVE YMM support. However, the processor will still enumerate AVX support. Userspace that does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM support will break. Mitigation control on the kernel command line --------------------------------------------- The mitigation can be disabled by setting "gather_data_sampling=off" or "mitigations=off" on the kernel command line. Not specifying either will default to the mitigation being enabled. Specifying "gather_data_sampling=force" will use the microcode mitigation when available or disable AVX on affected systems where the microcode hasn't been updated to include the mitigation. GDS System Information ------------------------ The kernel provides vulnerability status information through sysfs. For GDS this can be accessed by the following sysfs file: /sys/devices/system/cpu/vulnerabilities/gather_data_sampling The possible values contained in this file are: ============================== ============================================= Not affected Processor not vulnerable. Vulnerable Processor vulnerable and mitigation disabled. Vulnerable: No microcode Processor vulnerable and microcode is missing mitigation. Mitigation: AVX disabled, no microcode Processor is vulnerable and microcode is missing mitigation. AVX disabled as mitigation. Mitigation: Microcode Processor is vulnerable and mitigation is in effect. Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in effect and cannot be disabled. Unknown: Dependent on hypervisor status Running on a virtual guest processor that is affected but with no way to know if host processor is mitigated or vulnerable. ============================== ============================================= GDS Default mitigation ---------------------- The updated microcode will enable the mitigation by default. The kernel's default action is to leave the mitigation enabled.
Documentation/admin-guide/hw-vuln/index.rst +1 −0 Original line number Diff line number Diff line Loading @@ -16,3 +16,4 @@ are configurable at compile, boot or run time. multihit.rst special-register-buffer-data-sampling.rst processor_mmio_stale_data.rst gather_data_sampling.rst
Documentation/admin-guide/hw-vuln/spectre.rst +16 −5 Original line number Diff line number Diff line Loading @@ -479,8 +479,16 @@ Spectre variant 2 On Intel Skylake-era systems the mitigation covers most, but not all, cases. See :ref:`[3] <spec_ref3>` for more details. On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced IBRS on x86), retpoline is automatically disabled at run time. On CPUs with hardware mitigation for Spectre variant 2 (e.g. IBRS or enhanced IBRS on x86), retpoline is automatically disabled at run time. Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at boot, by setting the IBRS bit, and they're automatically protected against Spectre v2 variant attacks, including cross-thread branch target injections on SMT systems (STIBP). In other words, eIBRS enables STIBP too. Legacy IBRS systems clear the IBRS bit on exit to userspace and therefore explicitly enable STIBP for that The retpoline mitigation is turned on by default on vulnerable CPUs. It can be forced on or off by the administrator Loading @@ -504,9 +512,12 @@ Spectre variant 2 For Spectre variant 2 mitigation, individual user programs can be compiled with return trampolines for indirect branches. This protects them from consuming poisoned entries in the branch target buffer left by malicious software. Alternatively, the programs can disable their indirect branch speculation via prctl() (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`). target buffer left by malicious software. On legacy IBRS systems, at return to userspace, implicit STIBP is disabled because the kernel clears the IBRS bit. In this case, the userspace programs can disable indirect branch speculation via prctl() (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`). On x86, this will turn on STIBP to guard against attacks from the sibling thread when the user program is running, and use IBPB to flush the branch target buffer when switching to/from the program. Loading
Documentation/admin-guide/kernel-parameters.txt +30 −13 Original line number Diff line number Diff line Loading @@ -823,10 +823,6 @@ debugpat [X86] Enable PAT debugging decnet.addr= [HW,NET] Format: <area>[,<node>] See also Documentation/networking/decnet.txt. default_hugepagesz= [same as hugepagesz=] The size of the default HugeTLB page size. This is the size represented by Loading Loading @@ -1310,6 +1306,26 @@ Format: off | on default: on gather_data_sampling= [X86,INTEL] Control the Gather Data Sampling (GDS) mitigation. Gather Data Sampling is a hardware vulnerability which allows unprivileged speculative access to data which was previously stored in vector registers. This issue is mitigated by default in updated microcode. The mitigation may have a performance impact but can be disabled. On systems without the microcode mitigation disabling AVX serves as a mitigation. force: Disable AVX to mitigate systems without microcode mitigation. No effect if the microcode mitigation is present. Known to cause crashes in userspace with buggy AVX enumeration. off: Disable GDS mitigation. gcov_persist= [GCOV] When non-zero (default), profiling data for kernel modules is saved and remains accessible via debugfs, even when the module is unloaded/reloaded. Loading Loading @@ -2584,22 +2600,23 @@ Disable all optional CPU mitigations. This improves system performance, but it may also expose users to several CPU vulnerabilities. Equivalent to: nopti [X86,PPC] Equivalent to: gather_data_sampling=off [X86] kpti=0 [ARM64] nospectre_v1 [PPC] kvm.nx_huge_pages=off [X86] l1tf=off [X86] mds=off [X86] mmio_stale_data=off [X86] no_entry_flush [PPC] no_uaccess_flush [PPC] nobp=0 [S390] nopti [X86,PPC] nospectre_v1 [PPC] nospectre_v1 [X86] nospectre_v2 [X86,PPC,S390,ARM64] spectre_v2_user=off [X86] spec_store_bypass_disable=off [X86,PPC] spectre_v2_user=off [X86] ssbd=force-off [ARM64] l1tf=off [X86] mds=off [X86] tsx_async_abort=off [X86] kvm.nx_huge_pages=off [X86] no_entry_flush [PPC] no_uaccess_flush [PPC] mmio_stale_data=off [X86] Exceptions: This does not have any effect on Loading
