[PATCH v2] x86/bugs: Break down mitigations configurations

[PATCH v2] x86/bugs: Break down mitigations configurations

[Breno Leitao]

There is no way to disable MDS, TAA, MMIO Stale data mitigation today at
compilation time. These mitigations are enabled even if
CONFIG_SPECULATION_MITIGATIONS is unset.

Create a new KCONFIG option for each mitigation under
CONFIG_SPECULATION_MITIGATIONS that allows these
mitigations to be disabled by default at compilation time.

It is still possible to enable these mitigations by passing kernel
parameters, even if they are disabled by default.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
V1->V2: Change the default value of the global mitigation flag, other
	than disabling at the function itself, so, it could be
	re-enabled/overwritten if a parameter is passed.

---
 arch/x86/Kconfig           | 31 +++++++++++++++++++++++++++++++
 arch/x86/kernel/cpu/bugs.c | 12 ++++++++++++
 2 files changed, 43 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 53bab123a8ee..ba64f7c9b08d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2649,6 +2649,37 @@ config SLS
 	  against straight line speculation. The kernel image might be slightly
 	  larger.
 
+config MITIGATE_MDS
+	bool "Mitigate Microarchitectural Data Sampling (MDS) hardware bug"
+	depends on CPU_SUP_INTEL && X86_64
+	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
+	  technical information is available in the MDS specific x86 architecture
+	  section: Documentation/arch/x86/mds.rst.
+
+config MITIGATE_TAA
+	bool "Mitigate TSX Asynchronous Abort (TAA) hardware bug"
+	depends on CPU_SUP_INTEL && X86_64
+	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.
+
+config MITIGATE_MMIO_STALE_DATA
+	bool "Mitigate MMIO Stale Data hardware bug"
+	depends on CPU_SUP_INTEL && X86_64
+	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.
+
 endif
 
 config ARCH_HAS_ADD_PAGES
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 182af64387d0..ba653830796f 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -267,7 +267,11 @@ static void x86_amd_ssb_disable(void)
 #define pr_fmt(fmt)	"MDS: " fmt
 
 /* Default mitigation for MDS-affected CPUs */
+#if IS_ENABLED(CONFIG_MITIGATE_MDS)
 static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_FULL;
+#else
+static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_OFF;
+#endif
 static bool mds_nosmt __ro_after_init = false;
 
 static const char * const mds_strings[] = {
@@ -327,7 +331,11 @@ enum taa_mitigations {
 };
 
 /* Default mitigation for TAA-affected CPUs */
+#if IS_ENABLED(CONFIG_MITIGATE_TAA)
 static enum taa_mitigations taa_mitigation __ro_after_init = TAA_MITIGATION_VERW;
+#else
+static enum taa_mitigations taa_mitigation __ro_after_init = TAA_MITIGATION_OFF;
+#endif
 static bool taa_nosmt __ro_after_init;
 
 static const char * const taa_strings[] = {
@@ -428,7 +436,11 @@ enum mmio_mitigations {
 };
 
 /* Default mitigation for Processor MMIO Stale Data vulnerabilities */
+#if IS_ENABLED(CONFIG_MITIGATE_MMIO_STALE_DATA)
 static enum mmio_mitigations mmio_mitigation __ro_after_init = MMIO_MITIGATION_VERW;
+#else
+static enum mmio_mitigations mmio_mitigation __ro_after_init = MMIO_MITIGATION_OFF;
+#endif
 static bool mmio_nosmt __ro_after_init = false;
 
 static const char * const mmio_strings[] = {
-- 
2.34.1

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Pawan Gupta]

On Fri, Jun 16, 2023 at 09:48:50AM -0700, Breno Leitao wrote:
> There is no way to disable MDS, TAA, MMIO Stale data mitigation today at
> compilation time. These mitigations are enabled even if
> CONFIG_SPECULATION_MITIGATIONS is unset.
> 
> Create a new KCONFIG option for each mitigation under
> CONFIG_SPECULATION_MITIGATIONS that allows these
> mitigations to be disabled by default at compilation time.

I don't think all mitigations are still controllable at build-time e.g.
spectre_v2 eIBRS mitigation will still be deployed irrespective of the
config.

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Breno Leitao]

On Tue, Jun 20, 2023 at 05:13:27PM -0700, Pawan Gupta wrote:
> On Fri, Jun 16, 2023 at 09:48:50AM -0700, Breno Leitao wrote:
> > There is no way to disable MDS, TAA, MMIO Stale data mitigation today at
> > compilation time. These mitigations are enabled even if
> > CONFIG_SPECULATION_MITIGATIONS is unset.
> > 
> > Create a new KCONFIG option for each mitigation under
> > CONFIG_SPECULATION_MITIGATIONS that allows these
> > mitigations to be disabled by default at compilation time.
> 
> I don't think all mitigations are still controllable at build-time e.g.
> spectre_v2 eIBRS mitigation will still be deployed irrespective of the
> config.

Right. This patchset only cares about MDS, TAA and MMIO. I am more than
happy to send a new patch to also disable spectre_v2 eIBRS.

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Pawan Gupta]

