From: "Borislav Petkov (AMD)" <[email protected]>
This has been long overdue. Write down what x86's version of
/proc/cpuinfo is and should be used for.
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
---
Documentation/arch/x86/cpuinfo.rst | 79 ++++++++++++++++++++++--------
1 file changed, 58 insertions(+), 21 deletions(-)
diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst
index 08246e8ac835..cede6aad27c0 100644
--- a/Documentation/arch/x86/cpuinfo.rst
+++ b/Documentation/arch/x86/cpuinfo.rst
@@ -7,27 +7,64 @@ x86 Feature Flags
Introduction
============
-On x86, flags appearing in /proc/cpuinfo have an X86_FEATURE definition
-in arch/x86/include/asm/cpufeatures.h. If the kernel cares about a feature
-or KVM want to expose the feature to a KVM guest, it can and should have
-an X86_FEATURE_* defined. These flags represent hardware features as
-well as software features.
-
-If users want to know if a feature is available on a given system, they
-try to find the flag in /proc/cpuinfo. If a given flag is present, it
-means that the kernel supports it and is currently making it available.
-If such flag represents a hardware feature, it also means that the
-hardware supports it.
-
-If the expected flag does not appear in /proc/cpuinfo, things are murkier.
-Users need to find out the reason why the flag is missing and find the way
-how to enable it, which is not always easy. There are several factors that
-can explain missing flags: the expected feature failed to enable, the feature
-is missing in hardware, platform firmware did not enable it, the feature is
-disabled at build or run time, an old kernel is in use, or the kernel does
-not support the feature and thus has not enabled it. In general, /proc/cpuinfo
-shows features which the kernel supports. For a full list of CPUID flags
-which the CPU supports, use tools/arch/x86/kcpuid.
+The list of feature flags in /proc/cpuinfo is not complete and
+represents an ill-fated attempt from long time ago to put feature flags
+in an easy to find place for userspace.
+
+However, the amount of feature flags is growing by the CPU generation,
+leading to unparseable and unwieldy /proc/cpuinfo.
+
+What is more, those feature flags do not even need to be in that file
+because userspace doesn't care about them - glibc et al already use
+CPUID to find out what the target machine supports and what not.
+
+And even if it doesn't show a particular feature flag - although the CPU
+still does have support for the respective hardware functionality and
+said CPU supports CPUID faulting - userspace can simply probe for the
+feature and figure out if it is supported or not, regardless of whether
+it is being advertized somewhere.
+
+Furthermore, those flag strings become an ABI the moment they appear
+there and maintaining them forever when nothing even uses them is a lot
+of wasted effort.
+
+So, the current use of /proc/cpuinfo is to show features which the
+kernel has *enabled* and supports. As in: the CPUID feature flag is
+there, there's an additional setup which the kernel has done while
+booting and the functionality is there and ready to use. A perfect
+example for that is "user_shstk" where additional code enablement is
+present in the kernel to support shadow stack for user programs.
+
+So, if users want to know if a feature is available on a given system,
+they try to find the flag in /proc/cpuinfo. If a given flag is present,
+it means that the kernel supports it and is currently making it
+available. If such flag represents a hardware feature, it also means
+that the hardware supports it.
+
+If the expected flag does not appear in /proc/cpuinfo, things are
+murkier. Users need to find out the reason why the flag is missing and
+find the way how to enable it, which is not always easy.
+
+There are several factors that can explain missing flags: the expected
+feature failed to enable, the feature is missing in hardware, platform
+firmware did not enable it, the feature is disabled at build or run
+time, an old kernel is in use, or the kernel does not support the
+feature and thus has not enabled it. In general, /proc/cpuinfo shows
+features which the kernel supports. For a full list of CPUID flags which
+the CPU supports, use tools/arch/x86/kcpuid.
+
+Regarding implementation, flags appearing in /proc/cpuinfo have an
+X86_FEATURE definition in arch/x86/include/asm/cpufeatures.h. These flags
+represent hardware features as well as software features.
+
+If the kernel cares about a feature or KVM want to expose the feature to
+a KVM guest, it should only then expose it to the guest when the guest
+needs to parse /proc/cpuinfo. Which, as mentioned above, is highly
+unlikely. KVM can synthesize the CPUID bit and the KVM guest can simply
+query CPUID and figure out what the hypervisor supports and what not. As
+already stated, /proc/cpuinfo is not a dumping ground for useless
+feature flags.
+
How are feature flags created?
==============================
--
2.42.0.rc0.25.ga82fb66fed25
On 11/29/23 02:17, Borislav Petkov wrote:
> From: "Borislav Petkov (AMD)" <[email protected]>
>
> This has been long overdue. Write down what x86's version of
> /proc/cpuinfo is and should be used for.
>
> Signed-off-by: Borislav Petkov (AMD) <[email protected]>
> ---
> Documentation/arch/x86/cpuinfo.rst | 79 ++++++++++++++++++++++--------
> 1 file changed, 58 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst
> index 08246e8ac835..cede6aad27c0 100644
> --- a/Documentation/arch/x86/cpuinfo.rst
> +++ b/Documentation/arch/x86/cpuinfo.rst
> @@ -7,27 +7,64 @@ x86 Feature Flags
> Introduction
> ============
>
> -On x86, flags appearing in /proc/cpuinfo have an X86_FEATURE definition
> -in arch/x86/include/asm/cpufeatures.h. If the kernel cares about a feature
> -or KVM want to expose the feature to a KVM guest, it can and should have
> -an X86_FEATURE_* defined. These flags represent hardware features as
> -well as software features.
> -
> -If users want to know if a feature is available on a given system, they
> -try to find the flag in /proc/cpuinfo. If a given flag is present, it
> -means that the kernel supports it and is currently making it available.
> -If such flag represents a hardware feature, it also means that the
> -hardware supports it.
> -
> -If the expected flag does not appear in /proc/cpuinfo, things are murkier.
> -Users need to find out the reason why the flag is missing and find the way
> -how to enable it, which is not always easy. There are several factors that
> -can explain missing flags: the expected feature failed to enable, the feature
> -is missing in hardware, platform firmware did not enable it, the feature is
> -disabled at build or run time, an old kernel is in use, or the kernel does
> -not support the feature and thus has not enabled it. In general, /proc/cpuinfo
> -shows features which the kernel supports. For a full list of CPUID flags
> -which the CPU supports, use tools/arch/x86/kcpuid.
> +The list of feature flags in /proc/cpuinfo is not complete and
> +represents an ill-fated attempt from long time ago to put feature flags
> +in an easy to find place for userspace.
> +
> +However, the amount of feature flags is growing by the CPU generation,
> +leading to unparseable and unwieldy /proc/cpuinfo.
> +
> +What is more, those feature flags do not even need to be in that file
> +because userspace doesn't care about them - glibc et al already use
> +CPUID to find out what the target machine supports and what not.
> +
> +And even if it doesn't show a particular feature flag - although the CPU
> +still does have support for the respective hardware functionality and
> +said CPU supports CPUID faulting - userspace can simply probe for the
> +feature and figure out if it is supported or not, regardless of whether
> +it is being advertized somewhere.
^ advertised
> +Furthermore, those flag strings become an ABI the moment they appear
> +there and maintaining them forever when nothing even uses them is a lot
> +of wasted effort.
> +
> +So, the current use of /proc/cpuinfo is to show features which the
> +kernel has *enabled* and supports. As in: the CPUID feature flag is
> +there, there's an additional setup which the kernel has done while
> +booting and the functionality is there and ready to use. A perfect
> +example for that is "user_shstk" where additional code enablement is
> +present in the kernel to support shadow stack for user programs.
> +
> +So, if users want to know if a feature is available on a given system,
> +they try to find the flag in /proc/cpuinfo. If a given flag is present,
> +it means
Just rephrasing the meanings, I think I'd say that it means:
all of the following:
* The kernel knows about the feature enough to have an X86_FEATURE_ bit
* The kernel supports it and is currently making it available either to
userspace or some other part of the kernel
* If the flag represents a hardware feature the hardware supports it
> +If the expected flag does not appear in /proc/cpuinfo, things are
> +murkier. Users need to find out the reason why the flag is missing and
> +find the way how to enable it, which is not always easy.
> +
> +There are several factors that can explain missing flags: the expected
> +feature failed to enable, the feature is missing in hardware, platform
> +firmware did not enable it, the feature is disabled at build or run
> +time, an old kernel is in use, or the kernel does not support the
> +feature and thus has not enabled it. In general, /proc/cpuinfo shows
> +features which the kernel supports. For a full list of CPUID flags which
> +the CPU supports, use tools/arch/x86/kcpuid.
Could we trim this down a bit? Maybe concentrate on one example and
then just jump to the takeaway:
The absence of a flag in /proc/cpuinfo by itself means almost nothing to
an end user. A feature like "vaes" might be fully available to user
applications on an kernel that has not defined X86_FEATURE_VAES and thus
there is no "vaes" in /proc/cpuinfo.
On the other hand, a new kernel running on non-VAES hardware would also
have no "vaes" in /proc/cpuinfo. There's no way for an application or
user to tell the difference.
The end result is that the flags field in /proc/cpuinfo is marginally
useful for kernel debugging, but not really for anything else.
Applications should instead use things like the glibc facilities for
querying CPU support. Users should rely on tools like
tools/arch/x86/kcpuid and cpuid(1).
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: 79c603ee43b2674fba0257803bab265147821955
Gitweb: https://git.kernel.org/tip/79c603ee43b2674fba0257803bab265147821955
Author: Borislav Petkov (AMD) <[email protected]>
AuthorDate: Fri, 08 Dec 2023 22:57:33 +01:00
Committer: Borislav Petkov (AMD) <[email protected]>
CommitterDate: Sat, 09 Dec 2023 08:52:53 +01:00
Documentation/x86: Document what /proc/cpuinfo is for
This has been long overdue. Write down what x86's version of
/proc/cpuinfo is and should be used for.
With improvements by dhansen.
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Reviewed-by: Dave Hansen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
Documentation/arch/x86/cpuinfo.rst | 89 ++++++++++++++++++++++-------
1 file changed, 68 insertions(+), 21 deletions(-)
diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst
index 08246e8..8895784 100644
--- a/Documentation/arch/x86/cpuinfo.rst
+++ b/Documentation/arch/x86/cpuinfo.rst
@@ -7,27 +7,74 @@ x86 Feature Flags
Introduction
============
-On x86, flags appearing in /proc/cpuinfo have an X86_FEATURE definition
-in arch/x86/include/asm/cpufeatures.h. If the kernel cares about a feature
-or KVM want to expose the feature to a KVM guest, it can and should have
-an X86_FEATURE_* defined. These flags represent hardware features as
-well as software features.
-
-If users want to know if a feature is available on a given system, they
-try to find the flag in /proc/cpuinfo. If a given flag is present, it
-means that the kernel supports it and is currently making it available.
-If such flag represents a hardware feature, it also means that the
-hardware supports it.
-
-If the expected flag does not appear in /proc/cpuinfo, things are murkier.
-Users need to find out the reason why the flag is missing and find the way
-how to enable it, which is not always easy. There are several factors that
-can explain missing flags: the expected feature failed to enable, the feature
-is missing in hardware, platform firmware did not enable it, the feature is
-disabled at build or run time, an old kernel is in use, or the kernel does
-not support the feature and thus has not enabled it. In general, /proc/cpuinfo
-shows features which the kernel supports. For a full list of CPUID flags
-which the CPU supports, use tools/arch/x86/kcpuid.
+The list of feature flags in /proc/cpuinfo is not complete and
+represents an ill-fated attempt from long time ago to put feature flags
+in an easy to find place for userspace.
+
+However, the amount of feature flags is growing by the CPU generation,
+leading to unparseable and unwieldy /proc/cpuinfo.
+
+What is more, those feature flags do not even need to be in that file
+because userspace doesn't care about them - glibc et al already use
+CPUID to find out what the target machine supports and what not.
+
+And even if it doesn't show a particular feature flag - although the CPU
+still does have support for the respective hardware functionality and
+said CPU supports CPUID faulting - userspace can simply probe for the
+feature and figure out if it is supported or not, regardless of whether
+it is being advertised somewhere.
+
+Furthermore, those flag strings become an ABI the moment they appear
+there and maintaining them forever when nothing even uses them is a lot
+of wasted effort.
+
+So, the current use of /proc/cpuinfo is to show features which the
+kernel has *enabled* and *supports*. As in: the CPUID feature flag is
+there, there's an additional setup which the kernel has done while
+booting and the functionality is ready to use. A perfect example for
+that is "user_shstk" where additional code enablement is present in the
+kernel to support shadow stack for user programs.
+
+So, if users want to know if a feature is available on a given system,
+they try to find the flag in /proc/cpuinfo. If a given flag is present,
+it means that
+
+* the kernel knows about the feature enough to have an X86_FEATURE bit
+
+* the kernel supports it and is currently making it available either to
+ userspace or some other part of the kernel
+
+* if the flag represents a hardware feature the hardware supports it.
+
+The absence of a flag in /proc/cpuinfo by itself means almost nothing to
+an end user.
+
+On the one hand, a feature like "vaes" might be fully available to user
+applications on a kernel that has not defined X86_FEATURE_VAES and thus
+there is no "vaes" in /proc/cpuinfo.
+
+On the other hand, a new kernel running on non-VAES hardware would also
+have no "vaes" in /proc/cpuinfo. There's no way for an application or
+user to tell the difference.
+
+The end result is that the flags field in /proc/cpuinfo is marginally
+useful for kernel debugging, but not really for anything else.
+Applications should instead use things like the glibc facilities for
+querying CPU support. Users should rely on tools like
+tools/arch/x86/kcpuid and cpuid(1).
+
+Regarding implementation, flags appearing in /proc/cpuinfo have an
+X86_FEATURE definition in arch/x86/include/asm/cpufeatures.h. These flags
+represent hardware features as well as software features.
+
+If the kernel cares about a feature or KVM want to expose the feature to
+a KVM guest, it should only then expose it to the guest when the guest
+needs to parse /proc/cpuinfo. Which, as mentioned above, is highly
+unlikely. KVM can synthesize the CPUID bit and the KVM guest can simply
+query CPUID and figure out what the hypervisor supports and what not. As
+already stated, /proc/cpuinfo is not a dumping ground for useless
+feature flags.
+
How are feature flags created?
==============================
On Wed, Nov 29, 2023 at 10:20:31AM -0800, Dave Hansen wrote:
> > +And even if it doesn't show a particular feature flag - although the CPU
> > +still does have support for the respective hardware functionality and
> > +said CPU supports CPUID faulting - userspace can simply probe for the
> > +feature and figure out if it is supported or not, regardless of whether
> > +it is being advertized somewhere.
>
> ^ advertised
"In a rare show of solidarity, both British English and American English
spell advertise with an s in all forms."
LOL: https://grammarist.com/spelling/advertise-vs-advertize/
Agreed with the rest, v2 coming up.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
From: "Borislav Petkov (AMD)" <[email protected]>
Date: Wed, 29 Nov 2023 11:12:55 +0100
This has been long overdue. Write down what x86's version of
/proc/cpuinfo is and should be used for.
With improvements by dhansen.
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
---
Documentation/arch/x86/cpuinfo.rst | 89 +++++++++++++++++++++++-------
1 file changed, 68 insertions(+), 21 deletions(-)
diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst
index 08246e8ac835..8895784d4784 100644
--- a/Documentation/arch/x86/cpuinfo.rst
+++ b/Documentation/arch/x86/cpuinfo.rst
@@ -7,27 +7,74 @@ x86 Feature Flags
Introduction
============
-On x86, flags appearing in /proc/cpuinfo have an X86_FEATURE definition
-in arch/x86/include/asm/cpufeatures.h. If the kernel cares about a feature
-or KVM want to expose the feature to a KVM guest, it can and should have
-an X86_FEATURE_* defined. These flags represent hardware features as
-well as software features.
-
-If users want to know if a feature is available on a given system, they
-try to find the flag in /proc/cpuinfo. If a given flag is present, it
-means that the kernel supports it and is currently making it available.
-If such flag represents a hardware feature, it also means that the
-hardware supports it.
-
-If the expected flag does not appear in /proc/cpuinfo, things are murkier.
-Users need to find out the reason why the flag is missing and find the way
-how to enable it, which is not always easy. There are several factors that
-can explain missing flags: the expected feature failed to enable, the feature
-is missing in hardware, platform firmware did not enable it, the feature is
-disabled at build or run time, an old kernel is in use, or the kernel does
-not support the feature and thus has not enabled it. In general, /proc/cpuinfo
-shows features which the kernel supports. For a full list of CPUID flags
-which the CPU supports, use tools/arch/x86/kcpuid.
+The list of feature flags in /proc/cpuinfo is not complete and
+represents an ill-fated attempt from long time ago to put feature flags
+in an easy to find place for userspace.
+
+However, the amount of feature flags is growing by the CPU generation,
+leading to unparseable and unwieldy /proc/cpuinfo.
+
+What is more, those feature flags do not even need to be in that file
+because userspace doesn't care about them - glibc et al already use
+CPUID to find out what the target machine supports and what not.
+
+And even if it doesn't show a particular feature flag - although the CPU
+still does have support for the respective hardware functionality and
+said CPU supports CPUID faulting - userspace can simply probe for the
+feature and figure out if it is supported or not, regardless of whether
+it is being advertised somewhere.
+
+Furthermore, those flag strings become an ABI the moment they appear
+there and maintaining them forever when nothing even uses them is a lot
+of wasted effort.
+
+So, the current use of /proc/cpuinfo is to show features which the
+kernel has *enabled* and *supports*. As in: the CPUID feature flag is
+there, there's an additional setup which the kernel has done while
+booting and the functionality is ready to use. A perfect example for
+that is "user_shstk" where additional code enablement is present in the
+kernel to support shadow stack for user programs.
+
+So, if users want to know if a feature is available on a given system,
+they try to find the flag in /proc/cpuinfo. If a given flag is present,
+it means that
+
+* the kernel knows about the feature enough to have an X86_FEATURE bit
+
+* the kernel supports it and is currently making it available either to
+ userspace or some other part of the kernel
+
+* if the flag represents a hardware feature the hardware supports it.
+
+The absence of a flag in /proc/cpuinfo by itself means almost nothing to
+an end user.
+
+On the one hand, a feature like "vaes" might be fully available to user
+applications on a kernel that has not defined X86_FEATURE_VAES and thus
+there is no "vaes" in /proc/cpuinfo.
+
+On the other hand, a new kernel running on non-VAES hardware would also
+have no "vaes" in /proc/cpuinfo. There's no way for an application or
+user to tell the difference.
+
+The end result is that the flags field in /proc/cpuinfo is marginally
+useful for kernel debugging, but not really for anything else.
+Applications should instead use things like the glibc facilities for
+querying CPU support. Users should rely on tools like
+tools/arch/x86/kcpuid and cpuid(1).
+
+Regarding implementation, flags appearing in /proc/cpuinfo have an
+X86_FEATURE definition in arch/x86/include/asm/cpufeatures.h. These flags
+represent hardware features as well as software features.
+
+If the kernel cares about a feature or KVM want to expose the feature to
+a KVM guest, it should only then expose it to the guest when the guest
+needs to parse /proc/cpuinfo. Which, as mentioned above, is highly
+unlikely. KVM can synthesize the CPUID bit and the KVM guest can simply
+query CPUID and figure out what the hypervisor supports and what not. As
+already stated, /proc/cpuinfo is not a dumping ground for useless
+feature flags.
+
How are feature flags created?
==============================
--
2.42.0.rc0.25.ga82fb66fed25
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette