[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20201110123349.1.Id0cbf996d2151f4c143c90f9028651a5b49a5908@changeid>
Date: Tue, 10 Nov 2020 12:33:53 +1100
From: Anand K Mistry <amistry@...gle.com>
To: x86@...nel.org
Cc: joelaf@...gle.com, Thomas.Lendacky@....com,
asteinhauser@...gle.com, tglx@...utronix.de,
Anand K Mistry <amistry@...gle.com>,
Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Mark Gross <mgross@...ux.intel.com>,
Mike Rapoport <rppt@...nel.org>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Tom Lendacky <thomas.lendacky@....com>,
Tony Luck <tony.luck@...el.com>,
Waiman Long <longman@...hat.com>, linux-kernel@...r.kernel.org
Subject: [PATCH] x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb
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@...gle.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
Powered by blists - more mailing lists