linux-kernel - Re: [RFC PATCH v2] tools/x86: add kcpuid tool to show raw CPU features

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: <20200925205751.GR16872@zn.tnic>
Date:   Fri, 25 Sep 2020 22:57:51 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Arvind Sankar <nivedita@...m.mit.edu>
Cc:     Feng Tang <feng.tang@...el.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Yazen Ghannam <yazen.ghannam@....com>,
        Wei Huang <wei.huang2@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...el.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2] tools/x86: add kcpuid tool to show raw CPU
 features

On Fri, Sep 25, 2020 at 04:40:47PM -0400, Arvind Sankar wrote:
> They're not the same, but aren't there going to be quite a few common
> flags between the definitions in cpufeatures.h and the definitions in
> cpuid.txt? If they're both living in the kernel repo, it would be nice
> for them to not duplicate what's common between them, no?

You will generate cpuid.txt exactly once and shortly after cpufeatures.h
will already be ancient in comparison to it. So there would be no point
to share.

Also, have a look at which leafs are in cpufeatures.h, which of those
leafs are synthetic and how many leafs are in an actual CPUID hw
implementation.

Then, some of the bits in cpufeatures.h are not present while the leafs
in CPUID have them for the above reason.

And so on...

> This shouldn't affect how easy it is to update, I think. The kernel
> build will use whatever version is in the source tree, the tool will use
> whatever version is installed under /usr/share, so the latter can be
> updated without needing a new kernel.

And I believe that keeping those apart because there are differences,
would cause more confusion vs having the two things completely separate.

So I actually think that sharing between the two is not even worth the
effort.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette