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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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.
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 <[email protected]>
>> ---
>> 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
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
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 <[email protected]>
---
.../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
* Kim Phillips <[email protected]> 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
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 <[email protected]>
---
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
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 <[email protected]>
AuthorDate: Mon, 08 Aug 2022 09:32:33 -05:00
Committer: Borislav Petkov <[email protected]>
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 <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: [email protected] # 5.10, 5.15, 5.19
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Link: https://lore.kernel.org/r/[email protected]
---
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],