linux-kernel - Re: [RFC PATCH] x86/cpu: Mark Ice Lake model 7D and 9D as unreleased

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: <46022480-eef7-4670-ab1d-6d781eee95d5@intel.com>
Date: Wed, 11 Jun 2025 12:24:31 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>,
 Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, x86@...nel.org
Cc: tony.luck@...el.com, "H. Peter Anvin" <hpa@...or.com>,
 linux-kernel@...r.kernel.org, Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [RFC PATCH] x86/cpu: Mark Ice Lake model 7D and 9D as unreleased

On 6/11/25 11:52, Andrew Cooper wrote:
> What if Intel suddenly find there's a >50% gross market opportunity
> selling ICX-NNPI and release this model after all?  (Ok fine, unlikely,
> but the point stands).

Intel has been _treating_ these models as if they don't exist. If Intel
changes its mind, it's going to have an awful lot of work to do like
updating the "affected CPU list" documentation or the other random CPU
model lists in the kernel that are missing ICX-NNPI.

Removing a CPU from this list will be a small matter compared to the
rest of the work that has to be done.

> What about unallocated model numbers?

One thing I considered was just taking model 7D and 9D and removing them
from the kernel. Basically making them the same as unallocated model
numbers.

But in general, we expect that folks will boot old kernels on new
hardware. We also expect the kernel to do its best there and not whine
or complain because there's nothing wrong going on.

But model 7D and 9D are different. I think we really do want the kernel
to complain. It's totally unexpected that someone will run Linux on one
of those CPUs. We want the kernel to complain loudly.

> What about A0 stepping of released models?

Can we detect A0 steppings deterministically? Do we want Linux running
on them without or without complaint?

I don't think there are any hard rules across all CPUs that would let us
reliably detect A0 steppings. Even if we could, the vast majority of
folks running Linux on them are doing internal CPU company testing on
them and we aren't going to help those folks much by scaring them with
warnings.

> What about Cannon Lake which did technically ship to customers, but
> for most intents and purposes doesn't exist.

Is there a _reason_ to mark them as unreleased? Are they getting (or did
they get) microcode updates? Are they covered in the mitigation
documentation?