linux-kernel - Re: [PATCH] x86/cpu: Update power flags

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20231128193650.GFZWZBUqhLD4AJzeO3@fat_crate.local>
Date:   Tue, 28 Nov 2023 20:36:50 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Thomas Weißschuh <linux@...ssschuh.net>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/cpu: Update power flags

On Tue, Nov 28, 2023 at 08:25:40PM +0100, Thomas Weißschuh wrote:
> > The beginning of Documentation/arch/x86/cpuinfo.rst tries to explain
> > why.
> 
> Isn't this introduction more about the cpuinfo "flags" fields?

That's why I said "tries to explain". See below - I've been meaning to
write this for a long time now.

>   power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14] [15]

Yeah, nothing cares about those - see below.

Thx.

---
diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst
index 08246e8ac835..95c7ebcc13a9 100644
--- a/Documentation/arch/x86/cpuinfo.rst
+++ b/Documentation/arch/x86/cpuinfo.rst
@@ -13,6 +13,29 @@ 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.
 
+The /proc/cpuinfo list is not exhaustive 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 even need to be in that file because
+userspace doesn't even 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 do that and the hw supports CPUID faulting, userspace can
+simply probe for the feature and figure out if it is supported or not
+
+* 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".
+
 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.


-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette