[PATCH] x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb

* [PATCH] x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb
@ 2020-11-10  1:33 Anand K Mistry
  2020-11-25 19:24 ` [tip: x86/urgent] " tip-bot2 for Anand K Mistry
  0 siblings, 1 reply; 2+ messages in thread
From: Anand K Mistry @ 2020-11-10  1:33 UTC (permalink / raw)
  To: x86
  Cc: joelaf, Thomas.Lendacky, asteinhauser, tglx, Anand K Mistry,
	Borislav Petkov, H. Peter Anvin, Ingo Molnar, Mark Gross,
	Mike Rapoport, Pawan Gupta, Tom Lendacky, Tony Luck, Waiman Long,
	linux-kernel

When spectre_v2_user={seccomp,prctl},ibpb, IBPB is force-enabled and
STIPB is conditionally-enabled (or not available). However, since
commit 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on
STIBP and enhanced IBRS.") the spectre_v2_user_ibpb variable is set to
SPECTRE_V2_USER_{PRCTL,SECCOMP} instead of SPECTRE_V2_USER_STRICT, which
is the actual behaviour. Because the issuing of IBPB relies on the
switch_mm_*_ibpb static branches, the mitigations behave as expected.

Since commit 1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally
enabled on CPUs with always-on STIBP") this discrepency caused the
misreporting of IB speculation via prctl().

On CPUs with STIBP always-on and spectre_v2_user=seccomp,ibpb,
prctl(PR_GET_SPECULATION_CTRL) would return PR_SPEC_PRCTL |
PR_SPEC_ENABLE instead of PR_SPEC_DISABLE since both IBPB and STIPB are
always on. It also allowed prctl(PR_SET_SPECULATION_CTRL) to set the IB
speculation mode, even though the flag is ignored.

Similarly for CPUs without SMT, prctl(PR_GET_SPECULATION_CTRL) should
also return PR_SPEC_DISABLE since IBPB is always on and STIBP is not
available.

Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Fixes: 1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP")
Signed-off-by: Anand K Mistry <amistry@google.com>

---
This is a follow up to my last patch (https://lore.kernel.org/lkml/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid/).
Unlike that one, this one does not change the behaviour or allow
enabling/disabling of IB speculation. Rather, it fixes the way the
prctl() responds. The last patch exposed an existing oversight in way
migitations were being tracked. Basically, the switch_mm_*_ibpb static
branches and the spectre_v2_user_ibpb variable were not consistent. This
patch tried to line those ducks in a row, as well as you can wrangle
ducks. Unfortunately, duck-wrangling is not one of my areas of
expertise.

 arch/x86/kernel/cpu/bugs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 581fb7223ad0..d41b70fe4918 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -739,11 +739,13 @@ spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd)
 	if (boot_cpu_has(X86_FEATURE_IBPB)) {
 		setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
 
+		spectre_v2_user_ibpb = mode;
 		switch (cmd) {
 		case SPECTRE_V2_USER_CMD_FORCE:
 		case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
 		case SPECTRE_V2_USER_CMD_SECCOMP_IBPB:
 			static_branch_enable(&switch_mm_always_ibpb);
+			spectre_v2_user_ibpb = SPECTRE_V2_USER_STRICT;
 			break;
 		case SPECTRE_V2_USER_CMD_PRCTL:
 		case SPECTRE_V2_USER_CMD_AUTO:
@@ -757,8 +759,6 @@ 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;
 	}
 
 	/*
-- 
2.29.2.222.g5d2a92d10f8-goog


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