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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yu1Zj5mNZiAWdJgK@zn.tnic>
Date:   Fri, 5 Aug 2022 19:55:27 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Kim Phillips <kim.phillips@....com>
Cc:     x86@...nel.org, peterz@...radead.org, bpf@...r.kernel.org,
        jpoimboe@...hat.com, andrew.cooper3@...rix.com,
        linux-kernel@...r.kernel.org, thomas.lendacky@....com
Subject: Re: [PATCH] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

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