From 195b1745c4b5c7ac61d35228485d4f548d9ad3a2 Mon Sep 17 00:00:00 2001 From: Ben Hutchings Date: Tue, 5 May 2020 02:21:33 +0100 Subject: [PATCH] Avoid an ABI change for SRBDS Adding the x86_cpu_id::steppings field is an ABI change. It doesn't seem worth the trouble of another ABI bump just to be able to report some potential future CPU steppings as invulnerable. Until we have other change that require an ABI bump, we'll match the affected models regardless of stepping. Keep the reverted patch in the queue so that the reverting patch will continue to be applied when we rebase onto a new stable update. --- debian/changelog | 2 +- ...steppings-field-to-struct-x86_cpu_id.patch | 99 +++++++++++++++++++ ...6-speculation-do-not-match-steppings.patch | 27 +++++ debian/patches/series | 2 + 4 files changed, 129 insertions(+), 1 deletion(-) create mode 100644 debian/patches/debian/abi/revert-x86-cpu-add-a-steppings-field-to-struct-x86_cpu_id.patch create mode 100644 debian/patches/debian/abi/x86-speculation-do-not-match-steppings.patch diff --git a/debian/changelog b/debian/changelog index 01ded5bde..ec8f7f3bd 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,12 +2,12 @@ linux (4.19.118-2+deb10u1) UNRELEASED; urgency=medium * [x86] Add support for mitigation of Special Register Buffer Data Sampling (SRBDS) (CVE-2020-0543): - - x86/cpu: Add a steppings field to struct x86_cpu_id - x86/cpu: Add 'table' argument to cpu_matches() - x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation - x86/speculation: Add SRBDS vulnerability and mitigation documentation - x86/speculation: Add Ivy Bridge to affected list + * [x86] speculation: Do not match steppings, to avoid an ABI change -- Ben Hutchings Tue, 05 May 2020 02:03:59 +0100 diff --git a/debian/patches/debian/abi/revert-x86-cpu-add-a-steppings-field-to-struct-x86_cpu_id.patch b/debian/patches/debian/abi/revert-x86-cpu-add-a-steppings-field-to-struct-x86_cpu_id.patch new file mode 100644 index 000000000..12a76dd4d --- /dev/null +++ b/debian/patches/debian/abi/revert-x86-cpu-add-a-steppings-field-to-struct-x86_cpu_id.patch @@ -0,0 +1,99 @@ +From: Ben Hutchings +Date: Tue, 05 May 2020 02:19:23 +0100 +Subject: Revert "x86/cpu: Add a steppings field to struct x86_cpu_id" +Forwarded: not-needed + +Adding the x86_cpu_id::steppings field is an ABI change. It doesn't +seem worth the trouble of another ABI bump just to be able to report +some potential future CPU steppings as invulnerable. Until we have +other change that require an ABI bump, we'll match the affected models +regardless of stepping. + +--- +--- a/arch/x86/include/asm/cpu_device_id.h ++++ b/arch/x86/include/asm/cpu_device_id.h +@@ -9,33 +9,6 @@ + + #include + +-#define X86_STEPPINGS(mins, maxs) GENMASK(maxs, mins) +- +-/** +- * X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE - Base macro for CPU matching +- * @_vendor: The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY +- * The name is expanded to X86_VENDOR_@_vendor +- * @_family: The family number or X86_FAMILY_ANY +- * @_model: The model number, model constant or X86_MODEL_ANY +- * @_steppings: Bitmask for steppings, stepping constant or X86_STEPPING_ANY +- * @_feature: A X86_FEATURE bit or X86_FEATURE_ANY +- * @_data: Driver specific data or NULL. The internal storage +- * format is unsigned long. The supplied value, pointer +- * etc. is casted to unsigned long internally. +- * +- * Backport version to keep the SRBDS pile consistant. No shorter variants +- * required for this. +- */ +-#define X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \ +- _steppings, _feature, _data) { \ +- .vendor = X86_VENDOR_##_vendor, \ +- .family = _family, \ +- .model = _model, \ +- .steppings = _steppings, \ +- .feature = _feature, \ +- .driver_data = (unsigned long) _data \ +-} +- + extern const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match); + + #endif +--- a/arch/x86/kernel/cpu/match.c ++++ b/arch/x86/kernel/cpu/match.c +@@ -34,18 +34,13 @@ const struct x86_cpu_id *x86_match_cpu(c + const struct x86_cpu_id *m; + struct cpuinfo_x86 *c = &boot_cpu_data; + +- for (m = match; +- m->vendor | m->family | m->model | m->steppings | m->feature; +- m++) { ++ for (m = match; m->vendor | m->family | m->model | m->feature; m++) { + if (m->vendor != X86_VENDOR_ANY && c->x86_vendor != m->vendor) + continue; + if (m->family != X86_FAMILY_ANY && c->x86 != m->family) + continue; + if (m->model != X86_MODEL_ANY && c->x86_model != m->model) + continue; +- if (m->steppings != X86_STEPPING_ANY && +- !(BIT(c->x86_stepping) & m->steppings)) +- continue; + if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature)) + continue; + return m; +--- a/include/linux/mod_devicetable.h ++++ b/include/linux/mod_devicetable.h +@@ -621,10 +621,6 @@ struct mips_cdmm_device_id { + /* + * MODULE_DEVICE_TABLE expects this struct to be called x86cpu_device_id. + * Although gcc seems to ignore this error, clang fails without this define. +- * +- * Note: The ordering of the struct is different from upstream because the +- * static initializers in kernels < 5.7 still use C89 style while upstream +- * has been converted to proper C99 initializers. + */ + #define x86cpu_device_id x86_cpu_id + struct x86_cpu_id { +@@ -633,7 +629,6 @@ struct x86_cpu_id { + __u16 model; + __u16 feature; /* bit index */ + kernel_ulong_t driver_data; +- __u16 steppings; + }; + + #define X86_FEATURE_MATCH(x) \ +@@ -642,7 +637,6 @@ struct x86_cpu_id { + #define X86_VENDOR_ANY 0xffff + #define X86_FAMILY_ANY 0 + #define X86_MODEL_ANY 0 +-#define X86_STEPPING_ANY 0 + #define X86_FEATURE_ANY 0 /* Same as FPU, you can't test for that */ + + /* diff --git a/debian/patches/debian/abi/x86-speculation-do-not-match-steppings.patch b/debian/patches/debian/abi/x86-speculation-do-not-match-steppings.patch new file mode 100644 index 000000000..a0cc5f521 --- /dev/null +++ b/debian/patches/debian/abi/x86-speculation-do-not-match-steppings.patch @@ -0,0 +1,27 @@ +From: Ben Hutchings +Date: Tue, 05 May 2020 02:09:56 +0100 +Subject: x86/speculation: Do not match steppings +Forwarded: not-needed + +Adding the x86_cpu_id::steppings field is an ABI change. It doesn't +seem worth the trouble of another ABI bump just to be able to report +some potential future CPU steppings as invulnerable. Until we have +other change that require an ABI bump, match the affected models +regardless of stepping. + +--- +--- a/arch/x86/kernel/cpu/common.c ++++ b/arch/x86/kernel/cpu/common.c +@@ -1013,10 +1013,8 @@ static const __initconst struct x86_cpu_ + {} + }; + +-#define VULNBL_INTEL_STEPPINGS(model, steppings, issues) \ +- X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6, \ +- INTEL_FAM6_##model, steppings, \ +- X86_FEATURE_ANY, issues) ++#define VULNBL_INTEL_STEPPINGS(model, steppings, issues) \ ++ VULNWL_INTEL(model, issues) + + #define SRBDS BIT(0) + diff --git a/debian/patches/series b/debian/patches/series index 03e6594de..e06a570ba 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -307,3 +307,5 @@ bugfix/x86/srbds/0004-x86-speculation-Add-SRBDS-vulnerability-and-mitigati.patch bugfix/x86/srbds/0005-x86-speculation-Add-Ivy-Bridge-to-affected-list.patch # ABI maintenance +debian/abi/x86-speculation-do-not-match-steppings.patch +debian/abi/revert-x86-cpu-add-a-steppings-field-to-struct-x86_cpu_id.patch