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