* 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
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*.
* 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
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.
* Dave Hansen:
> 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.
That's an interesing point.
3 looks potentially more useful than the feature/usable distinction to
me.
The recent RTM change suggests that there are more states, but we
probably can't do much about such soft-disable changes.
Thanks,
Florian