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: <20200902165216.GB21537@zn.tnic>
Date:   Wed, 2 Sep 2020 18:52:16 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Feng Tang <feng.tang@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] tools/x86: add kcpuid tool to show raw CPU features

On Wed, Sep 02, 2020 at 09:25:17AM -0700, Dave Hansen wrote:
> Ugh.  I hate text parsers.  But, I do see what you're getting at.

That's why it'll be a simple one. Nothing fancy. I'm hoping the final
version would be somewhat readable to humans too.

> If we do this, I bet having each value on its own line, I bet this would
> be a bit less painful to parse.  It'll be a _bit_ harder to read, but
> not really.  Maybe:
>
> LEAF[07],SUBLEAF[00],EAX[31:0],max_value,	Max input value for supported
> subleafs
> LEAF[07],SUBLEAF[00],EBX[   0],FSGSBASE,
> RDFSBASE/RDGSBASE/WRFSBASE/WRGSBASE if 1.
> LEAF[07],SUBLEAF[00],EBX[   1],TSC_ADJUST,	IA32_TSC_ADJUST MSR is
> supported if 1.
> LEAF[07],SUBLEAF[00],EBX[   2],SGX,		Supports IntelĀ® Software Guard
> Extensions (IntelĀ® SGX Extensions) if 1.

Yeah, this was just a stupid example to start the conversation.

> I was *really* hoping that we could eventually feed kcpuid and the
> X86_FEATURE_* bits from the same source.

But X86_FEATURE_* won't be all bits in all CPUID leafs - only the ones the
kernel has enabled/use for/needs/...

Also you have CPUID fields which are multi-bit and which cannot be
X86_FEATURE_* things.

So you need a place which has the whole CPUID space and X86_FEATURE_*
simply cannot represent it all.

-- 
Regards/Gruss,
    Boris.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