linux-kernel - Re: [PATCH] x86: add more x86-64 micro-architecture levels

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]

Message-ID: <OCPUzm9NO5UcsvzQfzIazzMh7nymvY5oz3pBojDqEOlhVrYTdYZ35Il0oi8WkwFN7N-1HpCIPXFgQ3MGT7108YhjiBWWv7RqrC40mlW4ak4=@proton.me>
Date: Sun, 15 Sep 2024 12:25:24 +0000
From: John <therealgraysky@...ton.me>
To: Dave Hansen <dave.hansen@...el.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, Unknown <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86: add more x86-64 micro-architecture levels

On Sunday, September 15th, 2024 at 7:40 AM, Dave Hansen <dave.hansen@...el.com> wrote:
> If these are going to be exposed to end users, we need some kind of
> help text that helps end users select among these options and what the
> pitfalls are.
> 
> I actually don't have the foggiest idea what an "AMD x86-64 CPU with v2
> instructions" even is. Even saying "AMD x86-64 CPU" isn't super helpful
> because "AMD x86_64" is kinda a generic way to refer to all the 64-bit
> x86 CPUs, Intel included.

> Why are there v4's for both AMD and Intel that do the exact same thing?

I did it this way to selectively include the AMD-specific and Intel-specific membership in the config options below.  For example, the AMD options should be included in the X86_INTEL_USERCOPY config.

> Why is this copied and pasted six times?
> 
> + depends on (CC_IS_GCC && GCC_VERSION > 110000)...

I believe the version requirement is needed for each of these new options.  Please correct me if I am mistaken.

> Alternatively, anyone wanting to do this could just hack their makefile
> or (I assume) pass CFLAGS= into the build command-line. Why is
> something like that insufficient.

I believe this would work:
export KCFLAGS=' -march=x86-64-v3'
export KCPPFLAGS=' -march=x86-64-v3'

> > config X86_HAVE_PAE
> > def_bool y
> > - depends on MCRUSOE || MEFFICEON || MCYRIXIII || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC7 || MCORE2 || MATOM || X86_64
> > + depends on MCRUSOE || MEFFICEON || MCYRIXIII || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC7 || MCORE2 || MATOM || X86_64 || MAMD_CPU_V2 || MAMD_CPU_V3 || MAMD_CPU_V4 || MINTEL_CPU_V2 || MINTEL_CPU_V3 || MINTEL_CPU_V4
> 
> 
> is rather silly when M*_CPU_V* all:
> 
> depends on X86_64
> 
> right?

True!

> So, taking a step back: Please convince us that this is something we
> want to expose to end users in the first place, as opposed to having
> them hack makefiles or just allowing users a string instead of using the
> existing CONFIG_M* Kconfig options.

This was just the logical extension of the already included and now antiquated options, for example pentium-mmx, k6, etc.