historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
* [MODERATED] [PATCH RFC 0/4] Proposed cmdline improvements
@ 2019-03-04  1:21 Josh Poimboeuf
  2019-03-04  1:23 ` [MODERATED] [PATCH RFC 1/4] 1 Josh Poimboeuf
                   ` (3 more replies)
  0 siblings, 4 replies; 17+ messages in thread
From: Josh Poimboeuf @ 2019-03-04  1:21 UTC (permalink / raw)
  To: speck


For MDS and SMT, I'd propose that we do something similar to what we did
for L1TF: a) add an mds=full,nosmt option; and b) add a printk warning
if SMT is enabled.  That's the first three patches.

The last patch proposes a meta-option which is intended to make it
easier for users to choose sane mitigation defaults for all the
speculative vulnerabilities at once.

Josh Poimboeuf (4):
  x86/speculation/mds: Add mds=full,nosmt cmdline option
  x86/speculation: Move arch_smt_update() call to after mitigation
    decisions
  x86/speculation/mds: Add SMT warning message
  x86/speculation: Add 'cpu_spec_mitigations=' cmdline options

 Documentation/admin-guide/hw-vuln/mds.rst     |  3 +
 .../admin-guide/kernel-parameters.txt         | 49 ++++++++++++-
 arch/powerpc/kernel/security.c                |  6 +-
 arch/powerpc/kernel/setup_64.c                |  2 +-
 arch/s390/kernel/nospec-branch.c              |  4 +-
 arch/x86/include/asm/processor.h              |  2 +
 arch/x86/kernel/cpu/bugs.c                    | 68 ++++++++++++++++---
 arch/x86/mm/pti.c                             |  3 +-
 include/linux/cpu.h                           |  8 +++
 kernel/cpu.c                                  | 15 ++++
 10 files changed, 144 insertions(+), 16 deletions(-)

-- 
2.17.2

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] [PATCH RFC 1/4] 1
  2019-03-04  1:21 [MODERATED] [PATCH RFC 0/4] Proposed cmdline improvements Josh Poimboeuf
@ 2019-03-04  1:23 ` Josh Poimboeuf
  2019-03-04  3:55   ` [MODERATED] Encrypted Message Jon Masters
  2019-03-04  7:30   ` [MODERATED] Re: [PATCH RFC 1/4] 1 Greg KH
  2019-03-04  1:24 ` [MODERATED] [PATCH RFC 2/4] 2 Josh Poimboeuf
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 17+ messages in thread
From: Josh Poimboeuf @ 2019-03-04  1:23 UTC (permalink / raw)
  To: speck

From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH RFC 1/4] x86/speculation/mds: Add mds=full,nosmt cmdline
 option

Add the mds=full,nosmt cmdline option.  This is like mds=full, but with
SMT disabled if the CPU is vulnerable.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 Documentation/admin-guide/hw-vuln/mds.rst       |  3 +++
 Documentation/admin-guide/kernel-parameters.txt |  6 ++++--
 arch/x86/kernel/cpu/bugs.c                      | 10 ++++++++++
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst
index 1de29d28903d..244ab47d1fb3 100644
--- a/Documentation/admin-guide/hw-vuln/mds.rst
+++ b/Documentation/admin-guide/hw-vuln/mds.rst
@@ -260,6 +260,9 @@ time with the option "mds=". The valid arguments for this option are:
 
 		It does not automatically disable SMT.
 
+  full,nosmt	The same as mds=full, with SMT disabled on vulnerable
+		CPUs.  This is the complete mitigation.
+
   off		Disables MDS mitigations completely.
 
   ============  =============================================================
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index dddb024eb523..55969f240f2e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2372,8 +2372,10 @@
 			This parameter controls the MDS mitigation. The
 			options are:
 
-			full    - Enable MDS mitigation on vulnerable CPUs
-			off     - Unconditionally disable MDS mitigation
+			full       - Enable MDS mitigation on vulnerable CPUs
+			full,nosmt - Enable MDS mitigation and disable
+				     SMT on vulnerable CPUs
+			off        - Unconditionally disable MDS mitigation
 
 			Not specifying this option is equivalent to
 			mds=full.
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index e11654f93e71..0c71ab0d57e3 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -221,6 +221,7 @@ static void x86_amd_ssb_disable(void)
 
 /* Default mitigation for L1TF-affected CPUs */
 static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_FULL;
+static bool mds_nosmt __ro_after_init = false;
 
 static const char * const mds_strings[] = {
 	[MDS_MITIGATION_OFF]	= "Vulnerable",
@@ -238,8 +239,13 @@ static void mds_select_mitigation(void)
 	if (mds_mitigation == MDS_MITIGATION_FULL) {
 		if (!boot_cpu_has(X86_FEATURE_MD_CLEAR))
 			mds_mitigation = MDS_MITIGATION_VMWERV;
+
 		static_branch_enable(&mds_user_clear);
+
+		if (mds_nosmt && !boot_cpu_has(X86_BUG_MSBDS_ONLY))
+			cpu_smt_disable(false);
 	}
+
 	pr_info("%s\n", mds_strings[mds_mitigation]);
 }
 
@@ -255,6 +261,10 @@ static int __init mds_cmdline(char *str)
 		mds_mitigation = MDS_MITIGATION_OFF;
 	else if (!strcmp(str, "full"))
 		mds_mitigation = MDS_MITIGATION_FULL;
+	else if (!strcmp(str, "full,nosmt")) {
+		mds_mitigation = MDS_MITIGATION_FULL;
+		mds_nosmt = true;
+	}
 
 	return 0;
 }
