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

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