RFDS only affects Atom parts. Vendor/Family/Model matching in the affected
processor table makes Alderlake and Raptorlake P-only parts affected (which
are not affected in reality). This is because the affected hybrid and
E-only parts have the same Family/Model as the unaffected P-only parts.
Match CPU-type as Atom to exclude P-only parts as RFDS affected.
Note, a guest with the same Family/Model as the affected part may not have
leaf 1A enumerated to know its CPU-type, but it should not be a problem as
guest's Family/Model can anyways be inaccurate. Moreover, RFDS_NO or
RFDS_CLEAR enumeration by the VMM decides the affected status of the guest.
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 7e3b09b0f82c..73ec66321758 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1209,6 +1209,9 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
#define VULNBL_INTEL_STEPPINGS(vfm, steppings, issues) \
X86_MATCH_VFM_STEPPINGS(INTEL_##vfm, steppings, issues)
+#define VULNBL_INTEL_CPU_TYPE(vfm, cpu_type, issues) \
+ X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, cpu_type, issues)
+
#define VULNBL_AMD(family, blacklist) \
VULNBL(AMD, family, X86_MODEL_ANY, blacklist)
@@ -1255,9 +1258,7 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
VULNBL_INTEL(TIGERLAKE, GDS),
VULNBL_INTEL(LAKEFIELD, MMIO | MMIO_SBDS | RETBLEED),
VULNBL_INTEL(ROCKETLAKE, MMIO | RETBLEED | GDS),
- VULNBL_INTEL(ALDERLAKE, RFDS),
VULNBL_INTEL(ALDERLAKE_L, RFDS),
- VULNBL_INTEL(RAPTORLAKE, RFDS),
VULNBL_INTEL(RAPTORLAKE_P, RFDS),
VULNBL_INTEL(RAPTORLAKE_S, RFDS),
VULNBL_INTEL(ATOM_GRACEMONT, RFDS),
@@ -1271,6 +1272,8 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
/* Match more than Vendor/Family/Model */
VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED),
VULNBL_INTEL (COMETLAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS),
+ VULNBL_INTEL_CPU_TYPE (RAPTORLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS),
+ VULNBL_INTEL_CPU_TYPE (ALDERLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS),
VULNBL_AMD(0x15, RETBLEED),
VULNBL_AMD(0x16, RETBLEED),
--
2.34.1On 6/17/24 02:12, Pawan Gupta wrote: > +#define VULNBL_INTEL_CPU_TYPE(vfm, cpu_type, issues) \ > + X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, cpu_type, issues) > + ... > /* Match more than Vendor/Family/Model */ > VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED), > VULNBL_INTEL (COMETLAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS), > + VULNBL_INTEL_CPU_TYPE (RAPTORLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS), > + VULNBL_INTEL_CPU_TYPE (ALDERLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS), Could we tweak this a bit to make it more compact? For instance, if we did this: #define VULNBL_INTEL_TYPE(vfm, cpu_type, issues) \ X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, \ X86_CPU_TYPE_INTEL_##cpu_type, \ issues) We'd end up with entries like this: VULNBL_INTEL_TYPE (ALDERLAKE, ATOM, RFDS), I guess "TYPE" is a _bit_ ambiguous. But it's also pretty patently obvious what's going on versus something like this: VULNBL_INTEL (COMETLAKE_L, MMIO | MMIO_SBDS | RETBLEED...), Getting rid of the "X86_CPU_TYPE_INTEL_" string in the table is low hanging fruit. I don't feel as strongly about changing the new macro name.
On Mon, Jun 17, 2024 at 07:33:13AM -0700, Dave Hansen wrote: > On 6/17/24 02:12, Pawan Gupta wrote: > > +#define VULNBL_INTEL_CPU_TYPE(vfm, cpu_type, issues) \ > > + X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, cpu_type, issues) > > + > ... > > /* Match more than Vendor/Family/Model */ > > VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED), > > VULNBL_INTEL (COMETLAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS), > > + VULNBL_INTEL_CPU_TYPE (RAPTORLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS), > > + VULNBL_INTEL_CPU_TYPE (ALDERLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS), > > Could we tweak this a bit to make it more compact? For instance, if we > did this: > > #define VULNBL_INTEL_TYPE(vfm, cpu_type, issues) \ > X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, \ > X86_CPU_TYPE_INTEL_##cpu_type, \ > issues) > > We'd end up with entries like this: > > VULNBL_INTEL_TYPE (ALDERLAKE, ATOM, RFDS), > > I guess "TYPE" is a _bit_ ambiguous. But it's also pretty patently > obvious what's going on versus something like this: > > VULNBL_INTEL (COMETLAKE_L, MMIO | MMIO_SBDS | RETBLEED...), > > Getting rid of the "X86_CPU_TYPE_INTEL_" string in the table is low > hanging fruit. I don't feel as strongly about changing the new macro name. It makes sense to me, atleast getting rid of X86_CPU_TYPE_INTEL_ in X86_CPU_TYPE_INTEL_ATOM.
On 17/06/2024 10:12 am, Pawan Gupta wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 7e3b09b0f82c..73ec66321758 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1209,6 +1209,9 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
> #define VULNBL_INTEL_STEPPINGS(vfm, steppings, issues) \
> X86_MATCH_VFM_STEPPINGS(INTEL_##vfm, steppings, issues)
>
> +#define VULNBL_INTEL_CPU_TYPE(vfm, cpu_type, issues) \
> + X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, cpu_type, issues)
> +
> #define VULNBL_AMD(family, blacklist) \
> VULNBL(AMD, family, X86_MODEL_ANY, blacklist)
>
> @@ -1255,9 +1258,7 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
> VULNBL_INTEL(TIGERLAKE, GDS),
> VULNBL_INTEL(LAKEFIELD, MMIO | MMIO_SBDS | RETBLEED),
> VULNBL_INTEL(ROCKETLAKE, MMIO | RETBLEED | GDS),
> - VULNBL_INTEL(ALDERLAKE, RFDS),
> VULNBL_INTEL(ALDERLAKE_L, RFDS),
> - VULNBL_INTEL(RAPTORLAKE, RFDS),
> VULNBL_INTEL(RAPTORLAKE_P, RFDS),
> VULNBL_INTEL(RAPTORLAKE_S, RFDS),
> VULNBL_INTEL(ATOM_GRACEMONT, RFDS),
> @@ -1271,6 +1272,8 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
> /* Match more than Vendor/Family/Model */
> VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED),
> VULNBL_INTEL (COMETLAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS),
> + VULNBL_INTEL_CPU_TYPE (RAPTORLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS),
> + VULNBL_INTEL_CPU_TYPE (ALDERLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS),
How does this work?
Being __initconst, this is only evaluated on the BSP.
P-only and mixed P/E systems won't see X86_CPU_TYPE_INTEL_ATOM, even if
there are ATOM APs to bring up later.
~Andrew
On 6/17/24 02:43, Andrew Cooper wrote: > On 17/06/2024 10:12 am, Pawan Gupta wrote: >> + VULNBL_INTEL_CPU_TYPE (RAPTORLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS), >> + VULNBL_INTEL_CPU_TYPE (ALDERLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS), > > How does this work? > > Being __initconst, this is only evaluated on the BSP. > > P-only and mixed P/E systems won't see X86_CPU_TYPE_INTEL_ATOM, even if > there are ATOM APs to bring up later. The X86_CPU_TYPE_* is only used on the boot CPU on non-hybrids. Hybrids (independent of the boot CPU type) should be considered vulnerable no matter what.
On Mon, Jun 17, 2024 at 07:34:22AM -0700, Dave Hansen wrote:
> On 6/17/24 02:43, Andrew Cooper wrote:
> > On 17/06/2024 10:12 am, Pawan Gupta wrote:
> >> + VULNBL_INTEL_CPU_TYPE (RAPTORLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS),
> >> + VULNBL_INTEL_CPU_TYPE (ALDERLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS),
> >
> > How does this work?
> >
> > Being __initconst, this is only evaluated on the BSP.
> >
> > P-only and mixed P/E systems won't see X86_CPU_TYPE_INTEL_ATOM, even if
> > there are ATOM APs to bring up later.
>
> The X86_CPU_TYPE_* is only used on the boot CPU on non-hybrids. Hybrids
> (independent of the boot CPU type) should be considered vulnerable no
> matter what.
Yes. This is done in x86_match_cpu_type(), that matches all cpu-types on hybrids:
static bool x86_match_cpu_type(struct cpuinfo_x86 *c, const struct x86_cpu_id)
{
if (m->cpu_type == X86_CPU_TYPE_ANY)
return true;
/* Hybrid CPUs are special, they are assumed to match all cpu-types */
if (boot_cpu_has(X86_FEATURE_HYBRID_CPU))
return true;
return c->topo.cpu_type == m->cpu_type;
}
© 2016 - 2025 Red Hat, Inc.