On Wed, Jun 21, 2023 at 08:54:17AM -0700, Breno Leitao wrote:
> On Tue, Jun 20, 2023 at 05:13:27PM -0700, Pawan Gupta wrote:
> > On Fri, Jun 16, 2023 at 09:48:50AM -0700, Breno Leitao wrote:
> > > There is no way to disable MDS, TAA, MMIO Stale data mitigation today at
> > > compilation time. These mitigations are enabled even if
> > > CONFIG_SPECULATION_MITIGATIONS is unset.
> > > 
> > > Create a new KCONFIG option for each mitigation under
> > > CONFIG_SPECULATION_MITIGATIONS that allows these
> > > mitigations to be disabled by default at compilation time.
> > 
> > I don't think all mitigations are still controllable at build-time e.g.
> > spectre_v2 eIBRS mitigation will still be deployed irrespective of the
> > config.
> 
> Right. This patchset only cares about MDS, TAA and MMIO. I am more than
> happy to send a new patch to also disable spectre_v2 eIBRS.

What about Retbleed, L1TF, SRBDS etc? I thought the goal is to control
all speculation mitigations?

To be consistent CONFIG_SPECULATION_MITIGATIONS should control all
speculation mitigations.

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Breno Leitao]

On Wed, Jun 21, 2023 at 10:31:35AM -0700, Pawan Gupta wrote:
> On Wed, Jun 21, 2023 at 08:54:17AM -0700, Breno Leitao wrote:
> > On Tue, Jun 20, 2023 at 05:13:27PM -0700, Pawan Gupta wrote:
> > > On Fri, Jun 16, 2023 at 09:48:50AM -0700, Breno Leitao wrote:
> > > > There is no way to disable MDS, TAA, MMIO Stale data mitigation today at
> > > > compilation time. These mitigations are enabled even if
> > > > CONFIG_SPECULATION_MITIGATIONS is unset.
> > > > 
> > > > Create a new KCONFIG option for each mitigation under
> > > > CONFIG_SPECULATION_MITIGATIONS that allows these
> > > > mitigations to be disabled by default at compilation time.
> > > 
> > > I don't think all mitigations are still controllable at build-time e.g.
> > > spectre_v2 eIBRS mitigation will still be deployed irrespective of the
> > > config.
> > 
> > Right. This patchset only cares about MDS, TAA and MMIO. I am more than
> > happy to send a new patch to also disable spectre_v2 eIBRS.
> 
> What about Retbleed, L1TF, SRBDS etc? I thought the goal is to control
> all speculation mitigations?
> 
> To be consistent CONFIG_SPECULATION_MITIGATIONS should control all
> speculation mitigations.

If I understand where you want to go, you think we should create a
single patchset that creates a CONFIG_<MITIGATION> for each mitigation,
and move get it under CONFIG_SPECULATION_MITIGATIONS.

Is this what you think we should do?

Thanks!

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Pawan Gupta]

