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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <878s2hz6g3.fsf@oldenburg.str.redhat.com>
Date:   Thu, 08 Jul 2021 08:05:16 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Dave Hansen <dave.hansen@...el.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)

* Dave Hansen:

> On 6/23/21 8:04 AM, Florian Weimer wrote:
>> https://www.gnu.org/software/libc/manual/html_node/X86.html
> ...
>> Previously kernel developers have expressed dismay that we didn't
>> coordinate the interface with them.  This is why I want raise this now.
>
> This looks basically like someone dumped a bunch of CPUID bit values and
> exposed them to applications without considering whether applications
> would ever need them.  For instance, why would an app ever care about:
>
> 	PKS – Protection keys for supervisor-mode pages.
>
> And how could glibc ever give applications accurate information about
> whether PKS "is supported by the operating system"?  It just plain
> doesn't know, or at least only knows from a really weak ABI like
> /proc/cpuinfo.

glibc is expected to mask these bits for CPU_FEATURE_USABLE because they
have unknown semantics (to glibc).

They are still exposed via HAS_CPU_FEATURE.

I argued against HAS_CPU_FEATURE because the mere presence of this
interface will introduce application bugs because application really
must use CPU_FEATURE_USABLE instead.

I wanted to go with a curated set of bits, but we couldn't get consensus
around that.  Curiously, the present interface can expose changing CPU
state (if the kernel updates some fixed memory region accordingly), my
preferred interface would not have supported that.

> It also doesn't seem to tell applications what they want which is, "can
> I, the application, *use* this feature?"

CPU_FEATURE_USABLE is supposed to be that interface.

Thanks,
Florian