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
