linux-kernel - Re: [PATCH v13 00/11] Parallel CPU bringup for x86

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: <ZAfDhT97ctXSYiYe@google.com>
Date:   Tue, 7 Mar 2023 15:35:20 -0800
From:   Sean Christopherson <seanjc@...gle.com>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Tom Lendacky <thomas.lendacky@....com>,
        Usama Arif <usama.arif@...edance.com>, tglx@...utronix.de,
        kim.phillips@....com, brgerst@...il.com,
        Sabin Rapan <sabrapan@...zon.com>, piotrgorski@...hyos.org,
        oleksandr@...alenko.name, arjan@...ux.intel.com, mingo@...hat.com,
        bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
        x86@...nel.org, pbonzini@...hat.com, paulmck@...nel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        rcu@...r.kernel.org, mimoja@...oja.de, hewenliang4@...wei.com,
        pmenzel@...gen.mpg.de, fam.zheng@...edance.com,
        punit.agrawal@...edance.com, simon.evans@...edance.com,
        liangma@...ngbit.com
Subject: Re: [PATCH v13 00/11] Parallel CPU bringup for x86_64

On Tue, Mar 07, 2023, David Woodhouse wrote:
> On Tue, 2023-03-07 at 16:22 -0600, Tom Lendacky wrote:
> > 
> > I did some Qemu/KVM testing. One thing I noticed is that on AMD, CPUID 0xB 
> > EAX will be non-zero only if SMT is enabled. So just booting some guests 
> > without CPU topology never did parallel booting ("smpboot: Disabling 
> > parallel bringup because CPUID 0xb looks untrustworthy"). I would imagine 
> > a bare-metal system that has diabled SMT will not do parallel booting, too 
> > (but I haven't had time to test that).
> 
> Interesting, thanks. Should I change to checking for *both* EAX and EBX
> being zero? That's what I did first, after reading only the Intel SDM.
> But I changed to only EAX because the AMD doc only says that EAX will
> be zero for unsupported leaves.

LOL, nice.  '0' is a prefectly valid output for the shift if there's exactly one
CPU at the current level, which is why Intel states that both EAX and EBX are
cleared.  I assume/hope this is effectively a documentation goof, in that the APM
assumes that all "real" CPUs that support CPUID 0xB also support sub-function 0.

Nit, the AMD says EAX will be zero for unsupported _levels_.  The distinction
matters because if the entire leaf is unsupported, AMD behavior is to zero out
all output registers, even if the input leaf is above the max supported leaf.

Anyways, the kernel already sanity checks the outputs on all x86 CPUs, just
piggyback that logic, e.g. expose detect_extended_topology_leaf() or so.  If AMD
or a VMM is doing something crazy, the kernel is doomed anyways.