linux-kernel - Re: [PATCH v3 1/2] x86/cpufeatures: Add macros for Intel's new fast rep string 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: <YxGZH7aOXQF7Pu5q@nazgul.tnic>
Date:   Fri, 2 Sep 2022 07:48:31 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     Jim Mattson <jmattson@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Babu Moger <babu.moger@....com>,
        "Chang S. Bae" <chang.seok.bae@...el.com>,
        Wyes Karny <wyes.karny@....com>,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@...r.kernel.org>,
        "open list:KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)" 
        <kvm@...r.kernel.org>
Subject: Re: [PATCH v3 1/2] x86/cpufeatures: Add macros for Intel's new fast
 rep string features

On Thu, Sep 01, 2022 at 09:14:24PM -0700, H. Peter Anvin wrote:
> Any reason why these bits are hidden from /proc/cpuinfo?

Yes, we aim to hide such purely CPUID bits from /proc/cpuinfo because it
becomes a dumping ground for "enablement" of new features. But

1. those features are not really used - most userspace like binutils and
gcc, etc do their own detection. (Yes, yes, I'd like to have ubiquitous
CPUID faulting).

2. /proc/cpuinfo is an ABI so we have to carry *all* those gazillion
flags for no good reason

So we have tools/arch/x86/kcpuid/ which we control and we can extend
with all the CPUID querying needs we have.

These kvm enablement things are kinda needed because guest userspace
gets an emulated CPUID so in order to detect features on its own, it
needs them. And kvm has tied features to x86's X86_FEATURE stuff and
there are sometimes weird interactions with it too but that's another
topic...

Oh and we still do add visible flags to /proc/cpuinfo but only when
they're features which need and have received non-trivial kernel
enablement like TDX or SNP or so.

-- 
Regards/Gruss,
    Boris.

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