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

* Dave Hansen:

On 7/7/21 11:05 PM, Florian Weimer wrote:

quoted

quoted

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).

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:

quoted

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.)

Thanks,
Florian

On 7/8/21 7:31 AM, Florian Weimer wrote:

quoted

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:

quoted

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.