* Dave Hansen: > On 7/7/21 11:05 PM, Florian Weimer wrote: >>> 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: > >> 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
