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: <BL1PR12MB51573FC5B880ED914628A95BE2E79@BL1PR12MB5157.namprd12.prod.outlook.com>
Date:   Wed, 6 Apr 2022 14:23:37 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@....com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Dave Hansen <dave.hansen@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Karny, Wyes" <Wyes.Karny@....com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Carroll, Lewis" <Lewis.Carroll@....com>,
        "Shenoy, Gautham Ranjal" <gautham.shenoy@....com>,
        "Narayan, Ananth" <Ananth.Narayan@....com>,
        "Rao, Bharata Bhasker" <bharata@....com>,
        "len.brown@...el.com" <len.brown@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "chang.seok.bae@...el.com" <chang.seok.bae@...el.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "metze@...ba.org" <metze@...ba.org>,
        "zhengqi.arch@...edance.com" <zhengqi.arch@...edance.com>,
        "mark.rutland@....com" <mark.rutland@....com>
Subject: RE: [PATCH] x86: Prefer MWAIT over HALT on AMD processors

[Public]

> > [Public]
> 
> Really useful information that your post is public while some of the
> earlier posts in this _public_ thread were marked '[AMD confidential]'.

AMD's mail system adds this tag.  You'll see it in my next reply too.

You might be referring to Lewis' earlier email that had "AMD Official Use Only".
I don't believe anything has been tagged as confidential.

> 
> >> >> This seem _bit_ at odds with the commit message (and the AMD SSBD
> >> >> whitepaper):
> >> >>
> >> >>>     Add the necessary synchronization logic for AMD family 17H.
> >> >> So, is X86_FEATURE_ZEN for family==0x17, or family>=0x17?
> >> > There are Zen family CPUs and APUs from family 0x19.  Perhaps at the
> >> > time of the whitepaper there weren't yet though.
> >>
> >> Is this a gap in the documentation, then?  Is there some documentation
> >> of the availability of SSBD mitigations on family 0x19?
> >
> > It looks like a misinterpretation of the document.
> 
> Not at all. The document does not mention family 19h at all. So where is
> the misinterpretation?
> 
> Dave was asking for documentation for family 0x19, right?
> 
> > Notice it mentions in Non-architectural MSRs explicitly:
> >
> > "some models of family 17h have logic that allow loads to bypass older
> stores
> > but lack the architectural SPEC_CTRL or VIRT_SPEC_CTR"
> 
> That's relevant to Dave's question in which way?

The document is proposing logic that includes saying that if the CPU supports
the architectural MSR then use that.  If it doesn't then do this other stuff.
It specifically mentions that some CPUs in family 17h don't support the architectural
MSR.

The document is *not intended* to be comprehensive list of CPUs that support
It.  Documentation for individual CPUs indicate the availability of the MSR.

> 
> > But that is not for all family 17h nor for family 19h.  You can see earlier in
> > the document the method to detect presence for SSBD which applies to
> the
> > rest of 17h and 19h.
> 
> We know how to read this document. But this document does not mention
> anything else than family 17h. So what are you talking about?
> 
> > That code in amd_set_core_ssb_state is only used for one of the
> > mitigation codepaths without MSR support, not for all Zen CPUs.
> 
> Again, how is that relevant to the legitimate question whether that
> document applies to family 17h only or to 17h+ which includes 19h?

To confirm the availability of the MSR for a particular CPU, you can look
at the PPR for a family 19h CPU.  For example here is family 19h model 01h:
https://www.amd.com/en/support/tech-docs/processor-programming-reference-ppr-for-amd-family-19h-model-01h-revision-b1?msclkid=f5047d01b5b211ec8d619d1385260e2d

> 
> We need to make a decison about what X86_FEATURE_ZEN means. Is it that
> hard to give an authoritive answer?
> 

The comment currently associated with X86_FEATURE_ZEN is appropriate that it
means family 17h or newer.  There is an ask in this thread for clarifying that comment
it's for all CPUs with the Zen microarchitecture, and I believe that will be something
that Wyes will do as a follow up.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