-- 
2.17.2

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [MODERATED] [PATCH RFC 2/4] 2
  2019-03-04  1:21 [MODERATED] [PATCH RFC 0/4] Proposed cmdline improvements Josh Poimboeuf
  2019-03-04  1:23 ` [MODERATED] [PATCH RFC 1/4] 1 Josh Poimboeuf
@ 2019-03-04  1:24 ` Josh Poimboeuf
  2019-03-04  7:31   ` [MODERATED] " Greg KH
  2019-03-04  1:24 ` [MODERATED] [PATCH RFC 3/4] 3 Josh Poimboeuf
  2019-03-04  1:25 ` [MODERATED] [PATCH RFC 4/4] 4 Josh Poimboeuf
  3 siblings, 1 reply; 17+ messages in thread
From: Josh Poimboeuf @ 2019-03-04  1:24 UTC (permalink / raw)
  To: speck

From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH RFC 2/4] x86/speculation: Move arch_smt_update() call to after
 mitigation decisions

arch_smt_update() now has a dependency on both Spectre v2 and MDS
mitigations.  Move its initial call to after all the mitigation
decisions have been made.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 arch/x86/kernel/cpu/bugs.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 0c71ab0d57e3..9e20aef01d38 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -111,6 +111,8 @@ void __init check_bugs(void)
 
 	mds_select_mitigation();
 
+	arch_smt_update();
+
 #ifdef CONFIG_X86_32
 	/*
 	 * Check whether we are able to run this kernel safely on SMP.
@@ -638,9 +640,6 @@ static void __init spectre_v2_select_mitigation(void)
 
 	/* Set up IBPB and STIBP depending on the general spectre V2 command */
 	spectre_v2_user_select_mitigation(cmd);
-
-	/* Enable STIBP if appropriate */
-	arch_smt_update();
 }
 
 static void update_stibp_msr(void * __unused)
-- 
2.17.2

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [MODERATED] [PATCH RFC 3/4] 3
  2019-03-04  1:21 [MODERATED] [PATCH RFC 0/4] Proposed cmdline improvements Josh Poimboeuf
  2019-03-04  1:23 ` [MODERATED] [PATCH RFC 1/4] 1 Josh Poimboeuf
  2019-03-04  1:24 ` [MODERATED] [PATCH RFC 2/4] 2 Josh Poimboeuf
@ 2019-03-04  1:24 ` Josh Poimboeuf
  2019-03-04  3:58   ` [MODERATED] Encrypted Message Jon Masters
  2019-03-04  7:33   ` [MODERATED] Re: [PATCH RFC 3/4] 3 Greg KH
  2019-03-04  1:25 ` [MODERATED] [PATCH RFC 4/4] 4 Josh Poimboeuf
  3 siblings, 2 replies; 17+ messages in thread
From: Josh Poimboeuf @ 2019-03-04  1:24 UTC (permalink / raw)
  To: speck

From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH RFC 3/4] x86/speculation/mds: Add SMT warning message

MDS is vulnerable with SMT.  Make that clear with a one-time printk
whenever SMT first gets enabled.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 arch/x86/kernel/cpu/bugs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 9e20aef01d38..346f0f05879d 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -691,6 +691,8 @@ static void update_mds_branch_idle(void)
 		static_branch_disable(&mds_idle_clear);
 }
 
+#define MDS_MSG_SMT "MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.\n"
+
 void arch_smt_update(void)
 {
 	/* Enhanced IBRS implies STIBP. No update required. */
@@ -715,6 +717,8 @@ void arch_smt_update(void)
 	switch(mds_mitigation) {
 	case MDS_MITIGATION_FULL:
 	case MDS_MITIGATION_VMWERV:
+		if (sched_smt_active() && !boot_cpu_has(X86_BUG_MSBDS_ONLY))
+			pr_warn_once(MDS_MSG_SMT);
 		update_mds_branch_idle();
 		break;
 	case MDS_MITIGATION_OFF:
-- 
2.17.2

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [MODERATED] [PATCH RFC 4/4] 4
  2019-03-04  1:21 [MODERATED] [PATCH RFC 0/4] Proposed cmdline improvements Josh Poimboeuf
                   ` (2 preceding siblings ...)
  2019-03-04  1:24 ` [MODERATED] [PATCH RFC 3/4] 3 Josh Poimboeuf
@ 2019-03-04  1:25 ` Josh Poimboeuf
  2019-03-04  4:07   ` [MODERATED] Encrypted Message Jon Masters
  3 siblings, 1 reply; 17+ messages in thread
From: Josh Poimboeuf @ 2019-03-04  1:25 UTC (permalink / raw)
  To: speck

From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH RFC 4/4] x86/speculation: Add 'cpu_spec_mitigations=' cmdline
 options

Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users.  It's getting more and more
complicated to decide what mitigations are needed for a given
architecture.

Most users fall into a few basic categories:

- want all mitigations off;

- want all reasonable mitigations on, with SMT enabled even if it's
  vulnerable; or

- want all reasonable mitigations on, with SMT disabled if vulnerable.

Define a set of curated, arch-independent options, each of which is an
aggregation of existing options:

- cpu_spec_mitigations=off: Disable all mitigations.

- cpu_spec_mitigations=auto: [default] Enable all the default mitigations,
  but leave SMT enabled, even if it's vulnerable.

- cpu_spec_mitigations=auto,nosmt: Enable all the default mitigations,
  disabling SMT if needed by a mitigation.

See the documentation for more details.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 .../admin-guide/kernel-parameters.txt         | 43 ++++++++++++++++
 arch/powerpc/kernel/security.c                |  6 +--
 arch/powerpc/kernel/setup_64.c                |  2 +-
 arch/s390/kernel/nospec-branch.c              |  4 +-
 arch/x86/include/asm/processor.h              |  2 +
 arch/x86/kernel/cpu/bugs.c                    | 51 ++++++++++++++++---
 arch/x86/mm/pti.c                             |  3 +-
 include/linux/cpu.h                           |  8 +++
 kernel/cpu.c                                  | 15 ++++++
 9 files changed, 122 insertions(+), 12 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 55969f240f2e..c2dba60630e4 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2537,6 +2537,49 @@
 			in the "bleeding edge" mini2440 support kernel at
 			http://repo.or.cz/w/linux-2.6/mini2440.git
 
+	cpu_spec_mitigations=
+			[KNL] Control mitigations for CPU speculation
+			vulnerabilities on affected CPUs.  This is a set of
+			curated, arch-independent options, each of which is an
+			aggregation of existing options.
+
+			off
+				Disable all speculative CPU mitigations.
+				Equivalent to: nopti
+					       nospectre_v1
+					       nospectre_v2
+					       spectre_v2_user=off
+					       nobp=0
+					       spec_store_bypass_disable=off
+					       l1tf=off
+					       mds=off
+
+			auto (default)
+				Mitigate all speculative CPU vulnerabilities,
+				but leave SMT enabled, even if it's vulnerable.
+				This is useful for users who don't want to be
+				surprised by SMT getting disabled across kernel
+				upgrades, or who have other ways of avoiding
+				SMT-based attacks.
+				Equivalent to: pti=auto
+					       spectre_v2=auto
+					       spectre_v2_user=auto
+					       spec_store_bypass_disable=auto
+					       l1tf=flush
+					       mds=full
+
+			auto,nosmt
+				Mitigate all speculative CPU vulnerabilities,
+				disabling SMT if needed.  This is for users who
+				always want to be fully mitigated, even if it
+				means losing SMT.
+				Equivalent to: pti=auto
+					       spectre_v2=auto
+					       spectre_v2_user=auto
+					       spec_store_bypass_disable=auto
+					       l1tf=flush,nosmt
+					       mds=full,nosmt
+
 	mminit_loglevel=
 			[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
 			parameter allows control of the logging verbosity for
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 9b8631533e02..be4266a57e54 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -57,7 +57,7 @@ void setup_barrier_nospec(void)
 	enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) &&
 		 security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR);
 
-	if (!no_nospec)
+	if (!no_nospec && cpu_spec_mitigations != CPU_SPEC_MITIGATIONS_OFF)
 		enable_barrier_nospec(enable);
 }
 
@@ -116,7 +116,7 @@ static int __init handle_nospectre_v2(char *p)
 early_param("nospectre_v2", handle_nospectre_v2);
 void setup_spectre_v2(void)
 {
-	if (no_spectrev2)
+	if (no_spectrev2 || cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF)
 		do_btb_flush_fixups();
 	else
 		btb_flush_enabled = true;
@@ -307,7 +307,7 @@ void setup_stf_barrier(void)
 
 	stf_enabled_flush_types = type;
 
-	if (!no_stf_barrier)
+	if (!no_stf_barrier && cpu_spec_mitigations != CPU_SPEC_MITIGATIONS_OFF)
 		stf_barrier_enable(enable);
 }
 
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 236c1151a3a7..5fe43bcde325 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -958,7 +958,7 @@ void setup_rfi_flush(enum l1d_flush_type types, bool enable)
 
 	enabled_flush_types = types;
 
-	if (!no_rfi_flush)
+	if (!no_rfi_flush || cpu_spec_mitigations != CPU_SPEC_MITIGATIONS_OFF)
 		rfi_flush_enable(enable);
 }
 
diff --git a/arch/s390/kernel/nospec-branch.c b/arch/s390/kernel/nospec-branch.c
index bdddaae96559..c40eb672b43a 100644
--- a/arch/s390/kernel/nospec-branch.c
+++ b/arch/s390/kernel/nospec-branch.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include <linux/module.h>
 #include <linux/device.h>
+#include <linux/cpu.h>
 #include <asm/nospec-branch.h>
 
 static int __init nobp_setup_early(char *str)
@@ -58,7 +59,8 @@ early_param("nospectre_v2", nospectre_v2_setup_early);
 
 void __init nospec_auto_detect(void)
 {
-	if (test_facility(156)) {
+	if (test_facility(156) ||
+	    cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF) {
 		/*
 		 * The machine supports etokens.
 		 * Disable expolines and disable nobp.
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index aca1ef8cc79f..bb2ced3a491e 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -983,6 +983,7 @@ void microcode_check(void);
 
 enum l1tf_mitigations {
 	L1TF_MITIGATION_OFF,
+	L1TF_MITIGATION_DEFAULT,
 	L1TF_MITIGATION_FLUSH_NOWARN,
 	L1TF_MITIGATION_FLUSH,
 	L1TF_MITIGATION_FLUSH_NOSMT,
@@ -994,6 +995,7 @@ extern enum l1tf_mitigations l1tf_mitigation;
 
 enum mds_mitigations {
 	MDS_MITIGATION_OFF,
+	MDS_MITIGATION_DEFAULT,
 	MDS_MITIGATION_FULL,
 	MDS_MITIGATION_VMWERV,
 };
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 346f0f05879d..7354daf3555f 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -222,7 +222,7 @@ static void x86_amd_ssb_disable(void)
 #define pr_fmt(fmt)	"MDS: " fmt
 
 /* Default mitigation for L1TF-affected CPUs */
-static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_FULL;
+static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_DEFAULT;
 static bool mds_nosmt __ro_after_init = false;
 
 static const char * const mds_strings[] = {
@@ -238,6 +238,20 @@ static void mds_select_mitigation(void)
 		return;
 	}
 
+	if (mds_mitigation == MDS_MITIGATION_DEFAULT) {
+		switch (cpu_spec_mitigations) {
+		case CPU_SPEC_MITIGATIONS_OFF:
+			mds_mitigation = MDS_MITIGATION_OFF;
+			break;
+		case CPU_SPEC_MITIGATIONS_AUTO_NOSMT:
+			mds_nosmt = true;
+			/* fallthrough */
+		case CPU_SPEC_MITIGATIONS_AUTO:
+			mds_mitigation = MDS_MITIGATION_FULL;
+			break;
+		}
+	}
+
 	if (mds_mitigation == MDS_MITIGATION_FULL) {
 		if (!boot_cpu_has(X86_FEATURE_MD_CLEAR))
 			mds_mitigation = MDS_MITIGATION_VMWERV;
@@ -374,8 +388,11 @@ spectre_v2_parse_user_cmdline(enum spectre_v2_mitigation_cmd v2_cmd)
 
 	ret = cmdline_find_option(boot_command_line, "spectre_v2_user",
 				  arg, sizeof(arg));
-	if (ret < 0)
+	if (ret < 0) {
+		if (cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF)
+			return SPECTRE_V2_USER_CMD_NONE;
 		return SPECTRE_V2_USER_CMD_AUTO;
+	}
 
 	for (i = 0; i < ARRAY_SIZE(v2_user_options); i++) {
 		if (match_option(arg, ret, v2_user_options[i].option)) {
@@ -510,8 +527,11 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
 		return SPECTRE_V2_CMD_NONE;
 
 	ret = cmdline_find_option(boot_command_line, "spectre_v2", arg, sizeof(arg));
-	if (ret < 0)
+	if (ret < 0) {
+		if (cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF)
+			return SPECTRE_V2_CMD_NONE;
 		return SPECTRE_V2_CMD_AUTO;
+	}
 
 	for (i = 0; i < ARRAY_SIZE(mitigation_options); i++) {
 		if (!match_option(arg, ret, mitigation_options[i].option))
@@ -716,9 +736,10 @@ void arch_smt_update(void)
 
 	switch(mds_mitigation) {
 	case MDS_MITIGATION_FULL:
+	case MDS_MITIGATION_DEFAULT:
 	case MDS_MITIGATION_VMWERV:
 		if (sched_smt_active() && !boot_cpu_has(X86_BUG_MSBDS_ONLY))
-			pr_warn_once(MDS_MSG_SMT);
+			printk_once(KERN_WARNING MDS_MSG_SMT);
 		update_mds_branch_idle();
 		break;
 	case MDS_MITIGATION_OFF:
@@ -771,8 +792,11 @@ static enum ssb_mitigation_cmd __init ssb_parse_cmdline(void)
 	} else {
 		ret = cmdline_find_option(boot_command_line, "spec_store_bypass_disable",
 					  arg, sizeof(arg));
-		if (ret < 0)
+		if (ret < 0) {
+			if (cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF)
+				return SPEC_STORE_BYPASS_CMD_NONE;
 			return SPEC_STORE_BYPASS_CMD_AUTO;
+		}
 
 		for (i = 0; i < ARRAY_SIZE(ssb_mitigation_options); i++) {
 			if (!match_option(arg, ret, ssb_mitigation_options[i].option))
@@ -1037,7 +1061,7 @@ void x86_spec_ctrl_setup_ap(void)
 #define pr_fmt(fmt)	"L1TF: " fmt
 
 /* Default mitigation for L1TF-affected CPUs */
-enum l1tf_mitigations l1tf_mitigation __ro_after_init = L1TF_MITIGATION_FLUSH;
+enum l1tf_mitigations l1tf_mitigation __ro_after_init = L1TF_MITIGATION_DEFAULT;
 #if IS_ENABLED(CONFIG_KVM_INTEL)
 EXPORT_SYMBOL_GPL(l1tf_mitigation);
 #endif
@@ -1092,8 +1116,23 @@ static void __init l1tf_select_mitigation(void)
 
 	override_cache_bits(&boot_cpu_data);
 
+	if (l1tf_mitigation == L1TF_MITIGATION_DEFAULT) {
+		switch (cpu_spec_mitigations) {
+		case CPU_SPEC_MITIGATIONS_OFF:
+			l1tf_mitigation = L1TF_MITIGATION_OFF;
+			break;
+		case CPU_SPEC_MITIGATIONS_AUTO:
+			l1tf_mitigation = L1TF_MITIGATION_FLUSH;
+			break;
+		case CPU_SPEC_MITIGATIONS_AUTO_NOSMT:
+			l1tf_mitigation = L1TF_MITIGATION_FLUSH_NOSMT;
+			break;
+		}
+	}
+
 	switch (l1tf_mitigation) {
 	case L1TF_MITIGATION_OFF:
+	case L1TF_MITIGATION_DEFAULT:
 	case L1TF_MITIGATION_FLUSH_NOWARN:
 	case L1TF_MITIGATION_FLUSH:
 		break;
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index 4fee5c3003ed..943b641bc003 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -115,7 +115,8 @@ void __init pti_check_boottime_disable(void)
 		}
 	}
 
-	if (cmdline_find_option_bool(boot_command_line, "nopti")) {
+	if (cmdline_find_option_bool(boot_command_line, "nopti") ||
+	    cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF) {
 		pti_mode = PTI_FORCE_OFF;
 		pti_print_if_insecure("disabled on command line.");
 		return;
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 3c87ad888ed3..6cdd3d5228d3 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -189,4 +189,12 @@ static inline void cpu_smt_disable(bool force) { }
 static inline void cpu_smt_check_topology(void) { }
 #endif
 
+enum cpu_spec_mitigations {
+	CPU_SPEC_MITIGATIONS_OFF,
+	CPU_SPEC_MITIGATIONS_AUTO,
+	CPU_SPEC_MITIGATIONS_AUTO_NOSMT,
+};
+
+extern enum cpu_spec_mitigations cpu_spec_mitigations;
+
 #endif /* _LINUX_CPU_H_ */
diff --git a/kernel/cpu.c b/kernel/cpu.c
index d1c6d152da89..136d33fb90e5 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2279,3 +2279,18 @@ void __init boot_cpu_hotplug_init(void)
 #endif
 	this_cpu_write(cpuhp_state.state, CPUHP_ONLINE);
 }
+
+enum cpu_spec_mitigations cpu_spec_mitigations __ro_after_init = CPU_SPEC_MITIGATIONS_AUTO;
+
+static int __init cpu_spec_mitigations_setup(char *arg)
+{
+	if (!strcmp(arg, "off"))
+		cpu_spec_mitigations = CPU_SPEC_MITIGATIONS_OFF;
+	else if (!strcmp(arg, "auto"))
+		cpu_spec_mitigations = CPU_SPEC_MITIGATIONS_AUTO;
+	else if (!strcmp(arg, "auto,nosmt"))
+		cpu_spec_mitigations = CPU_SPEC_MITIGATIONS_AUTO_NOSMT;
+
+	return 0;
+}
+early_param("cpu_spec_mitigations", cpu_spec_mitigations_setup);
-- 
2.17.2

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [MODERATED] Encrypted Message
  2019-03-04  1:23 ` [MODERATED] [PATCH RFC 1/4] 1 Josh Poimboeuf
