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: <4d172613-481b-4b45-aa59-165ef1c7dc9b@intel.com>
Date: Sun, 15 Sep 2024 05:58:01 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: John <therealgraysky@...ton.me>
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 9/15/24 05:25, John wrote:
>> 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.

The requirement is fine.

But copying and pasting the same string without refactoring it is not.
You should refactor it:

bool SUPPORT_MARCH_CODEVERS
	depends on (CC_IS_GCC && GCC_VERSION > 110000)...
	depends on X86_64

and then have each site do this:

+config MINTEL_CPU_V4
+	bool "Intel x86-64-v4"
+	depends on SUPPORT_MARCH_CODEVERS
+	help
...

>> 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.

I think you mean "the AMD options should *not* be included..."

...
>> 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'

So why not just have users do that?

>> 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.
It's probably best not to extend that beast.  It really is a relic of
the past and, practically, all of our 64-bit builds are GENERIC_CPU=y
and have been for a long time.  We've moved away from the old days where
you could easily compile a kernel that didn't boot.

We're basically handing our users a big long piece of rope with which to
hang themselves here.  This patch makes it easy and doesn't do a great
job of explaining why they'd take the risk or what the benefit is.

I don't think we should do this.