All of lore.kernel.org
 help / color / mirror / Atom feed
* FAILED: patch "[PATCH] x86/speculation: Avoid force-disabling IBPB based on STIBP" failed to apply to 4.19-stable tree
@ 2020-06-15 13:33 gregkh
  2020-06-15 18:03 ` Sasha Levin
  0 siblings, 1 reply; 3+ messages in thread
From: gregkh @ 2020-06-15 13:33 UTC (permalink / raw)
  To: asteinhauser, tglx; +Cc: stable


The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 21998a351512eba4ed5969006f0c55882d995ada Mon Sep 17 00:00:00 2001
From: Anthony Steinhauser <asteinhauser@google.com>
Date: Tue, 19 May 2020 06:40:42 -0700
Subject: [PATCH] x86/speculation: Avoid force-disabling IBPB based on STIBP
 and enhanced IBRS.

When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.

STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf

Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.

Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.

Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index ed54b3b21c39..8d57562b1d2c 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -495,7 +495,9 @@ early_param("nospectre_v1", nospectre_v1_cmdline);
 static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
 	SPECTRE_V2_NONE;
 
-static enum spectre_v2_user_mitigation spectre_v2_user __ro_after_init =
+static enum spectre_v2_user_mitigation spectre_v2_user_stibp __ro_after_init =
+	SPECTRE_V2_USER_NONE;
+static enum spectre_v2_user_mitigation spectre_v2_user_ibpb __ro_after_init =
 	SPECTRE_V2_USER_NONE;
 
 #ifdef CONFIG_RETPOLINE
@@ -641,15 +643,6 @@ spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd)
 		break;
 	}
 
-	/*
-	 * At this point, an STIBP mode other than "off" has been set.
-	 * If STIBP support is not being forced, check if STIBP always-on
-	 * is preferred.
-	 */
-	if (mode != SPECTRE_V2_USER_STRICT &&
-	    boot_cpu_has(X86_FEATURE_AMD_STIBP_ALWAYS_ON))
-		mode = SPECTRE_V2_USER_STRICT_PREFERRED;
-
 	/* Initialize Indirect Branch Prediction Barrier */
 	if (boot_cpu_has(X86_FEATURE_IBPB)) {
 		setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
@@ -672,23 +665,36 @@ spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd)
 		pr_info("mitigation: Enabling %s Indirect Branch Prediction Barrier\n",
 			static_key_enabled(&switch_mm_always_ibpb) ?
 			"always-on" : "conditional");
+
+		spectre_v2_user_ibpb = mode;
 	}
 
-	/* If enhanced IBRS is enabled no STIBP required */
-	if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
+	/*
+	 * If enhanced IBRS is enabled or SMT impossible, STIBP is not
+	 * required.
+	 */
+	if (!smt_possible || spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
 		return;
 
 	/*
-	 * If SMT is not possible or STIBP is not available clear the STIBP
-	 * mode.
+	 * At this point, an STIBP mode other than "off" has been set.
+	 * If STIBP support is not being forced, check if STIBP always-on
+	 * is preferred.
+	 */
+	if (mode != SPECTRE_V2_USER_STRICT &&
+	    boot_cpu_has(X86_FEATURE_AMD_STIBP_ALWAYS_ON))
+		mode = SPECTRE_V2_USER_STRICT_PREFERRED;
+
+	/*
+	 * If STIBP is not available, clear the STIBP mode.
 	 */
-	if (!smt_possible || !boot_cpu_has(X86_FEATURE_STIBP))
+	if (!boot_cpu_has(X86_FEATURE_STIBP))
 		mode = SPECTRE_V2_USER_NONE;
+
+	spectre_v2_user_stibp = mode;
+
 set_mode:
-	spectre_v2_user = mode;
-	/* Only print the STIBP mode when SMT possible */
-	if (smt_possible)
-		pr_info("%s\n", spectre_v2_user_strings[mode]);
+	pr_info("%s\n", spectre_v2_user_strings[mode]);
 }
 
 static const char * const spectre_v2_strings[] = {
@@ -921,7 +927,7 @@ void cpu_bugs_smt_update(void)
 {
 	mutex_lock(&spec_ctrl_mutex);
 
-	switch (spectre_v2_user) {
+	switch (spectre_v2_user_stibp) {
 	case SPECTRE_V2_USER_NONE:
 		break;
 	case SPECTRE_V2_USER_STRICT:
@@ -1164,14 +1170,16 @@ static int ib_prctl_set(struct task_struct *task, unsigned long ctrl)
 {
 	switch (ctrl) {
 	case PR_SPEC_ENABLE:
-		if (spectre_v2_user == SPECTRE_V2_USER_NONE)
+		if (spectre_v2_user_ibpb == SPECTRE_V2_USER_NONE &&
+		    spectre_v2_user_stibp == SPECTRE_V2_USER_NONE)
 			return 0;
 		/*
 		 * Indirect branch speculation is always disabled in strict
 		 * mode.
 		 */
-		if (spectre_v2_user == SPECTRE_V2_USER_STRICT ||
-		    spectre_v2_user == SPECTRE_V2_USER_STRICT_PREFERRED)
+		if (spectre_v2_user_ibpb == SPECTRE_V2_USER_STRICT ||
+		    spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT ||
+		    spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED)
 			return -EPERM;
 		task_clear_spec_ib_disable(task);
 		task_update_spec_tif(task);
@@ -1182,10 +1190,12 @@ static int ib_prctl_set(struct task_struct *task, unsigned long ctrl)
 		 * Indirect branch speculation is always allowed when
 		 * mitigation is force disabled.
 		 */
-		if (spectre_v2_user == SPECTRE_V2_USER_NONE)
+		if (spectre_v2_user_ibpb == SPECTRE_V2_USER_NONE &&
+		    spectre_v2_user_stibp == SPECTRE_V2_USER_NONE)
 			return -EPERM;
-		if (spectre_v2_user == SPECTRE_V2_USER_STRICT ||
-		    spectre_v2_user == SPECTRE_V2_USER_STRICT_PREFERRED)
+		if (spectre_v2_user_ibpb == SPECTRE_V2_USER_STRICT ||
+		    spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT ||
+		    spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED)
 			return 0;
 		task_set_spec_ib_disable(task);
 		if (ctrl == PR_SPEC_FORCE_DISABLE)
@@ -1216,7 +1226,8 @@ void arch_seccomp_spec_mitigate(struct task_struct *task)
 {
 	if (ssb_mode == SPEC_STORE_BYPASS_SECCOMP)
 		ssb_prctl_set(task, PR_SPEC_FORCE_DISABLE);
-	if (spectre_v2_user == SPECTRE_V2_USER_SECCOMP)
+	if (spectre_v2_user_ibpb == SPECTRE_V2_USER_SECCOMP ||
+	    spectre_v2_user_stibp == SPECTRE_V2_USER_SECCOMP)
 		ib_prctl_set(task, PR_SPEC_FORCE_DISABLE);
 }
 #endif
@@ -1247,22 +1258,24 @@ static int ib_prctl_get(struct task_struct *task)
 	if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
 		return PR_SPEC_NOT_AFFECTED;
 
-	switch (spectre_v2_user) {
-	case SPECTRE_V2_USER_NONE:
+	if (spectre_v2_user_ibpb == SPECTRE_V2_USER_NONE &&
+	    spectre_v2_user_stibp == SPECTRE_V2_USER_NONE)
 		return PR_SPEC_ENABLE;
-	case SPECTRE_V2_USER_PRCTL:
-	case SPECTRE_V2_USER_SECCOMP:
+	else if (spectre_v2_user_ibpb == SPECTRE_V2_USER_STRICT ||
+	    spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT ||
+	    spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED)
+		return PR_SPEC_DISABLE;
+	else if (spectre_v2_user_ibpb == SPECTRE_V2_USER_PRCTL ||
+	    spectre_v2_user_ibpb == SPECTRE_V2_USER_SECCOMP ||
+	    spectre_v2_user_stibp == SPECTRE_V2_USER_PRCTL ||
+	    spectre_v2_user_stibp == SPECTRE_V2_USER_SECCOMP) {
 		if (task_spec_ib_force_disable(task))
 			return PR_SPEC_PRCTL | PR_SPEC_FORCE_DISABLE;
 		if (task_spec_ib_disable(task))
 			return PR_SPEC_PRCTL | PR_SPEC_DISABLE;
 		return PR_SPEC_PRCTL | PR_SPEC_ENABLE;
-	case SPECTRE_V2_USER_STRICT:
-	case SPECTRE_V2_USER_STRICT_PREFERRED:
-		return PR_SPEC_DISABLE;
-	default:
+	} else
 		return PR_SPEC_NOT_AFFECTED;
-	}
 }
 
 int arch_prctl_spec_ctrl_get(struct task_struct *task, unsigned long which)
@@ -1501,7 +1514,7 @@ static char *stibp_state(void)
 	if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
 		return "";
 
-	switch (spectre_v2_user) {
+	switch (spectre_v2_user_stibp) {
 	case SPECTRE_V2_USER_NONE:
 		return ", STIBP: disabled";
 	case SPECTRE_V2_USER_STRICT:


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

* Re: FAILED: patch "[PATCH] x86/speculation: Avoid force-disabling IBPB based on STIBP" failed to apply to 4.19-stable tree
  2020-06-15 13:33 FAILED: patch "[PATCH] x86/speculation: Avoid force-disabling IBPB based on STIBP" failed to apply to 4.19-stable tree gregkh
@ 2020-06-15 18:03 ` Sasha Levin
  2020-06-16 10:49   ` Greg KH
  0 siblings, 1 reply; 3+ messages in thread
From: Sasha Levin @ 2020-06-15 18:03 UTC (permalink / raw)
  To: gregkh; +Cc: asteinhauser, tglx, stable

On Mon, Jun 15, 2020 at 03:33:25PM +0200, gregkh@linuxfoundation.org wrote:
>
>The patch below does not apply to the 4.19-stable tree.
>If someone wants it applied there, or to any other stable or longterm
>tree, then please email the backport, including the original git commit
>id to <stable@vger.kernel.org>.
>
>thanks,
>
>greg k-h
>
>------------------ original commit in Linus's tree ------------------
>
>From 21998a351512eba4ed5969006f0c55882d995ada Mon Sep 17 00:00:00 2001
>From: Anthony Steinhauser <asteinhauser@google.com>
>Date: Tue, 19 May 2020 06:40:42 -0700
>Subject: [PATCH] x86/speculation: Avoid force-disabling IBPB based on STIBP
> and enhanced IBRS.
>
>When STIBP is unavailable or enhanced IBRS is available, Linux
>force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
>multithreading is disabled. While attempts to enable IBPB using
>prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
>EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
>which are used e.g. by Chromium or OpenSSH succeed with no errors but the
>application remains silently vulnerable to cross-process Spectre v2 attacks
>(classical BTB poisoning). At the same time the SYSFS reporting
>(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
>conditionally enabled when in fact it is unconditionally disabled.
>
>STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
>unavailable, it makes no sense to force-disable also IBPB, because IBPB
>protects against cross-process Spectre-BTB attacks regardless of the SMT
>state. At the same time since missing STIBP was only observed on AMD CPUs,
>AMD does not recommend using STIBP, but recommends using IBPB, so disabling
>IBPB because of missing STIBP goes directly against AMD's advice:
>https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
>
>Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
>and BTB-poisoning attacks from user space against kernel (and
>BTB-poisoning attacks from guest against hypervisor), it is not designed
>to prevent cross-process (or cross-VM) BTB poisoning between processes (or
>VMs) running on the same core. Therefore, even with enhanced IBRS it is
>necessary to flush the BTB during context-switches, so there is no reason
>to force disable IBPB when enhanced IBRS is available.
>
>Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
>IBRS is available.
>
>Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
>Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
>Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>Cc: stable@vger.kernel.org

I took these two additional patches for 4.19-4.4:

aa77bfb354c4 ("x86/speculation: Change misspelled STIPB to STIBP")
20c3a2c33e9f ("x86/speculation: Add support for STIBP always-on preferred mode")

With tiny massaging on 4.9 and 4.4.

-- 
Thanks,
Sasha

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

* Re: FAILED: patch "[PATCH] x86/speculation: Avoid force-disabling IBPB based on STIBP" failed to apply to 4.19-stable tree
  2020-06-15 18:03 ` Sasha Levin