@ 2019-03-04  3:55   ` Jon Masters
  2019-03-04 17:06     ` [MODERATED] " Josh Poimboeuf
  2019-03-04  7:30   ` [MODERATED] Re: [PATCH RFC 1/4] 1 Greg KH
  1 sibling, 1 reply; 17+ messages in thread
From: Jon Masters @ 2019-03-04  3:55 UTC (permalink / raw)
  To: speck

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 117 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Josh Poimboeuf <speck@linutronix.de>
Subject: Re: [PATCH RFC 1/4] 1

[-- Attachment #2: Type: text/plain, Size: 1069 bytes --]

On 3/3/19 8:23 PM, speck for Josh Poimboeuf wrote:

> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index e11654f93e71..0c71ab0d57e3 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -221,6 +221,7 @@ static void x86_amd_ssb_disable(void)
>  
>  /* Default mitigation for L1TF-affected CPUs */
>  static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_FULL;
> +static bool mds_nosmt __ro_after_init = false;
>  
>  static const char * const mds_strings[] = {
>  	[MDS_MITIGATION_OFF]	= "Vulnerable",
> @@ -238,8 +239,13 @@ static void mds_select_mitigation(void)
>  	if (mds_mitigation == MDS_MITIGATION_FULL) {
>  		if (!boot_cpu_has(X86_FEATURE_MD_CLEAR))
>  			mds_mitigation = MDS_MITIGATION_VMWERV;
> +
>  		static_branch_enable(&mds_user_clear);
> +
> +		if (mds_nosmt && !boot_cpu_has(X86_BUG_MSBDS_ONLY))
> +			cpu_smt_disable(false);

Is there some logic missing here to disable SMT?

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Encrypted Message
  2019-03-04  1:24 ` [MODERATED] [PATCH RFC 3/4] 3 Josh Poimboeuf
