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

[Borislav Petkov <bp@alien8.de>]

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