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.