@ 2019-03-04  3:58   ` Jon Masters
  2019-03-04 17:17     ` [MODERATED] " Josh Poimboeuf
  2019-03-04  7:33   ` [MODERATED] Re: [PATCH RFC 3/4] 3 Greg KH
  1 sibling, 1 reply; 17+ messages in thread
From: Jon Masters @ 2019-03-04  3:58 UTC (permalink / raw)
  To: speck

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 117 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Josh Poimboeuf <speck@linutronix.de>
Subject: Re: [PATCH RFC 3/4] 3

[-- Attachment #2: Type: text/plain, Size: 445 bytes --]

On 3/3/19 8:24 PM, speck for Josh Poimboeuf wrote:

> +		if (sched_smt_active() && !boot_cpu_has(X86_BUG_MSBDS_ONLY))
> +			pr_warn_once(MDS_MSG_SMT);

It's never fully safe to use SMT. I get that if we only had MSBDS then
it's unlikely we'll hit the e.g. power state change cases needed to
exploit it but I think it would be prudent to display something anyway?

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Encrypted Message
  2019-03-04  1:25 ` [MODERATED] [PATCH RFC 4/4] 4 Josh Poimboeuf
@ 2019-03-04  4:07   ` Jon Masters
  0 siblings, 0 replies; 17+ messages in thread
From: Jon Masters @ 2019-03-04  4:07 UTC (permalink / raw)
  To: speck

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 117 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Josh Poimboeuf <speck@linutronix.de>
Subject: Re: [PATCH RFC 4/4] 4

[-- Attachment #2: Type: text/plain, Size: 1461 bytes --]

On 3/3/19 8:25 PM, speck for Josh Poimboeuf wrote:
> From: Josh Poimboeuf <jpoimboe@redhat.com>
> Subject: [PATCH RFC 4/4] x86/speculation: Add 'cpu_spec_mitigations=' cmdline
>  options
> 
> Keeping track of the number of mitigations for all the CPU speculation
> bugs has become overwhelming for many users.  It's getting more and more
> complicated to decide what mitigations are needed for a given
> architecture.
> 
> Most users fall into a few basic categories:
> 
> - want all mitigations off;
> 
> - want all reasonable mitigations on, with SMT enabled even if it's
>   vulnerable; or
> 
> - want all reasonable mitigations on, with SMT disabled if vulnerable.
> 
> Define a set of curated, arch-independent options, each of which is an
> aggregation of existing options:
> 
> - cpu_spec_mitigations=off: Disable all mitigations.
> 
> - cpu_spec_mitigations=auto: [default] Enable all the default mitigations,
>   but leave SMT enabled, even if it's vulnerable.
> 
> - cpu_spec_mitigations=auto,nosmt: Enable all the default mitigations,
>   disabling SMT if needed by a mitigation.
> 
> See the documentation for more details.

Looks good. There's an effort to upstream mitigation controls for the
arm64 but that's not in place yet. They'll want to wire that up later. I
actually had missed the s390x etokens work so that was fun to see here.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Re: [PATCH RFC 1/4] 1
  2019-03-04  1:23 ` [MODERATED] [PATCH RFC 1/4] 1 Josh Poimboeuf
  2019-03-04  3:55   ` [MODERATED] Encrypted Message Jon Masters
@ 2019-03-04  7:30   ` Greg KH
  2019-03-04  7:45     ` [MODERATED] Encrypted Message Jon Masters
  1 sibling, 1 reply; 17+ messages in thread
From: Greg KH @ 2019-03-04  7:30 UTC (permalink / raw)
  To: speck

On Sun, Mar 03, 2019 at 07:23:22PM -0600, speck for Josh Poimboeuf wrote:
> From: Josh Poimboeuf <jpoimboe@redhat.com>
> Subject: [PATCH RFC 1/4] x86/speculation/mds: Add mds=full,nosmt cmdline
>  option
> 
> Add the mds=full,nosmt cmdline option.  This is like mds=full, but with
> SMT disabled if the CPU is vulnerable.
> 
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
>  Documentation/admin-guide/hw-vuln/mds.rst       |  3 +++
>  Documentation/admin-guide/kernel-parameters.txt |  6 ++++--
>  arch/x86/kernel/cpu/bugs.c                      | 10 ++++++++++
>  3 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst
> index 1de29d28903d..244ab47d1fb3 100644
> --- a/Documentation/admin-guide/hw-vuln/mds.rst
> +++ b/Documentation/admin-guide/hw-vuln/mds.rst
> @@ -260,6 +260,9 @@ time with the option "mds=". The valid arguments for this option are:
>  
>  		It does not automatically disable SMT.
>  
> +  full,nosmt	The same as mds=full, with SMT disabled on vulnerable
> +		CPUs.  This is the complete mitigation.

While I understand the intention, the number of different combinations
we are "offering" to userspace here is huge, and everyone is going to be
confused as to what to do.  If we really think/say that SMT is a major
issue for this, why don't we just have "full" disable SMT?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Re: [PATCH RFC 2/4] 2
  2019-03-04  1:24 ` [MODERATED] [PATCH RFC 2/4] 2 Josh Poimboeuf
