lkml.org 
[lkml]   [2022]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2022-08-05 19:56    [W:0.059 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site