[PATCH] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

[PATCH] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

[Kim Phillips]

For retbleed=ibpb, force STIBP on machines that have it,
and report its SMT vulnerability status accordingly.

Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
---
 Documentation/admin-guide/kernel-parameters.txt |  4 +++-
 arch/x86/kernel/cpu/bugs.c                      | 10 ++++++----
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 597ac77b541c..127fa4328360 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5212,10 +5212,12 @@
 			ibpb	     - mitigate short speculation windows on
 				       basic block boundaries too. Safe, highest
 				       perf impact.
+			ibpb,nosmt   - like ibpb, but will disable SMT when STIBP
+			               is not available.
 			unret        - force enable untrained return thunks,
 				       only effective on AMD f15h-f17h
 				       based systems.
-			unret,nosmt  - like unret, will disable SMT when STIBP
+			unret,nosmt  - like unret, but will disable SMT when STIBP
 			               is not available.
 
 			Selecting 'auto' will choose a mitigation method at run
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index fd5464ff714d..f710c012f1eb 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();
@@ -1181,7 +1181,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");
@@ -2346,10 +2347,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

Re: [PATCH] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

[Borislav Petkov]

On Thu, Aug 04, 2022 at 02:22:01PM -0500, Kim Phillips wrote:
> For retbleed=ibpb, force STIBP on machines that have it,

Because?

> and report its SMT vulnerability status accordingly.
> 
> Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
> Signed-off-by: Kim Phillips <kim.phillips@amd.com>
> ---
>  Documentation/admin-guide/kernel-parameters.txt |  4 +++-
>  arch/x86/kernel/cpu/bugs.c                      | 10 ++++++----
>  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 597ac77b541c..127fa4328360 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5212,10 +5212,12 @@
>  			ibpb	     - mitigate short speculation windows on
>  				       basic block boundaries too. Safe, highest
>  				       perf impact.

You should put some blurb here about STIBP and why it is being enabled,
where present.

> +			ibpb,nosmt   - like ibpb, but will disable SMT when STIBP
> +			               is not available.
>  			unret        - force enable untrained return thunks,
>  				       only effective on AMD f15h-f17h
>  				       based systems.
> -			unret,nosmt  - like unret, will disable SMT when STIBP
> +			unret,nosmt  - like unret, but will disable SMT when STIBP
>  			               is not available.
>  
>  			Selecting 'auto' will choose a mitigation method at run
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index fd5464ff714d..f710c012f1eb 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();
> @@ -1181,7 +1181,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");
> @@ -2346,10 +2347,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");

Well, you can't lump those together.

You can't especially say "Vulnerable" and "IBPB" in one line.

To quote from the BTC paper:

"Software may choose to perform an IBPB command on entry into privileged
code in order to avoid any previous branch prediction information from
subsequently being used. This effectively mitigates all forms of BTC for
scenarios like user-to-supervisor or VM-to-hypervisor attacks."

Especially if we disable SMT only on !STIBP parts:

        if (mitigate_smt && !boot_cpu_has(X86_FEATURE_STIBP) &&
            (retbleed_nosmt || cpu_mitigations_auto_nosmt()))
                cpu_smt_disable(false);

If there are AMD parts which have IBPB but DO NOT have STIBP, then you
can say "Vulnerable... IBPB" but then you need to check for !STIBP and
issue that on a separate line.

I'd say...

-- 
Regards/Gruss,
    Boris.

Re: [PATCH] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

[Kim Phillips]

On 8/5/22 9:42 AM, Borislav Petkov wrote:
> On Thu, Aug 04, 2022 at 02:22:01PM -0500, Kim Phillips wrote:
>> For retbleed=ibpb, force STIBP on machines that have it,
> 
> Because?

See "6.1.2 IBPB On Privileged Mode Entry / SMT Safety":

https://www.amd.com/system/files/documents/technical-guidance-for-mitigating-branch-type-confusion_v7_20220712.pdf

Did you want me to re-quote the whitepaper, or reference it,
or paraphrase it, or...?

>> and report its SMT vulnerability status accordingly.
>>
>> Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
>> Signed-off-by: Kim Phillips <kim.phillips@amd.com>
>> ---
>>   Documentation/admin-guide/kernel-parameters.txt |  4 +++-
>>   arch/x86/kernel/cpu/bugs.c                      | 10 ++++++----
>>   2 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 597ac77b541c..127fa4328360 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -5212,10 +5212,12 @@
>>   			ibpb	     - mitigate short speculation windows on
>>   				       basic block boundaries too. Safe, highest
>>   				       perf impact.
> 
> You should put some blurb here about STIBP and why it is being enabled,
> where present.

unret didn't have it, was just copying unret's entry, but,
ok, will do for both now.

How about:

"{unret,ibpb} alone does 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."

>> @@ -2346,10 +2347,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");
> 
> Well, you can't lump those together.
>  > You can't especially say "Vulnerable" and "IBPB" in one line.
> 
> To quote from the BTC paper:
> 
> "Software may choose to perform an IBPB command on entry into privileged
> code in order to avoid any previous branch prediction information from
> subsequently being used. This effectively mitigates all forms of BTC for
> scenarios like user-to-supervisor or VM-to-hypervisor attacks."
> 
> Especially if we disable SMT only on !STIBP parts:
> 
>          if (mitigate_smt && !boot_cpu_has(X86_FEATURE_STIBP) &&
>              (retbleed_nosmt || cpu_mitigations_auto_nosmt()))
>                  cpu_smt_disable(false);
> 
> If there are AMD parts which have IBPB but DO NOT have STIBP, then you
> can say "Vulnerable... IBPB" but then you need to check for !STIBP and
> issue that on a separate line.
> 
> I'd say...