@ 2019-03-04  7:31   ` Greg KH
  2019-03-04 17:11     ` Josh Poimboeuf
  0 siblings, 1 reply; 17+ messages in thread
From: Greg KH @ 2019-03-04  7:31 UTC (permalink / raw)
  To: speck

On Sun, Mar 03, 2019 at 07:24:15PM -0600, speck for Josh Poimboeuf wrote:
> From: Josh Poimboeuf <jpoimboe@redhat.com>
> Subject: [PATCH RFC 2/4] x86/speculation: Move arch_smt_update() call to after
>  mitigation decisions
> 
> arch_smt_update() now has a dependency on both Spectre v2 and MDS
> mitigations.  Move its initial call to after all the mitigation
> decisions have been made.

So Patch 1 doesn't work without this?  If so, shouldn't this go first?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Re: [PATCH RFC 3/4] 3
  2019-03-04  1:24 ` [MODERATED] [PATCH RFC 3/4] 3 Josh Poimboeuf
  2019-03-04  3:58   ` [MODERATED] Encrypted Message Jon Masters
@ 2019-03-04  7:33   ` Greg KH
  2019-03-04 17:18     ` Josh Poimboeuf
  1 sibling, 1 reply; 17+ messages in thread
From: Greg KH @ 2019-03-04  7:33 UTC (permalink / raw)
  To: speck

