| Message ID | 20240627-add-cpu-type-v2-9-f927bde83ad0@linux.intel.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Headers | show |
| Series | Add CPU-type to topology | expand |
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.
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(-)