Those messages only get printed on non-AMD hardware?

Kim

Re: [PATCH] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

[Borislav Petkov]

On Fri, Aug 05, 2022 at 12:04:34PM -0500, Kim Phillips wrote:
> On 8/5/22 9:42 AM, Borislav Petkov wrote:
> > On Thu, Aug 04, 2022 at 02:22:01PM -0500, Kim Phillips wrote:
> > > For retbleed=ibpb, force STIBP on machines that have it,
> > 
> > Because?
> 
> See "6.1.2 IBPB On Privileged Mode Entry / SMT Safety":
> 
> https://www.amd.com/system/files/documents/technical-guidance-for-mitigating-branch-type-confusion_v7_20220712.pdf
> 
> Did you want me to re-quote the whitepaper, or reference it,
> or paraphrase it, or...?

I would like for our commit messages to be fully standalone and explain
in detail why a change is being done. So that when doing git archeology
months, years from now it is perfectly clear why a change was needed.

This holds especially true for the CPU vuln nightmares.

So please explain the "why" of your change. In your own words.

> "{unret,ibpb} alone does 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."

Pretty much. I'd even explain each case explicitly:

                        ibpb         - mitigate short speculation windows on
                                       basic block boundaries too. Safe, highest
                                       perf impact. On AMD, it also enables STIBP if
				       present.
                        ibpb,nosmt   - like ibpb, but will disable SMT when STIBP
                                       is not available. This is the alternative for
				       systems which do not have STIBP.

> Those messages only get printed on non-AMD hardware?

See, I got confused by our spaghetti code from hell. ;-\

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[PATCH v2] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

[Kim Phillips]

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")
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
---
 .../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 ef9f80b1ddde..c1061e7df55d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5237,20 +5237,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

Re: [PATCH v2] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

[Ingo Molnar]

* Kim Phillips <kim.phillips@amd.com> wrote:

>  			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.

>  	 * retbleed_select_mitigation(); specifically the STIBP selection is
> -	 * forced for UNRET.
> +	 * forced for UNRET or IBPB.

Nit: could you please capitalize the acronyms & instruction names 
consistently? Human eyesight is case sensitive.

Ie. it should be UNRET and IBPB everywhere.

Thanks,

	Ingo

[PATCH v3] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

[Kim Phillips]

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")
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
---
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

Re: [PATCH v3] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

[Greg KH]

On Mon, Aug 08, 2022 at 09:17:02AM -0500, Kim Phillips wrote:
> 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")
> Signed-off-by: Kim Phillips <kim.phillips@amd.com>
> ---
> 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(-)

Any specific reason you don't want this also backported to the stable
kernel branches that have the other retbleed fixes in them?

thanks,

greg k-h

[PATCH v4] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

[Kim Phillips]

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

[tip: x86/urgent] x86/bugs: Enable STIBP for IBPB mitigated RETBleed

[tip-bot2 for Kim Phillips]

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     e6cfcdda8cbe81eaf821c897369a65fec987b404
Gitweb:        https://git.kernel.org/tip/e6cfcdda8cbe81eaf821c897369a65fec987b404
Author:        Kim Phillips <kim.phillips@amd.com>
AuthorDate:    Mon, 08 Aug 2022 09:32:33 -05:00
Committer:     Borislav Petkov <bp@suse.de>
CommitterDate: Mon, 08 Aug 2022 19:12:17 +02:00

x86/bugs: Enable STIBP for IBPB mitigated RETBleed

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, and now also for
retbleed=ibpb, force STIBP on machines that have it, and report its SMT
vulnerability status accordingly.

 [ bp: Remove the "we" and remove "[AMD]" applicability parameter which
   doesn't work here. ]

Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org # 5.10, 5.15, 5.19
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Link: https://lore.kernel.org/r/20220804192201.439596-1-kim.phillips@amd.com
---
 Documentation/admin-guide/kernel-parameters.txt | 29 +++++++++++-----
 arch/x86/kernel/cpu/bugs.c                      | 10 +++---
 2 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 5e9147f..523b196 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5209,20 +5209,33 @@
 			Speculative Code Execution with Return Instructions)
 			vulnerability.
 
+			AMD-based UNRET and IBPB mitigations alone do not stop
+			sibling threads from influencing the predictions of other
+			sibling threads. For that reason, STIBP is used on pro-
+			cessors 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
-				       basic block boundaries too. Safe, highest
-				       perf impact.
-			unret        - 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.
+			ibpb         - On AMD, mitigate short speculation
+				       windows on basic block boundaries too.
+				       Safe, highest perf impact. It also
+				       enables STIBP if present. Not suitable
+				       on Intel.
+			ibpb,nosmt   - Like "ibpb" above but will disable SMT
+				       when STIBP is not available. This is
+				       the alternative for systems which do not
+				       have STIBP.
+			unret        - Force enable untrained return thunks,
+				       only effective on AMD f15h-f17h based
+				       systems.
+			unret,nosmt  - 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 6761668..d50686c 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],