On Sun, Mar 03, 2019 at 07:24:55PM -0600, speck for Josh Poimboeuf wrote:
> From: Josh Poimboeuf <jpoimboe@redhat.com>
> Subject: [PATCH RFC 3/4] x86/speculation/mds: Add SMT warning message
> 
> MDS is vulnerable with SMT.  Make that clear with a one-time printk
> whenever SMT first gets enabled.
> 
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
>  arch/x86/kernel/cpu/bugs.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 9e20aef01d38..346f0f05879d 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -691,6 +691,8 @@ static void update_mds_branch_idle(void)
>  		static_branch_disable(&mds_idle_clear);
>  }
>  
> +#define MDS_MSG_SMT "MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.\n"

Why a #define?  Just stick that string into the printk message.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Encrypted Message
  2019-03-04  7:30   ` [MODERATED] Re: [PATCH RFC 1/4] 1 Greg KH
@ 2019-03-04  7:45     ` Jon Masters
  0 siblings, 0 replies; 17+ messages in thread
From: Jon Masters @ 2019-03-04  7:45 UTC (permalink / raw)
  To: speck

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 110 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Greg KH <speck@linutronix.de>
Subject: Re: [PATCH RFC 1/4] 1

[-- Attachment #2: Type: text/plain, Size: 1867 bytes --]

On 3/4/19 2:30 AM, speck for Greg KH wrote:
> On Sun, Mar 03, 2019 at 07:23:22PM -0600, speck for Josh Poimboeuf wrote:
>> From: Josh Poimboeuf <jpoimboe@redhat.com>
>> Subject: [PATCH RFC 1/4] x86/speculation/mds: Add mds=full,nosmt cmdline
>>  option
>>
>> Add the mds=full,nosmt cmdline option.  This is like mds=full, but with
>> SMT disabled if the CPU is vulnerable.
>>
>> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
>> ---
>>  Documentation/admin-guide/hw-vuln/mds.rst       |  3 +++
>>  Documentation/admin-guide/kernel-parameters.txt |  6 ++++--
>>  arch/x86/kernel/cpu/bugs.c                      | 10 ++++++++++
>>  3 files changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst
>> index 1de29d28903d..244ab47d1fb3 100644
>> --- a/Documentation/admin-guide/hw-vuln/mds.rst
>> +++ b/Documentation/admin-guide/hw-vuln/mds.rst
>> @@ -260,6 +260,9 @@ time with the option "mds=". The valid arguments for this option are:
>>  
>>  		It does not automatically disable SMT.
>>  
>> +  full,nosmt	The same as mds=full, with SMT disabled on vulnerable
>> +		CPUs.  This is the complete mitigation.
> 
> While I understand the intention, the number of different combinations
> we are "offering" to userspace here is huge, and everyone is going to be
> confused as to what to do.  If we really think/say that SMT is a major
> issue for this, why don't we just have "full" disable SMT?

Frankly, it ought to for safety (can't be made safe). The reason cited
for not doing so (Thomas and Linus can speak up on this part) was
upgrades vs new installs. The concern was not to break existing folks by
losing half their logical CPU count when upgrading a kernel.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Re: Encrypted Message
  2019-03-04  3:55   ` [MODERATED] Encrypted Message Jon Masters
@ 2019-03-04 17:06     ` Josh Poimboeuf
  0 siblings, 0 replies; 17+ messages in thread
From: Josh Poimboeuf @ 2019-03-04 17:06 UTC (permalink / raw)
  To: speck

On Sun, Mar 03, 2019 at 10:55:47PM -0500, speck for Jon Masters wrote:

> On 3/3/19 8:23 PM, speck for Josh Poimboeuf wrote:
> 
> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > index e11654f93e71..0c71ab0d57e3 100644
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
> > @@ -221,6 +221,7 @@ static void x86_amd_ssb_disable(void)
> >  
> >  /* Default mitigation for L1TF-affected CPUs */
> >  static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_FULL;
> > +static bool mds_nosmt __ro_after_init = false;
> >  
> >  static const char * const mds_strings[] = {
> >  	[MDS_MITIGATION_OFF]	= "Vulnerable",
> > @@ -238,8 +239,13 @@ static void mds_select_mitigation(void)
> >  	if (mds_mitigation == MDS_MITIGATION_FULL) {
> >  		if (!boot_cpu_has(X86_FEATURE_MD_CLEAR))
> >  			mds_mitigation = MDS_MITIGATION_VMWERV;
> > +
> >  		static_branch_enable(&mds_user_clear);
> > +
> > +		if (mds_nosmt && !boot_cpu_has(X86_BUG_MSBDS_ONLY))
> > +			cpu_smt_disable(false);
> 
> Is there some logic missing here to disable SMT?

That would be the cpu_smt_disable() call :-)

-- 
Josh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Re: [PATCH RFC 2/4] 2
  2019-03-04  7:31   ` [MODERATED] " Greg KH
@ 2019-03-04 17:11     ` Josh Poimboeuf
  0 siblings, 0 replies; 17+ messages in thread
From: Josh Poimboeuf @ 2019-03-04 17:11 UTC (permalink / raw)
  To: speck

On Mon, Mar 04, 2019 at 08:31:48AM +0100, speck for Greg KH wrote:
> On Sun, Mar 03, 2019 at 07:24:15PM -0600, speck for Josh Poimboeuf wrote:
> > From: Josh Poimboeuf <jpoimboe@redhat.com>
> > Subject: [PATCH RFC 2/4] x86/speculation: Move arch_smt_update() call to after
> >  mitigation decisions
> > 
> > arch_smt_update() now has a dependency on both Spectre v2 and MDS
> > mitigations.  Move its initial call to after all the mitigation
> > decisions have been made.
> 
> So Patch 1 doesn't work without this?  If so, shouldn't this go first?

No, I think patch 1 works fine without it.  It's really a prereq for
patch 3 (and also a cleanup to prevent future bugs).

-- 
Josh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Re: Encrypted Message
  2019-03-04  3:58   ` [MODERATED] Encrypted Message Jon Masters
@ 2019-03-04 17:17     ` Josh Poimboeuf
  2019-03-06 16:22       ` [MODERATED] " Jon Masters
  0 siblings, 1 reply; 17+ messages in thread
From: Josh Poimboeuf @ 2019-03-04 17:17 UTC (permalink / raw)
  To: speck

On Sun, Mar 03, 2019 at 10:58:01PM -0500, speck for Jon Masters wrote:

> On 3/3/19 8:24 PM, speck for Josh Poimboeuf wrote:
> 
> > +		if (sched_smt_active() && !boot_cpu_has(X86_BUG_MSBDS_ONLY))
> > +			pr_warn_once(MDS_MSG_SMT);
> 
> It's never fully safe to use SMT. I get that if we only had MSBDS then
> it's unlikely we'll hit the e.g. power state change cases needed to
> exploit it but I think it would be prudent to display something anyway?

My understanding is that the idle state changes are mitigated elsewhere
in the MDS patches, so it should be safe in theory.

-- 
Josh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Re: [PATCH RFC 3/4] 3
  2019-03-04  7:33   ` [MODERATED] Re: [PATCH RFC 3/4] 3 Greg KH
@ 2019-03-04 17:18     ` Josh Poimboeuf
  0 siblings, 0 replies; 17+ messages in thread
From: Josh Poimboeuf @ 2019-03-04 17:18 UTC (permalink / raw)
  To: speck

On Mon, Mar 04, 2019 at 08:33:09AM +0100, speck for Greg KH wrote:
> On Sun, Mar 03, 2019 at 07:24:55PM -0600, speck for Josh Poimboeuf wrote:
> > From: Josh Poimboeuf <jpoimboe@redhat.com>
> > Subject: [PATCH RFC 3/4] x86/speculation/mds: Add SMT warning message
> > 
> > MDS is vulnerable with SMT.  Make that clear with a one-time printk
> > whenever SMT first gets enabled.
> > 
> > Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > ---
> >  arch/x86/kernel/cpu/bugs.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > index 9e20aef01d38..346f0f05879d 100644
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
> > @@ -691,6 +691,8 @@ static void update_mds_branch_idle(void)
> >  		static_branch_disable(&mds_idle_clear);
> >  }
> >  
> > +#define MDS_MSG_SMT "MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.\n"
> 
> Why a #define?  Just stick that string into the printk message.

The message is so long that it will really break up the flow and
readability of the code IMO.  We did the same thing in the vmx code for
the same reasons -- see L1TF_MSG_SMT and L1TF_MSG_L1D.

-- 
Josh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [MODERATED] Encrypted Message
  2019-03-04 17:17     ` [MODERATED] " Josh Poimboeuf
@ 2019-03-06 16:22       ` Jon Masters
  0 siblings, 0 replies; 17+ messages in thread
From: Jon Masters @ 2019-03-06 16:22 UTC (permalink / raw)
  To: speck

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 117 bytes --]

From: Jon Masters <jcm@redhat.com>
To: speck for Josh Poimboeuf <speck@linutronix.de>
Subject: Re: Encrypted Message

[-- Attachment #2: Type: text/plain, Size: 778 bytes --]

On 3/4/19 12:17 PM, speck for Josh Poimboeuf wrote:
> On Sun, Mar 03, 2019 at 10:58:01PM -0500, speck for Jon Masters wrote:
> 
>> On 3/3/19 8:24 PM, speck for Josh Poimboeuf wrote:
>>
>>> +		if (sched_smt_active() && !boot_cpu_has(X86_BUG_MSBDS_ONLY))
>>> +			pr_warn_once(MDS_MSG_SMT);
>>
>> It's never fully safe to use SMT. I get that if we only had MSBDS then
>> it's unlikely we'll hit the e.g. power state change cases needed to
>> exploit it but I think it would be prudent to display something anyway?
> 
> My understanding is that the idle state changes are mitigated elsewhere
> in the MDS patches, so it should be safe in theory.

Looked at it again. Agree. Sorry about that.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop


^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2019-03-06 16:22 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-04  1:21 [MODERATED] [PATCH RFC 0/4] Proposed cmdline improvements Josh Poimboeuf
2019-03-04  1:23 ` [MODERATED] [PATCH RFC 1/4] 1 Josh Poimboeuf
2019-03-04  3:55   ` [MODERATED] Encrypted Message Jon Masters
2019-03-04 17:06     ` [MODERATED] " Josh Poimboeuf
2019-03-04  7:30   ` [MODERATED] Re: [PATCH RFC 1/4] 1 Greg KH
2019-03-04  7:45     ` [MODERATED] Encrypted Message Jon Masters
2019-03-04  1:24 ` [MODERATED] [PATCH RFC 2/4] 2 Josh Poimboeuf
2019-03-04  7:31   ` [MODERATED] " Greg KH
2019-03-04 17:11     ` Josh Poimboeuf
2019-03-04  1:24 ` [MODERATED] [PATCH RFC 3/4] 3 Josh Poimboeuf
2019-03-04  3:58   ` [MODERATED] Encrypted Message Jon Masters
2019-03-04 17:17     ` [MODERATED] " Josh Poimboeuf
2019-03-06 16:22       ` [MODERATED] " Jon Masters
2019-03-04  7:33   ` [MODERATED] Re: [PATCH RFC 3/4] 3 Greg KH
2019-03-04 17:18     ` Josh Poimboeuf
2019-03-04  1:25 ` [MODERATED] [PATCH RFC 4/4] 4 Josh Poimboeuf
2019-03-04  4:07   ` [MODERATED] Encrypted Message Jon Masters

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).