| Message ID | 20240627-add-cpu-type-v2-9-f927bde83ad0@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2,1/9] x86/cpu/topology: Add CPU type to struct cpuinfo_topology | expand |
On Tue, Jul 02, 2024 at 06:04:33PM -0700, Josh Poimboeuf wrote: > On Thu, Jun 27, 2024 at 01:44:55PM -0700, Pawan Gupta wrote: > > @@ -1255,9 +1260,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 +1274,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_TYPE (ALDERLAKE, ATOM, RFDS), > > + VULNBL_INTEL_TYPE (RAPTORLAKE, ATOM, RFDS), > > Same comment here, these should be inline with the main list. Maybe > there's some way to structure the indentations so they align better > vertically with the STEPPINGS/TYPE variants. This is how it is turning out to be: --- diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 151c2377df21..75bbdf0cf8ae 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1237,45 +1237,43 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = { #define RFDS BIT(7) static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = { - VULNBL_INTEL(IVYBRIDGE, SRBDS), - VULNBL_INTEL(HASWELL, SRBDS), - VULNBL_INTEL(HASWELL_L, SRBDS), - VULNBL_INTEL(HASWELL_G, SRBDS), - VULNBL_INTEL(HASWELL_X, MMIO), - VULNBL_INTEL(BROADWELL_D, MMIO), - VULNBL_INTEL(BROADWELL_G, SRBDS), - VULNBL_INTEL(BROADWELL_X, MMIO), - VULNBL_INTEL(BROADWELL, SRBDS), - VULNBL_INTEL(SKYLAKE_X, MMIO | RETBLEED | GDS), - VULNBL_INTEL(SKYLAKE_L, MMIO | RETBLEED | GDS | SRBDS), - VULNBL_INTEL(SKYLAKE, MMIO | RETBLEED | GDS | SRBDS), - VULNBL_INTEL(KABYLAKE_L, MMIO | RETBLEED | GDS | SRBDS), - VULNBL_INTEL(KABYLAKE, MMIO | RETBLEED | GDS | SRBDS), - VULNBL_INTEL(CANNONLAKE_L, RETBLEED), - VULNBL_INTEL(ICELAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS), - VULNBL_INTEL(ICELAKE_D, MMIO | GDS), - VULNBL_INTEL(ICELAKE_X, MMIO | GDS), - VULNBL_INTEL(COMETLAKE, MMIO | MMIO_SBDS | RETBLEED | GDS), - VULNBL_INTEL(TIGERLAKE_L, GDS), - VULNBL_INTEL(TIGERLAKE, GDS), - VULNBL_INTEL(LAKEFIELD, MMIO | MMIO_SBDS | RETBLEED), - VULNBL_INTEL(ROCKETLAKE, MMIO | RETBLEED | GDS), - VULNBL_INTEL(ALDERLAKE_L, RFDS), - VULNBL_INTEL(RAPTORLAKE_P, RFDS), - VULNBL_INTEL(RAPTORLAKE_S, RFDS), - VULNBL_INTEL(ATOM_GRACEMONT, RFDS), - VULNBL_INTEL(ATOM_TREMONT, MMIO | MMIO_SBDS | RFDS), - VULNBL_INTEL(ATOM_TREMONT_D, MMIO | RFDS), - VULNBL_INTEL(ATOM_TREMONT_L, MMIO | MMIO_SBDS | RFDS), - VULNBL_INTEL(ATOM_GOLDMONT, RFDS), - VULNBL_INTEL(ATOM_GOLDMONT_D, RFDS), - VULNBL_INTEL(ATOM_GOLDMONT_PLUS, RFDS), - - /* 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_TYPE (ALDERLAKE, ATOM, RFDS), - VULNBL_INTEL_TYPE (RAPTORLAKE, ATOM, RFDS), + VULNBL_INTEL( IVYBRIDGE, SRBDS), + VULNBL_INTEL( HASWELL, SRBDS), + VULNBL_INTEL( HASWELL_L, SRBDS), + VULNBL_INTEL( HASWELL_G, SRBDS), + VULNBL_INTEL( HASWELL_X, MMIO), + VULNBL_INTEL( BROADWELL_D, MMIO), + VULNBL_INTEL( BROADWELL_G, SRBDS), + VULNBL_INTEL( BROADWELL_X, MMIO), + VULNBL_INTEL( BROADWELL, SRBDS), + VULNBL_INTEL( SKYLAKE_X, MMIO | RETBLEED | GDS), + VULNBL_INTEL( SKYLAKE_L, MMIO | RETBLEED | GDS | SRBDS), + VULNBL_INTEL( SKYLAKE, MMIO | RETBLEED | GDS | SRBDS), + VULNBL_INTEL( KABYLAKE_L, MMIO | RETBLEED | GDS | SRBDS), + VULNBL_INTEL( KABYLAKE, MMIO | RETBLEED | GDS | SRBDS), + VULNBL_INTEL( CANNONLAKE_L, RETBLEED), + VULNBL_INTEL( ICELAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS), + VULNBL_INTEL( ICELAKE_D, MMIO | GDS), + VULNBL_INTEL( ICELAKE_X, MMIO | GDS), + VULNBL_INTEL( COMETLAKE, MMIO | MMIO_SBDS | RETBLEED | GDS), + VULNBL_INTEL_STEPPINGS( COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED), + VULNBL_INTEL( COMETLAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS), + VULNBL_INTEL( TIGERLAKE_L, GDS), + VULNBL_INTEL( TIGERLAKE, GDS), + VULNBL_INTEL( LAKEFIELD, MMIO | MMIO_SBDS | RETBLEED), + VULNBL_INTEL( ROCKETLAKE, MMIO | RETBLEED | GDS), + VULNBL_INTEL_TYPE( ALDERLAKE, ATOM, RFDS), + VULNBL_INTEL( ALDERLAKE_L, RFDS), + VULNBL_INTEL_TYPE( RAPTORLAKE, ATOM, RFDS), + VULNBL_INTEL( RAPTORLAKE_P, RFDS), + VULNBL_INTEL( RAPTORLAKE_S, RFDS), + VULNBL_INTEL( ATOM_GRACEMONT, RFDS), + VULNBL_INTEL( ATOM_TREMONT, MMIO | MMIO_SBDS | RFDS), + VULNBL_INTEL( ATOM_TREMONT_D, MMIO | RFDS), + VULNBL_INTEL( ATOM_TREMONT_L, MMIO | MMIO_SBDS | RFDS), + VULNBL_INTEL( ATOM_GOLDMONT, RFDS), + VULNBL_INTEL( ATOM_GOLDMONT_D, RFDS), + VULNBL_INTEL( ATOM_GOLDMONT_PLUS, RFDS), VULNBL_AMD(0x15, RETBLEED), VULNBL_AMD(0x16, RETBLEED),
On Wed, Jul 03, 2024 at 11:26:13AM -0700, Pawan Gupta wrote: > On Tue, Jul 02, 2024 at 06:04:33PM -0700, Josh Poimboeuf wrote: > > Same comment here, these should be inline with the main list. Maybe > > there's some way to structure the indentations so they align better > > vertically with the STEPPINGS/TYPE variants. > > This is how it is turning out to be: > + VULNBL_INTEL( IVYBRIDGE, SRBDS), > + VULNBL_INTEL( HASWELL, SRBDS), > + VULNBL_INTEL( HASWELL_L, SRBDS), > + VULNBL_INTEL( HASWELL_G, SRBDS), > + VULNBL_INTEL( HASWELL_X, MMIO), > + VULNBL_INTEL( BROADWELL_D, MMIO), > + VULNBL_INTEL( BROADWELL_G, SRBDS), > + VULNBL_INTEL( BROADWELL_X, MMIO), > + VULNBL_INTEL( BROADWELL, SRBDS), > + VULNBL_INTEL( SKYLAKE_X, MMIO | RETBLEED | GDS), > + VULNBL_INTEL( SKYLAKE_L, MMIO | RETBLEED | GDS | SRBDS), > + VULNBL_INTEL( SKYLAKE, MMIO | RETBLEED | GDS | SRBDS), > + VULNBL_INTEL( KABYLAKE_L, MMIO | RETBLEED | GDS | SRBDS), > + VULNBL_INTEL( KABYLAKE, MMIO | RETBLEED | GDS | SRBDS), > + VULNBL_INTEL( CANNONLAKE_L, RETBLEED), > + VULNBL_INTEL( ICELAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS), > + VULNBL_INTEL( ICELAKE_D, MMIO | GDS), > + VULNBL_INTEL( ICELAKE_X, MMIO | GDS), > + VULNBL_INTEL( COMETLAKE, MMIO | MMIO_SBDS | RETBLEED | GDS), > + VULNBL_INTEL_STEPPINGS( COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED), > + VULNBL_INTEL( COMETLAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS), > + VULNBL_INTEL( TIGERLAKE_L, GDS), > + VULNBL_INTEL( TIGERLAKE, GDS), > + VULNBL_INTEL( LAKEFIELD, MMIO | MMIO_SBDS | RETBLEED), > + VULNBL_INTEL( ROCKETLAKE, MMIO | RETBLEED | GDS), > + VULNBL_INTEL_TYPE( ALDERLAKE, ATOM, RFDS), > + VULNBL_INTEL( ALDERLAKE_L, RFDS), > + VULNBL_INTEL_TYPE( RAPTORLAKE, ATOM, RFDS), > + VULNBL_INTEL( RAPTORLAKE_P, RFDS), > + VULNBL_INTEL( RAPTORLAKE_S, RFDS), > + VULNBL_INTEL( ATOM_GRACEMONT, RFDS), > + VULNBL_INTEL( ATOM_TREMONT, MMIO | MMIO_SBDS | RFDS), > + VULNBL_INTEL( ATOM_TREMONT_D, MMIO | RFDS), > + VULNBL_INTEL( ATOM_TREMONT_L, MMIO | MMIO_SBDS | RFDS), > + VULNBL_INTEL( ATOM_GOLDMONT, RFDS), > + VULNBL_INTEL( ATOM_GOLDMONT_D, RFDS), > + VULNBL_INTEL( ATOM_GOLDMONT_PLUS, RFDS), Looks good to me. The bug bits could also be vertically aligned, but that might offend those with undersized terminals :-)
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 7e5cd14e509f..86e0c69a60f6 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1209,6 +1209,11 @@ 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_TYPE(vfm, cpu_type, issues) \ + X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, \ + X86_HW_CPU_TYPE_INTEL_##cpu_type, \ + issues) + #define VULNBL_AMD(family, blacklist) \ VULNBL(AMD, family, X86_MODEL_ANY, blacklist) @@ -1255,9 +1260,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 +1274,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_TYPE (ALDERLAKE, ATOM, RFDS), + VULNBL_INTEL_TYPE (RAPTORLAKE, ATOM, RFDS), VULNBL_AMD(0x15, RETBLEED), VULNBL_AMD(0x16, RETBLEED),
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 | 9 +++++++-- 2 files changed, 7 insertions(+), 10 deletions(-)