@ 2020-06-16 10:49   ` Greg KH
  0 siblings, 0 replies; 3+ messages in thread
From: Greg KH @ 2020-06-16 10:49 UTC (permalink / raw)
  To: Sasha Levin; +Cc: asteinhauser, tglx, stable

On Mon, Jun 15, 2020 at 02:03:18PM -0400, Sasha Levin wrote:
> On Mon, Jun 15, 2020 at 03:33:25PM +0200, gregkh@linuxfoundation.org wrote:
> > 
> > The patch below does not apply to the 4.19-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > ------------------ original commit in Linus's tree ------------------
> > 
> > > From 21998a351512eba4ed5969006f0c55882d995ada Mon Sep 17 00:00:00 2001
> > From: Anthony Steinhauser <asteinhauser@google.com>
> > Date: Tue, 19 May 2020 06:40:42 -0700
> > Subject: [PATCH] x86/speculation: Avoid force-disabling IBPB based on STIBP
> > and enhanced IBRS.
> > 
> > When STIBP is unavailable or enhanced IBRS is available, Linux
> > force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
> > multithreading is disabled. While attempts to enable IBPB using
> > prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
> > EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
> > which are used e.g. by Chromium or OpenSSH succeed with no errors but the
> > application remains silently vulnerable to cross-process Spectre v2 attacks
> > (classical BTB poisoning). At the same time the SYSFS reporting
> > (/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
> > conditionally enabled when in fact it is unconditionally disabled.
> > 
> > STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
> > unavailable, it makes no sense to force-disable also IBPB, because IBPB
> > protects against cross-process Spectre-BTB attacks regardless of the SMT
> > state. At the same time since missing STIBP was only observed on AMD CPUs,
> > AMD does not recommend using STIBP, but recommends using IBPB, so disabling
> > IBPB because of missing STIBP goes directly against AMD's advice:
> > https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
> > 
> > Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
> > and BTB-poisoning attacks from user space against kernel (and
> > BTB-poisoning attacks from guest against hypervisor), it is not designed
> > to prevent cross-process (or cross-VM) BTB poisoning between processes (or
> > VMs) running on the same core. Therefore, even with enhanced IBRS it is
> > necessary to flush the BTB during context-switches, so there is no reason
> > to force disable IBPB when enhanced IBRS is available.
> > 
> > Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
> > IBRS is available.
> > 
> > Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
> > Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Cc: stable@vger.kernel.org
> 
> I took these two additional patches for 4.19-4.4:
> 
> aa77bfb354c4 ("x86/speculation: Change misspelled STIPB to STIBP")
> 20c3a2c33e9f ("x86/speculation: Add support for STIBP always-on preferred mode")
> 
> With tiny massaging on 4.9 and 4.4.

Thanks for doing this, and the other FAILED fixups.

greg k-h

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

end of thread, other threads:[~2020-06-16 10:49 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-15 13:33 FAILED: patch "[PATCH] x86/speculation: Avoid force-disabling IBPB based on STIBP" failed to apply to 4.19-stable tree gregkh
2020-06-15 18:03 ` Sasha Levin
2020-06-16 10:49   ` Greg KH

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.