From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org
Cc: daniel.sneddon@linux.intel.com, tony.luck@intel.com,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
linux-perf-users@vger.kernel.org,
Josh Poimboeuf <jpoimboe@kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
"Liang, Kan" <kan.liang@linux.intel.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Brice Goglin <brice.goglin@gmail.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Perry Yuan <Perry.Yuan@amd.com>,
Dapeng Mi <dapeng1.mi@linux.intel.com>
Subject: [PATCH v8 5/5] x86/rfds: Exclude P-only parts from the RFDS affected list
Date: Tue, 11 Mar 2025 08:03:08 -0700 [thread overview]
Message-ID: <20250311-add-cpu-type-v8-5-e8514dcaaff2@linux.intel.com> (raw)
In-Reply-To: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com>
The affected CPU table (cpu_vuln_blacklist) marks Alderlake and Raptorlake
P-only parts affected by RFDS. This is not true because only E-cores are
affected by RFDS. With the current family/model matching it is not possible
to differentiate the unaffected parts, as the affected and unaffected
hybrid variants have the same model number.
Add a cpu-type match as well for such parts so as to exclude P-only parts
being marked as affected.
Note, family/model and cpu-type enumeration could be inaccurate in
virtualized environments. In a guest affected status is decided by RFDS_NO
and RFDS_CLEAR bits exposed by VMMs.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst | 8 --------
arch/x86/kernel/cpu/common.c | 7 +++++--
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
index 0585d02b9a6c..ad15417d39f9 100644
--- a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
+++ b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
@@ -29,14 +29,6 @@ Below is the list of affected Intel processors [#f1]_:
RAPTORLAKE_S 06_BFH
=================== ============
-As an exception to this table, Intel Xeon E family parts ALDERLAKE(06_97H) and
-RAPTORLAKE(06_B7H) codenamed Catlow are not affected. They are reported as
-vulnerable in Linux because they share the same family/model with an affected
-part. Unlike their affected counterparts, they do not enumerate RFDS_CLEAR or
-CPUID.HYBRID. This information could be used to distinguish between the
-affected and unaffected parts, but it is deemed not worth adding complexity as
-the reporting is fixed automatically when these parts enumerate RFDS_NO.
-
Mitigation
==========
Intel released a microcode update that enables software to clear sensitive
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 5f81c553e733..92fe56c40238 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1203,6 +1203,9 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
#define VULNBL_INTEL_STEPS(vfm, max_stepping, issues) \
X86_MATCH_VFM_STEPS(vfm, X86_STEP_MIN, max_stepping, issues)
+#define VULNBL_INTEL_TYPE(vfm, cpu_type, issues) \
+ X86_MATCH_VFM_CPU_TYPE(vfm, INTEL_CPU_TYPE_##cpu_type, issues)
+
#define VULNBL_AMD(family, blacklist) \
VULNBL(AMD, family, X86_MODEL_ANY, blacklist)
@@ -1251,9 +1254,9 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
VULNBL_INTEL_STEPS(INTEL_TIGERLAKE, X86_STEP_MAX, GDS),
VULNBL_INTEL_STEPS(INTEL_LAKEFIELD, X86_STEP_MAX, MMIO | MMIO_SBDS | RETBLEED),
VULNBL_INTEL_STEPS(INTEL_ROCKETLAKE, X86_STEP_MAX, MMIO | RETBLEED | GDS),
- VULNBL_INTEL_STEPS(INTEL_ALDERLAKE, X86_STEP_MAX, RFDS),
+ VULNBL_INTEL_TYPE(INTEL_ALDERLAKE, ATOM, RFDS),
VULNBL_INTEL_STEPS(INTEL_ALDERLAKE_L, X86_STEP_MAX, RFDS),
- VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE, X86_STEP_MAX, RFDS),
+ VULNBL_INTEL_TYPE(INTEL_RAPTORLAKE, ATOM, RFDS),
VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE_P, X86_STEP_MAX, RFDS),
VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE_S, X86_STEP_MAX, RFDS),
VULNBL_INTEL_STEPS(INTEL_ATOM_GRACEMONT, X86_STEP_MAX, RFDS),
--
2.34.1
next prev parent reply other threads:[~2025-03-11 15:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-11 15:01 [PATCH v8 0/5] Utilize cpu-type for CPU matching Pawan Gupta
2025-03-11 15:02 ` [PATCH v8 1/5] x86/cpu: Fix the description of X86_MATCH_VFM_STEPS() Pawan Gupta
2025-03-12 9:54 ` [tip: x86/cpu] " tip-bot2 for Pawan Gupta
2025-03-19 11:03 ` [tip: x86/core] " tip-bot2 for Pawan Gupta
2025-03-11 15:02 ` [PATCH v8 2/5] x86/cpu: Name CPU matching macro more generically (and shorten) Pawan Gupta
2025-03-12 9:54 ` [tip: x86/cpu] x86/cpu: Shorten CPU matching macro tip-bot2 for Pawan Gupta
2025-03-19 11:03 ` [tip: x86/core] " tip-bot2 for Pawan Gupta
2025-03-11 15:02 ` [PATCH v8 3/5] x86/cpu: Add cpu_type to struct x86_cpu_id Pawan Gupta
2025-03-12 9:54 ` [tip: x86/cpu] " tip-bot2 for Pawan Gupta
2025-03-19 11:03 ` [tip: x86/core] " tip-bot2 for Pawan Gupta
2025-03-11 15:02 ` [PATCH v8 4/5] x86/cpu: Update x86_match_cpu() to also use cpu-type Pawan Gupta
2025-03-12 9:54 ` [tip: x86/cpu] " tip-bot2 for Pawan Gupta
2025-03-19 11:03 ` [tip: x86/core] " tip-bot2 for Pawan Gupta
2025-03-11 15:03 ` Pawan Gupta [this message]
2025-03-12 9:54 ` [tip: x86/cpu] x86/rfds: Exclude P-only parts from the RFDS affected list tip-bot2 for Pawan Gupta
2025-03-19 11:03 ` [tip: x86/core] " tip-bot2 for Pawan Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250311-add-cpu-type-v8-5-e8514dcaaff2@linux.intel.com \
--to=pawan.kumar.gupta@linux.intel.com \
--cc=Perry.Yuan@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=brice.goglin@gmail.com \
--cc=daniel.sneddon@linux.intel.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jpoimboe@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mingo@redhat.com \
--cc=rafael@kernel.org \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.