linux-kernel - Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Dec 2019 21:48:54 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Thomas Renninger <trenn@...e.de>
Cc:     linux-kernel@...r.kernel.org,
        Felix Schnizlein <fschnizlein@...e.de>,
        linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux@...linux.org.uk, will.deacon@....com, x86@...nel.org,
        fschnitzlein@...e.de, Felix Schnizlein <fschnizlein@...e.com>,
        Thomas Renninger <trenn@...e.com>
Subject: Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

Greg KH <gregkh@...uxfoundation.org> writes:
> On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
>> From: Felix Schnizlein <fschnizlein@...e.de>
>> ==> flags <==
>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip
>
> One file with all of that?  We are going to run into problems
> eventually, that should be split up.
>
> Just like bugs, that's going to just grow over time and eventually
> overflow PAGE_SIZE :(
>
> Make this:
>   ├── flags
>   │   ├── fpu
>   │   ├── vme
> ...
>
> Much simpler to parse, right?

Well, I'm not really sure whether 100+ files are simpler to parse.

Aside of that I really don't see the value for 100+ files per CPU which
are just returning 1 or True or whatever as long as you are not
suggesting to provide real feature files which have 0/1 or True/False
content.

But I still don't get the whole thing. The only "argument" I've seen so
far is the 'proc moves to sys' mantra, but that does not make it any
better.

We won't get rid of /proc/cpuinfo for a very long time simply because
too much userspace uses it. Introducing a mess in /sys/ in parallel just
for following the mantra does not help much.

Also IF we ever expose feature flags in sys then this needs to be a
split ino

  cpu/common_features

and

  cpu/CPU$N/unique_features

On most systems unique_features wont exist, but there is such stuff on
the horizon.

Thanks,

        tglx