On Wed, Jun 21, 2023 at 11:36:53AM -0700, Breno Leitao wrote:
> On Wed, Jun 21, 2023 at 10:31:35AM -0700, Pawan Gupta wrote:
> > On Wed, Jun 21, 2023 at 08:54:17AM -0700, Breno Leitao wrote:
> > > On Tue, Jun 20, 2023 at 05:13:27PM -0700, Pawan Gupta wrote:
> > > > On Fri, Jun 16, 2023 at 09:48:50AM -0700, Breno Leitao wrote:
> > > > > There is no way to disable MDS, TAA, MMIO Stale data mitigation today at
> > > > > compilation time. These mitigations are enabled even if
> > > > > CONFIG_SPECULATION_MITIGATIONS is unset.
> > > > > 
> > > > > Create a new KCONFIG option for each mitigation under
> > > > > CONFIG_SPECULATION_MITIGATIONS that allows these
> > > > > mitigations to be disabled by default at compilation time.
> > > > 
> > > > I don't think all mitigations are still controllable at build-time e.g.
> > > > spectre_v2 eIBRS mitigation will still be deployed irrespective of the
> > > > config.
> > > 
> > > Right. This patchset only cares about MDS, TAA and MMIO. I am more than
> > > happy to send a new patch to also disable spectre_v2 eIBRS.
> > 
> > What about Retbleed, L1TF, SRBDS etc? I thought the goal is to control
> > all speculation mitigations?
> > 
> > To be consistent CONFIG_SPECULATION_MITIGATIONS should control all
> > speculation mitigations.
> 
> If I understand where you want to go, you think we should create a
> single patchset that creates a CONFIG_<MITIGATION> for each mitigation,
> and move get it under CONFIG_SPECULATION_MITIGATIONS.

Yes, a single series (or a patch) that adds config for each mitigation
would be good.

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Dave Hansen]

On 6/21/23 12:41, Pawan Gupta wrote:
> Yes, a single series (or a patch) that adds config for each mitigation
> would be good.

Do people _really_ want per-mitigation compile-time controls?  That
seems like kinda a pain.

I Boris suggested it, but it seems like a _bit_ of overkill to me.

Would a compile-time option that just defaulted _everything_ to
mitigations=off behavior work instead?  That way we don't end up with a
billion new config options.

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Breno Leitao]

On Wed, Jun 21, 2023 at 03:35:45PM -0700, Dave Hansen wrote:
> On 6/21/23 12:41, Pawan Gupta wrote:
> > Yes, a single series (or a patch) that adds config for each mitigation
> > would be good.
> 
> Do people _really_ want per-mitigation compile-time controls?  That
> seems like kinda a pain.
> 
> I Boris suggested it, but it seems like a _bit_ of overkill to me.
> 
> Would a compile-time option that just defaulted _everything_ to
> mitigations=off behavior work instead?  That way we don't end up with a
> billion new config options.

This is exactly what my original patch proposed. It solves the problem with
a few lines of changes.

https://lore.kernel.org/lkml/20230203120615.1121272-1-leitao@debian.org/

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Dave Hansen]

On 6/21/23 15:52, Breno Leitao wrote:
> On Wed, Jun 21, 2023 at 03:35:45PM -0700, Dave Hansen wrote:
>> On 6/21/23 12:41, Pawan Gupta wrote:
>>> Yes, a single series (or a patch) that adds config for each mitigation
>>> would be good.
>> Do people _really_ want per-mitigation compile-time controls?  That
>> seems like kinda a pain.
>>
>> I Boris suggested it, but it seems like a _bit_ of overkill to me.
>>
>> Would a compile-time option that just defaulted _everything_ to
>> mitigations=off behavior work instead?  That way we don't end up with a
>> billion new config options.
> This is exactly what my original patch proposed. It solves the problem with
> a few lines of changes.
> 
> https://lore.kernel.org/lkml/20230203120615.1121272-1-leitao@debian.org/

Hey Boris,

I like this simple thingy better.  If for no other reason than it
reduces the burden of what we have to do for every _new_ mitigation
going forward.

Do you like the direction this is going?  Maybe I'm missing something.

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Borislav Petkov]

On Wed, Jun 21, 2023 at 03:58:10PM -0700, Dave Hansen wrote:
> Do you like the direction this is going?  Maybe I'm missing something.

Yeah, see

f43b9876e857 ("x86/retbleed: Add fine grained Kconfig knobs")

AFAIR, Linus wanted those this way so the only logical next step is to
add the Kconfig knobs for the missing ones...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Dave Hansen]

On 6/22/23 05:42, Borislav Petkov wrote:
> On Wed, Jun 21, 2023 at 03:58:10PM -0700, Dave Hansen wrote:
>> Do you like the direction this is going?  Maybe I'm missing something.
> Yeah, see
> 
> f43b9876e857 ("x86/retbleed: Add fine grained Kconfig knobs")
> 
> AFAIR, Linus wanted those this way so the only logical next step is to
> add the Kconfig knobs for the missing ones...

Makes sense.  Thanks.

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Breno Leitao]

Hello Pawan,

On Wed, Jun 21, 2023 at 12:41:01PM -0700, Pawan Gupta wrote:
> On Wed, Jun 21, 2023 at 11:36:53AM -0700, Breno Leitao wrote:
> > If I understand where you want to go, you think we should create a
> > single patchset that creates a CONFIG_<MITIGATION> for each mitigation,
> > and move get it under CONFIG_SPECULATION_MITIGATIONS.
> 
> Yes, a single series (or a patch) that adds config for each mitigation
> would be good.

I've been working on this request, and I may need your help to validate
the wordings and dependencies (as in architecture/vendors where the
problem needs to be mitigations) for each entry.

Also, I want to make sure I am not missing anything. Here is what I have
so far. Is it in the right direction?

--
Author: Breno Leitao <leitao@debian.org>
Date:   Thu Jun 15 08:04:16 2023 -0700

    x86/bugs: Break down mitigations configurations
    
    Create an entry for each CPU mitigation under
    CONFIG_SPECULATION_MITIGATIONS. This allow users to enable or disable
    them at compilation time.
    
    If a mitigation is disabled at compilation time, it could be enabled at
    runtime using kernel command line arguments.
    
    Signed-off-by: Breno Leitao <leitao@debian.org>

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 53bab123a8ee..10ea7884eddd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2649,6 +2649,100 @@ config SLS
 	  against straight line speculation. The kernel image might be slightly
 	  larger.
 
+config MITIGATE_MDS
+	bool "Mitigate Microarchitectural Data Sampling (MDS) hardware bug"
+	depends on CPU_SUP_INTEL && X86_64
+	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
+	  technical information is available in the MDS specific x86 architecture
+	  section: Documentation/arch/x86/mds.rst.
+
+config MITIGATE_TAA
+	bool "Mitigate TSX Asynchronous Abort (TAA) hardware bug"
+	depends on CPU_SUP_INTEL && X86_64
+	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.
+
+config MITIGATE_MMIO_STALE_DATA
+	bool "Mitigate MMIO Stale Data hardware bug"
+	depends on CPU_SUP_INTEL && X86_64
+	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.
+
+config MITIGATE_L1TF
+	bool "Mitigate L1 Terminal Fault (L1TF) hardware bug"
+	depends on X86_64
+	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.
+
+config MITIGATE_RETBLEED
+	bool "Mitigate MMIO Stale Data hardware bug"
+	default y
+	help
+	  Enable mitigation for RETBleed (Arbitrary Speculative Code Execution
+	  with Return Instructions) vulnerability.  RETBleed is a speculative
+	  execution attack which takes advantage of microarchitectural behavior
+	  in many modern microprocessors, similar to Spectre v2. An
+	  unprivileged attacker can use these flaws to bypass conventional
+	  memory security restrictions to gain read access to privileged memory
+	  that would otherwise be inaccessible.
+
+config MITIGATE_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.
+
+config MITIGATE_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.
+
+config MITIGATE_SRBDS
+	bool "Mitigate Special Register Buffer Data Sampling (SRBDS) hardware bug"
+	depends on CPU_SUP_INTEL && X86_64
+	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.
+
+config MITIGATE_SSB
+	bool "Mitigate Speculative Store Bypass (SSB) hardware bug"
+	default y
+	help
+	  Enable mitigation for Speculative Store Bypass (SSB). SSB is a
+	  hardware security vulnerability and its exploitation takes advantage
+	  of speculative execution in a similar way to the Meltdown and Spectre
+	  security vulnerabilities.
+
 endif
 
 config ARCH_HAS_ADD_PAGES
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 2b03e2ff03bb..5482cf33e56d 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -270,7 +270,11 @@ static void x86_amd_ssb_disable(void)
 #define pr_fmt(fmt)	"MDS: " fmt
 
 /* Default mitigation for MDS-affected CPUs */
