All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kim Phillips <kim.phillips@amd.com>
To: <gregkh@linuxfoundation.org>
Cc: <andrew.cooper3@citrix.com>, <bp@alien8.de>, <bp@suse.de>,
	<bpf@vger.kernel.org>, <jpoimboe@redhat.com>,
	<kim.phillips@amd.com>, <linux-kernel@vger.kernel.org>,
	<mingo@kernel.org>, <peterz@infradead.org>,
	<thomas.lendacky@amd.com>, <x86@kernel.org>,
	<stable@vger.kernel.org>
Subject: [PATCH v4] x86/bugs: Enable STIBP for IBPB mitigated RetBleed
Date: Mon, 8 Aug 2022 09:32:33 -0500	[thread overview]
Message-ID: <20220808143233.14211-1-kim.phillips@amd.com> (raw)
In-Reply-To: <YvEcSGxAh9qbOxPH@kroah.com>

AMD's "Technical Guidance for Mitigating Branch Type Confusion,
Rev. 1.0 2022-07-12" whitepaper, under section 6.1.2 "IBPB On
Privileged Mode Entry / SMT Safety" says:

"Similar to the Jmp2Ret mitigation, if the code on the sibling thread
cannot be trusted, software should set STIBP to 1 or disable SMT to
ensure SMT safety when using this mitigation."

So, like already being done for retbleed=unret, the also for
retbleed=ibpb, force STIBP on machines that have it, and report
its SMT vulnerability status accordingly.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
Cc: stable@vger.kernel.org # 5.10, 5.15, 5.19
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
---
v4:  Cc: stable (Greg K-H)
v3:  "unret and ibpb mitigations" -> "UNRET and IBPB mitigations" (Mingo)
v2:  Justify and explain STIBP's role with IBPB (Boris)

 .../admin-guide/kernel-parameters.txt         | 20 ++++++++++++++-----
 arch/x86/kernel/cpu/bugs.c                    | 10 ++++++----
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index bab2b0bf5988..ed6a19ae0dd6 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5260,20 +5260,30 @@
 			Speculative Code Execution with Return Instructions)
 			vulnerability.
 
+			AMD-based UNRET and IBPB mitigations alone do not stop
+			sibling threads influencing the predictions of other sibling
+			threads.  For that reason, we use STIBP on processors
+			that support it, and mitigate SMT on processors that don't.
+
 			off          - no mitigation
 			auto         - automatically select a migitation
 			auto,nosmt   - automatically select a mitigation,
 				       disabling SMT if necessary for
 				       the full mitigation (only on Zen1
 				       and older without STIBP).
-			ibpb	     - mitigate short speculation windows on
+			ibpb         - [AMD] Mitigate short speculation windows on
 				       basic block boundaries too. Safe, highest
-				       perf impact.
-			unret        - force enable untrained return thunks,
+				       perf impact. It also enables STIBP if
+				       present.
+			ibpb,nosmt   - [AMD] Like ibpb, but will disable SMT when STIBP
+				       is not available. This is the alternative for
+				       systems which do not have STIBP.
+			unret        - [AMD] Force enable untrained return thunks,
 				       only effective on AMD f15h-f17h
 				       based systems.
-			unret,nosmt  - like unret, will disable SMT when STIBP
-			               is not available.
+			unret,nosmt  - [AMD] Like unret, but will disable SMT when STIBP
+				       is not available. This is the alternative for
+				       systems which do not have STIBP.
 
 			Selecting 'auto' will choose a mitigation method at run
 			time according to the CPU.
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 6761668100b9..d50686ca5870 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -152,7 +152,7 @@ void __init check_bugs(void)
 	/*
 	 * spectre_v2_user_select_mitigation() relies on the state set by
 	 * retbleed_select_mitigation(); specifically the STIBP selection is
-	 * forced for UNRET.
+	 * forced for UNRET or IBPB.
 	 */
 	spectre_v2_user_select_mitigation();
 	ssb_select_mitigation();
@@ -1179,7 +1179,8 @@ spectre_v2_user_select_mitigation(void)
 	    boot_cpu_has(X86_FEATURE_AMD_STIBP_ALWAYS_ON))
 		mode = SPECTRE_V2_USER_STRICT_PREFERRED;
 
-	if (retbleed_mitigation == RETBLEED_MITIGATION_UNRET) {
+	if (retbleed_mitigation == RETBLEED_MITIGATION_UNRET ||
+	    retbleed_mitigation == RETBLEED_MITIGATION_IBPB) {
 		if (mode != SPECTRE_V2_USER_STRICT &&
 		    mode != SPECTRE_V2_USER_STRICT_PREFERRED)
 			pr_info("Selecting STIBP always-on mode to complement retbleed mitigation\n");
@@ -2320,10 +2321,11 @@ static ssize_t srbds_show_state(char *buf)
 
 static ssize_t retbleed_show_state(char *buf)
 {
-	if (retbleed_mitigation == RETBLEED_MITIGATION_UNRET) {
+	if (retbleed_mitigation == RETBLEED_MITIGATION_UNRET ||
+	    retbleed_mitigation == RETBLEED_MITIGATION_IBPB) {
 	    if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
 		boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
-		    return sprintf(buf, "Vulnerable: untrained return thunk on non-Zen uarch\n");
+		    return sprintf(buf, "Vulnerable: untrained return thunk / IBPB on non-AMD based uarch\n");
 
 	    return sprintf(buf, "%s; SMT %s\n",
 			   retbleed_strings[retbleed_mitigation],
-- 
2.34.1


  reply	other threads:[~2022-08-08 14:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-04 19:22 [PATCH] x86/bugs: Enable STIBP for IBPB mitigated RetBleed Kim Phillips
2022-08-05 14:42 ` Borislav Petkov
2022-08-05 17:04   ` Kim Phillips
2022-08-05 17:55     ` Borislav Petkov
2022-08-05 21:50       ` [PATCH v2] " Kim Phillips
2022-08-06 19:00         ` Ingo Molnar
2022-08-08 14:17           ` [PATCH v3] " Kim Phillips
2022-08-08 14:23             ` Greg KH
2022-08-08 14:32               ` Kim Phillips [this message]
2022-08-08 18:10 ` [tip: x86/urgent] x86/bugs: Enable STIBP for IBPB mitigated RETBleed tip-bot2 for Kim Phillips

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220808143233.14211-1-kim.phillips@amd.com \
    --to=kim.phillips@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=bp@suse.de \
    --cc=bpf@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.