Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Wed, 25 Oct 2023 09:29:06 -0700
From:   Josh Poimboeuf <jpoimboe@kernel.org>
To:     Breno Leitao <leitao@debian.org>
Cc:     mingo@redhat.com, tglx@linutronix.de, bp@alien8.de,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, leit@meta.com,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 12/12] x86/bugs: Add a separate config for missing
 mitigation
Message-ID: <20231025162906.abnyb7xum7cpjwxy@treble>
References: <20231019181158.1982205-1-leitao@debian.org>
 <20231019181158.1982205-13-leitao@debian.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20231019181158.1982205-13-leitao@debian.org>
Precedence: bulk

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@debian.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