+#if IS_ENABLED(CONFIG_MITIGATE_MDS)
 static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_FULL;
+#else
+static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_OFF;
+#endif
 static bool mds_nosmt __ro_after_init = false;
 
 static const char * const mds_strings[] = {
@@ -330,7 +334,11 @@ enum taa_mitigations {
 };
 
 /* Default mitigation for TAA-affected CPUs */
+#if IS_ENABLED(CONFIG_MITIGATE_TAA)
 static enum taa_mitigations taa_mitigation __ro_after_init = TAA_MITIGATION_VERW;
+#else
+static enum taa_mitigations taa_mitigation __ro_after_init = TAA_MITIGATION_OFF;
+#endif
 static bool taa_nosmt __ro_after_init;
 
 static const char * const taa_strings[] = {
@@ -431,7 +439,11 @@ enum mmio_mitigations {
 };
 
 /* Default mitigation for Processor MMIO Stale Data vulnerabilities */
+#if IS_ENABLED(CONFIG_MITIGATE_MMIO_STALE_DATA)
 static enum mmio_mitigations mmio_mitigation __ro_after_init = MMIO_MITIGATION_VERW;
+#else
+static enum mmio_mitigations mmio_mitigation __ro_after_init = MMIO_MITIGATION_OFF;
+#endif
 static bool mmio_nosmt __ro_after_init = false;
 
 static const char * const mmio_strings[] = {
@@ -580,7 +592,11 @@ enum srbds_mitigations {
 	SRBDS_MITIGATION_HYPERVISOR,
 };
 
+#if IS_ENABLED(CONFIG_MITIGATE_SRBDS)
 static enum srbds_mitigations srbds_mitigation __ro_after_init = SRBDS_MITIGATION_FULL;
+#else
+static enum srbds_mitigations srbds_mitigation __ro_after_init = SRBDS_MITIGATION_OFF;
+#endif
 
 static const char * const srbds_strings[] = {
 	[SRBDS_MITIGATION_OFF]		= "Vulnerable",
@@ -705,8 +721,13 @@ enum spectre_v1_mitigation {
 	SPECTRE_V1_MITIGATION_AUTO,
 };
 
+#if IS_ENABLED(CONFIG_MITIGATE_SPECTRE_V1)
 static enum spectre_v1_mitigation spectre_v1_mitigation __ro_after_init =
 	SPECTRE_V1_MITIGATION_AUTO;
+#else
+static enum spectre_v1_mitigation spectre_v1_mitigation __ro_after_init =
+	SPECTRE_V1_MITIGATION_NONE;
+#endif
 
 static const char * const spectre_v1_strings[] = {
 	[SPECTRE_V1_MITIGATION_NONE] = "Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers",
@@ -820,8 +841,13 @@ static const char * const retbleed_strings[] = {
 
 static enum retbleed_mitigation retbleed_mitigation __ro_after_init =
 	RETBLEED_MITIGATION_NONE;
+#if IS_ENABLED(CONFIG_MITIGATE_RETBLEED)
 static enum retbleed_mitigation_cmd retbleed_cmd __ro_after_init =
 	RETBLEED_CMD_AUTO;
+#else
+static enum retbleed_mitigation_cmd retbleed_cmd __ro_after_init =
+	RETBLEED_CMD_OFF;
+#endif
 
 static int __ro_after_init retbleed_nosmt = false;
 
@@ -1276,7 +1302,11 @@ static void __init spec_v2_print_cond(const char *reason, bool secure)
 
 static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
 {
+#if IS_ENABLED(CONFIG_MITIGATE_SPECTRE_V2)
 	enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_AUTO;
+#else
+	enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_NONE;
+#endif
 	char arg[20];
 	int ret, i;
 
@@ -1286,7 +1316,7 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
 
 	ret = cmdline_find_option(boot_command_line, "spectre_v2", arg, sizeof(arg));
 	if (ret < 0)
-		return SPECTRE_V2_CMD_AUTO;
+		return cmd;
 
 	for (i = 0; i < ARRAY_SIZE(mitigation_options); i++) {
 		if (!match_option(arg, ret, mitigation_options[i].option))
@@ -1770,7 +1800,11 @@ static const struct {
 
 static enum ssb_mitigation_cmd __init ssb_parse_cmdline(void)
 {
+#if IS_ENABLED(CONFIG_MITIGATE_SSB)
 	enum ssb_mitigation_cmd cmd = SPEC_STORE_BYPASS_CMD_AUTO;
+#else
+	enum ssb_mitigation_cmd cmd = SPEC_STORE_BYPASS_CMD_NONE;
+#endif
 	char arg[20];
 	int ret, i;
 
@@ -1781,7 +1815,7 @@ static enum ssb_mitigation_cmd __init ssb_parse_cmdline(void)
 		ret = cmdline_find_option(boot_command_line, "spec_store_bypass_disable",
 					  arg, sizeof(arg));
 		if (ret < 0)
-			return SPEC_STORE_BYPASS_CMD_AUTO;
+			return cmd;
 
 		for (i = 0; i < ARRAY_SIZE(ssb_mitigation_options); i++) {
 			if (!match_option(arg, ret, ssb_mitigation_options[i].option))
@@ -1793,7 +1827,7 @@ static enum ssb_mitigation_cmd __init ssb_parse_cmdline(void)
 
 		if (i >= ARRAY_SIZE(ssb_mitigation_options)) {
 			pr_err("unknown option (%s). Switching to AUTO select\n", arg);
-			return SPEC_STORE_BYPASS_CMD_AUTO;
+			return cmd;
 		}
 	}
 
@@ -2119,7 +2153,12 @@ EXPORT_SYMBOL_GPL(itlb_multihit_kvm_mitigation);
 #define pr_fmt(fmt)	"L1TF: " fmt
 
 /* Default mitigation for L1TF-affected CPUs */
+
+#if IS_ENABLED(CONFIG_MITIGATE_L1TF)
 enum l1tf_mitigations l1tf_mitigation __ro_after_init = L1TF_MITIGATION_FLUSH;
+#else
+enum l1tf_mitigations l1tf_mitigation __ro_after_init = L1TF_MITIGATION_OFF;
+#endif
 #if IS_ENABLED(CONFIG_KVM_INTEL)
 EXPORT_SYMBOL_GPL(l1tf_mitigation);
 #endif

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Pawan Gupta]

On Tue, Jun 27, 2023 at 10:36:10AM -0700, Breno Leitao wrote:
> Hello Pawan,
> 
> On Wed, Jun 21, 2023 at 12:41:01PM -0700, Pawan Gupta wrote:
> > On Wed, Jun 21, 2023 at 11:36:53AM -0700, Breno Leitao wrote:
> > > If I understand where you want to go, you think we should create a
> > > single patchset that creates a CONFIG_<MITIGATION> for each mitigation,
> > > and move get it under CONFIG_SPECULATION_MITIGATIONS.
> > 
> > Yes, a single series (or a patch) that adds config for each mitigation
> > would be good.
> 
> I've been working on this request, and I may need your help to validate
> the wordings and dependencies (as in architecture/vendors where the
> problem needs to be mitigations) for each entry.

Kconfig text looks fine to me. (Some comments on arch/vendor dependency
are down below).

> Also, I want to make sure I am not missing anything. Here is what I have
> so far. Is it in the right direction?
> 
> --
> Author: Breno Leitao <leitao@debian.org>
> Date:   Thu Jun 15 08:04:16 2023 -0700
> 
>     x86/bugs: Break down mitigations configurations

How about this?

x86/bugs: Add a separate config for each mitigation

>     Create an entry for each CPU mitigation under
>     CONFIG_SPECULATION_MITIGATIONS. This allow users to enable or disable
>     them at compilation time.
>     
>     If a mitigation is disabled at compilation time, it could be enabled at
>     runtime using kernel command line arguments.
>     
>     Signed-off-by: Breno Leitao <leitao@debian.org>
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 53bab123a8ee..10ea7884eddd 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2649,6 +2649,100 @@ config SLS
>  	  against straight line speculation. The kernel image might be slightly
>  	  larger.
>  
> +config MITIGATE_MDS
> +	bool "Mitigate Microarchitectural Data Sampling (MDS) hardware bug"
> +	depends on CPU_SUP_INTEL && X86_64

Architecture/vendor dependency is resolved at runtime during bug
enumeration (using CPU family/model). I don't think there is a need to
add explicit dependency here unless it creates runtime issues. And for
these configs it doesn't.

MDS and some of the other mitigations works for 32-bit kernel as well.
Dependency on X86_64 here is not correct, it makes 32-bit systems
vulnerable.

> +	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
> +	  technical information is available in the MDS specific x86 architecture
> +	  section: Documentation/arch/x86/mds.rst.
> +
> +config MITIGATE_TAA
> +	bool "Mitigate TSX Asynchronous Abort (TAA) hardware bug"
> +	depends on CPU_SUP_INTEL && X86_64

Ditto.

> +	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.
> +
> +config MITIGATE_MMIO_STALE_DATA
> +	bool "Mitigate MMIO Stale Data hardware bug"
> +	depends on CPU_SUP_INTEL && X86_64

Ditto for and all the others.

[...]
> @@ -1286,7 +1316,7 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
>  
>  	ret = cmdline_find_option(boot_command_line, "spectre_v2", arg, sizeof(arg));
>  	if (ret < 0)
> -		return SPECTRE_V2_CMD_AUTO;
> +		return cmd;

In the same function, below code also needs to return the compile time
default:

        if (i >= ARRAY_SIZE(mitigation_options)) {
                pr_err("unknown option (%s). Switching to AUTO select\n", arg);
                return SPECTRE_V2_CMD_AUTO;
        }

[...]
> @@ -2119,7 +2153,12 @@ EXPORT_SYMBOL_GPL(itlb_multihit_kvm_mitigation);
>  #define pr_fmt(fmt)	"L1TF: " fmt
>  
>  /* Default mitigation for L1TF-affected CPUs */
> +

Extra newline.

> +#if IS_ENABLED(CONFIG_MITIGATE_L1TF)
>  enum l1tf_mitigations l1tf_mitigation __ro_after_init = L1TF_MITIGATION_FLUSH;
> +#else
> +enum l1tf_mitigations l1tf_mitigation __ro_after_init = L1TF_MITIGATION_OFF;
> +#endif
>  #if IS_ENABLED(CONFIG_KVM_INTEL)
>  EXPORT_SYMBOL_GPL(l1tf_mitigation);
>  #endif

Re: [PATCH v2] x86/bugs: Break down mitigations configurations

[Breno Leitao]

On Tue, Jun 27, 2023 at 03:30:40PM -0700, Pawan Gupta wrote:
> On Tue, Jun 27, 2023 at 10:36:10AM -0700, Breno Leitao wrote:
> > On Wed, Jun 21, 2023 at 12:41:01PM -0700, Pawan Gupta wrote:
> > > On Wed, Jun 21, 2023 at 11:36:53AM -0700, Breno Leitao wrote:
> > > > If I understand where you want to go, you think we should create a
> > > > single patchset that creates a CONFIG_<MITIGATION> for each mitigation,
> > > > and move get it under CONFIG_SPECULATION_MITIGATIONS.
> > > 
> > > Yes, a single series (or a patch) that adds config for each mitigation
> > > would be good.
> > 
> > I've been working on this request, and I may need your help to validate
> > the wordings and dependencies (as in architecture/vendors where the
> > problem needs to be mitigations) for each entry.
> 
> Kconfig text looks fine to me. (Some comments on arch/vendor dependency
> are down below).

Neat, thanks for the clarifications. I will send v3 later today.