Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 5 Aug 2022 19:55:27 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     Kim Phillips <kim.phillips@amd.com>
Cc:     x86@kernel.org, peterz@infradead.org, bpf@vger.kernel.org,
        jpoimboe@redhat.com, andrew.cooper3@citrix.com,
        linux-kernel@vger.kernel.org, thomas.lendacky@amd.com
Subject: Re: [PATCH] x86/bugs: Enable STIBP for IBPB mitigated RetBleed
Message-ID: <Yu1Zj5mNZiAWdJgK@zn.tnic>
References: <20220804192201.439596-1-kim.phillips@amd.com>
 <Yu0sT6vCofyWiAMI@zn.tnic>
 <86921fe7-6a6b-2731-b09e-a6e03f38a6b9@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <86921fe7-6a6b-2731-b09e-a6e03f38a6b9@amd.com>
Precedence: bulk

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