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
| ||
|
Date: Sat, 03 Oct 2020 03:39:29 +0200 From: Thomas Gleixner <tglx@...utronix.de> To: Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>, x86@...nel.org, Borislav Petkov <bp@...e.de>, Ingo Molnar <mingo@...nel.org> Cc: Len Brown <len.brown@...el.com>, "Ravi V. Shankar" <ravi.v.shankar@...el.com>, linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>, Tony Luck <tony.luck@...el.com>, "Peter Zijlstra \(Intel\)" <peterz@...radead.org>, Ricardo Neri <ricardo.neri-calderon@...ux.intel.com> Subject: Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote: > Add support to discover and enumerate CPUs in Intel hybrid parts. A hybrid > part has CPUs with more than one type of micro-architecture. Thus, certain > features may only be present in a specific CPU type. > > It is useful to know the type of CPUs present in a system. For instance, > perf may need to handle CPUs differently depending on the type of micro- > architecture. Decoding machine check error logs may need the additional > micro-architecture type information, so include that in the log. 'It is useful' as justification just makes me barf. > A hybrid part can be identified by reading a new CPUID feature bit. > Likewise, CPUID contains information about the CPU type as well as a new > native model ID. Details can be found in the Intel manual (SDM, [1]). > > This series adds support for Intel hybrid parts in two areas: a) adding > the hybrid feature bit as well as struct cpuinfo_x86; and b) decode machine > check errors on hybrid parts. Bla, bla, bla. > A later submission will use the proposed functionality to expose the CPU > topology to user space. The only patch which is accepted for now is: if (boot_cpu_has(X86_FEATURE_HYBRID_CPU)) panic("Unsuppported insanity\n"); I'm not all all willing to take anything else unless you or someone else provides a reasonable explanation for the overall approach of supporting this mess inlcuding stable kernels. This has been clearly communicated years ago when the topic was discussed at one of the Intel Techday events. It's not my problem if Intel internal communication is disfunctional. Just to bring you up to speed: 1) The whole CPU enumeration of x86 sucks and is in no way prepared to deal with heterogenous CPU faetures Boris and I have discussed this with Intel and on LKML and there are ideas how to clean up that mess. This needs to be solved first before we even start to talk about this CPU has FOO but the other does not. 2) Intel has been told clearly that a prerequisite of adding any of this is a well defined programming model and a proper design of dealing with it at the kernel level. Since that discussion at one of the Intel events I haven't heard and seen anything related to that. If Intel thinks that some magic PDF and some Intel internal 'works for me' patches are solving it, then I just have to give up because explaining the requirements again is just waste of time. So I'm taking Patch 1/3 which defines the misfeature flag and then put something like the above on top which will prevent booting on any of these machines. These two patches are going to be marked for stable simply because any attempt to use any of these asymetric features is a recipe to disaster. And that disaster is going to happen simply because user space can use CPUID to figure out what a CPU supports. I'm not at all interested in the resulting wreckage reports. It's a sad state of affairs that the only outcome of a dicsussion which touched all of the above is a patch set which paves the path to hell. Not going to happen. Thanks, tglx
Powered by blists - more mailing lists