| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 25 Oct 2023 09:29:06 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: mingo@...hat.com, tglx@...utronix.de, bp@...en8.de,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, leit@...a.com,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 12/12] x86/bugs: Add a separate config for missing
mitigation
On Thu, Oct 19, 2023 at 11:11:58AM -0700, Breno Leitao wrote:
> Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated,
> where some mitigations have entries in Kconfig, and they could be
> modified, while others mitigations do not have Kconfig entries, and
> could not be controlled at build time.
>
> Create an entry for each CPU mitigation under
> CONFIG_SPECULATION_MITIGATIONS. This allow users to enable or disable
> them at compilation time.
>
> Signed-off-by: Breno Leitao <leitao@...ian.org>
We also probably need a CONFIG_MITIGATION_MELTDOWN.
> ---
> arch/x86/Kconfig | 93 ++++++++++++++++++++++++++++++++++++++
> arch/x86/kernel/cpu/bugs.c | 39 ++++++++++------
> 2 files changed, 117 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index a5cada7443ea..ccdcb1dcdc0c 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2591,6 +2591,99 @@ config MITIGATION_GDS_FORCE
>
> If in doubt, say N.
>
> +config MITIGATION_MDS
> + bool "Mitigate Microarchitectural Data Sampling (MDS) hardware bug"
> + depends on CPU_SUP_INTEL
> + default y
> + help
> + Enable mitigation for Microarchitectural Data Sampling (MDS). MDS is
> + a hardware vulnerability which allows unprivileged speculative access
> + to data which is available in various CPU internal buffer. Deeper
buffers
> + technical information is available in the MDS specific x86 architecture
> + section: Documentation/arch/x86/mds.rst.
I believe the high-level document is actually
Documentation/admin-guide/hw-vuln/mds.rst.
> +config MITIGATION_TAA
> + bool "Mitigate TSX Asynchronous Abort (TAA) hardware bug"
> + depends on CPU_SUP_INTEL
> + default y
> + help
> + Enable mitigation for TSX Asynchronous Abort (TAA). TAA is a hardware
> + vulnerability that allows unprivileged speculative access to data
> + which is available in various CPU internal buffers by using
> + asynchronous aborts within an Intel TSX transactional region.
Refer to Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
> +config MITIGATION_MMIO_STALE_DATA
> + bool "Mitigate MMIO Stale Data hardware bug"
> + depends on CPU_SUP_INTEL
> + default y
> + help
> + Enable mitigation for MMIO Stale Data hardware bugs. Processor MMIO
> + Stale Data Vulnerabilities are a class of memory-mapped I/O (MMIO)
> + vulnerabilities that can expose data. The vulnerabilities require the
> + attacker to have access to MMIO.
Refer to Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
> +config MITIGATION_L1TF
> + bool "Mitigate L1 Terminal Fault (L1TF) hardware bug"
depends on CPU_SUP_INTEL
> + default y
> + help
> + Mitigate L1 Terminal Fault (L1TF) hardware bug. L1 Terminal Fault is a
> + hardware vulnerability which allows unprivileged speculative access to data
> + which is available in the Level 1 Data Cache when the page table
> + entry controlling the virtual address.
-EGRAMMAR
Also refer to Documentation/admin-guide/hw-vuln/l1tf.rst
> +config MITIGATION_RETBLEED
> + bool "Mitigate RETBleed hardware bug"
depends on CPU_SUP_INTEL || (CPU_SUP_AMD && MITIGATION_UNRET_ENTRY)
> +config MITIGATION_SPECTRE_V1
> + bool "Mitigate SPECTRE V1 hardware bug"
> + default y
> + help
> + Enable mitigation for Spectre V1 (Bounds Check Bypass). Spectre V1 is a
> + class of side channel attacks that takes advantage of speculative
> + execution that bypasses conditional branch instructions used for
> + memory access bounds check.
Refer to Documentation/admin-guide/hw-vuln/spectre.rst
> +config MITIGATION_SPECTRE_V2
> + bool "Mitigate SPECTRE V2 hardware bug"
> + default y
> + help
> + Enable mitigation for Spectre V2 (Branch Target Injection). Spectre
> + V2 is a class of side channel attacks that takes advantage of
> + indirect branch predictors inside the processor. In Spectre variant 2
> + attacks, the attacker can steer speculative indirect branches in the
> + victim to gadget code by poisoning the branch target buffer of a CPU
> + used for predicting indirect branch addresses.
Refer to Documentation/admin-guide/hw-vuln/spectre.rst
> +config MITIGATION_SRBDS
> + bool "Mitigate Special Register Buffer Data Sampling (SRBDS) hardware bug"
> + depends on CPU_SUP_INTEL
> + default y
> + help
> + Enable mitigation for Special Register Buffer Data Sampling (SRBDS).
> + SRBDS is a hardware vulnerability that allows Microarchitectural Data
> + Sampling (MDS) techniques to infer values returned from special
> + register accesses. An unprivileged user can extract values returned
> + from RDRAND and RDSEED executed on another core or sibling thread
> + using MDS techniques.
Refer to Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
> + cmd = IS_ENABLED(CONFIG_MITIGATION_SPECTRE_V2) ? SPECTRE_V2_CMD_AUTO : SPECTRE_V2_CMD_NONE;
> if (cmdline_find_option_bool(boot_command_line, "nospectre_v2") ||
> cpu_mitigations_off())
> return SPECTRE_V2_CMD_NONE;
I'm thinking CONFIG_MITIGATION_SPECTRE_V2 should also affect whether the spectre v2 user
mitigation gets enabled.
--
Josh
Powered by blists - more mailing lists