linux-kernel - Re: x86 CPU features detection for applications (and AMX)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ba004c50-a630-27f4-5fb0-c6ad2b1f1e06@intel.com>
Date:   Thu, 8 Jul 2021 07:36:44 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Florian Weimer <fweimer@...hat.com>
Cc:     libc-alpha@...rceware.org, linux-api@...r.kernel.org,
        x86@...nel.org, linux-arch@...r.kernel.org,
        "H.J. Lu" <hjl.tools@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: x86 CPU features detection for applications (and AMX)

On 7/8/21 7:31 AM, Florian Weimer wrote:
>> OK, so if I call CPU_FEATURE_USABLE(PKS) on a system *WITH* PKS
>> supported in the operating system, I'll get false from an interface that
>> claims to be:
>>
>>> This macro returns a nonzero value (true) if the processor has the
>>> feature name and the feature is supported by the operating system.
>> The interface just seems buggy by *design*.
> Yes, but that is largely a documentation matter.  We should have said
> something about “userspace” there, and that the bit needs to be known to
> glibc.  There is another exception: FSGSBASE, and that's a real bug we
> need to fix (it has to go through AT_HWCAP2).
> 
> If we want to avoid that, we need to go down the road of a curated set
> of CPUID bits, where a bit only exists if we have taught glibc its
> semantics.  You still might get a false negative by running against an
> older glibc than the application was built for.  (We are not going to
> force applications that e.g. look for FSGSBASE only run with a glibc
> that is at least of that version which implemented semantics for the
> FSGSBASE bit.)

That's kinda my whole point.

These *MUST* be curated to be meaningful.  Right now, someone just
dumped a set of CPUID bits into the documentation.

The interface really needs *three* modes:

1. Yes, the CPU/OS supports this feature
2. No, the CPU/OS doesn't support this feature
3. Hell if I know, never heard of this feature
	
The interface really conflates 2 and 3.  To me, that makes it
fundamentally flawed.