linux-kernel - Re: [RFC PATCH v3] 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]

Date:   Thu, 19 Nov 2020 21:50:10 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Dave Hansen <dave.hansen@...el.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, nivedita@...m.mit.edu,
        thomas.lendacky@....com, yazen.ghannam@....com, wei.huang2@....com
Subject: Re: [RFC PATCH v3] tools/x86: add kcpuid tool to show raw CPU
 features

On Thu, Nov 19, 2020 at 10:18:15AM +0100, Borislav Petkov wrote:
> On Thu, Nov 19, 2020 at 03:20:55PM +0800, Feng Tang wrote:
> > I just tried the patch on one Debian 9 and 2 Ubuntus (16.04 & 20.10) with
> > different gcc versions, and haven't reproduced it yet.
> 
> That's because you're testing in VMs and they have CPUID(4) which baremetal -
> where I am testing - doesn't and I get

That's really odd. I tried on 3 baremetal machines: one Skylake NUC device,
one Xeon E5-2699 and one Xeon E5-2680.

> parse_line: entry
> parse_line: skip comments
> parse_line: index/main leaf, func: 0x5588497d7300
> parse_line: sub 0, leafs: (nil)
> 			^^^^^^

Thanks for the debugging and root causing!

> for leafs for index 4 and thus this is a NUL ptr. And leaf 4 is the test
> range in cpuid.csv.
> 
> Which brings me to another important point: setup_platform_cpuid()
> should not blindly simply look at the two ranges 0 and 0x8000_0000
> but detect whether it is running on baremetal or on a hypervisor and
> depending on which, setup the respective ranges.
> 
> For example, guests would need to scan 0x4, in addition to the above.
> Centaur CPUs have CPUID in the ranges 0xc0000000 and so on.
> 
> But you don't have to implement all CPUID leafs and ranges - just your
> tool should be careful and first detect on what it runs and then scan
> the possible ranges.

Ok, will check more on this.

> And then exit gracefully when it encounters a range which it doesn't
> know and not segfault.

Yes, it needs to consider more possible errors.

> There could be another option which, when set, would go and scan the
> *whole* 32-bit CPUID range to find whether there are some CPUID ranges
> which are not known. Another option because the scan would potentially
> take long time and thus off by default. And so on.
> 
> Here's the patch I've cleaned up and fixed up so far, please continue
> with it.

Thanks! will go with this version.

- Feng

> Thx.
> 
> ---
> >From 244c34532d1596a0e3603683904497847bb26b1c Mon Sep 17 00:00:00 2001
> From: Feng Tang <feng.tang@...el.com>
> Date: Thu, 22 Oct 2020 13:21:23 +0800
> Subject: [PATCH] tools/x86: Add a kcpuid tool to show raw CPU features
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> End users frequently want to know what features their processor
> supports, independent of what the kernel supports.
> 
> /proc/cpuinfo is great. It is omnipresent and since it is provided by
> the kernel it is always as up to date as the kernel. But, it could be
> ambiguous about processor features which can be disabled by the kernel
> at boot-time or compile-time.
> 
> There are some user space tools showing more raw features, but they are
> not bound with kernel, and go with distros. Many end users are still
> using old distros with new kernels (upgraded by themselves), and may
> not upgrade the distros only to get a newer tool.
> 
> So here arise the need for a new tool, which
>   * shows raw CPU features read from the CPUID instruction
>   * will be easier to update compared to existing userspace
>     tooling (perhaps distributed like perf)
>   * inherits "modern" kernel development process, in contrast to some
>     of the existing userspace CPUID tools which are still being developed
>     without git and distributed in tarballs from non-https sites.
>   * Can produce output consistent with /proc/cpuinfo to make comparison
>     easier.
> 
> The CPUID leaf definitions are kept in an .csv file which allows for
> updating only that file to add support for new feature leafs.
> 
> This is based on prototype code from Borislav Petkov
> (http://sr71.net/~dave/intel/stupid-cpuid.c).
> 
>  [ bp: Massage, add #define _GNU_SOURCE to fix implicit declaration of
>    function ‘strcasestr' warning. ]
> 
> Originally-from: Borislav Petkov <bp@...en8.de>
> Suggested-by: Dave Hansen <dave.hansen@...el.com>
> Suggested-by: Borislav Petkov <bp@...en8.de>
> Signed-off-by: Feng Tang <feng.tang@...el.com>
> Signed-off-by: Borislav Petkov <bp@...e.de>
> Link: https://lkml.kernel.org/r/1603344083-100742-1-git-send-email-feng.tang@intel.com
> ---
>  tools/arch/x86/kcpuid/Makefile  |  24 ++
>  tools/arch/x86/kcpuid/cpuid.csv |  57 +++
>  tools/arch/x86/kcpuid/kcpuid.c  | 623 ++++++++++++++++++++++++++++++++
>  3 files changed, 704 insertions(+)
>  create mode 100644 tools/arch/x86/kcpuid/Makefile
>  create mode 100644 tools/arch/x86/kcpuid/cpuid.csv
>  create mode 100644 tools/arch/x86/kcpuid/kcpuid.c