Slow Randomizing Boosts DoS v4.4.219 backport 0
Subsystems (17)
cover Slow Randomizing Boosts DoS v4.4.219 backport 0
From: mark gross <[email protected]>
Subject: [PATCH 0/5] Slow Ranomizing Boosts DoS linux-4.4.y backport
This is a backport of the backports done by Thomas for linux-4.14.y to linux-4.4.y.
The backport needed a backport of one additional dependency for cpu_data-x86_mask getting renamed to x86_stepping.
This was tested by the test engineer who tested the other SRBDS implementations and it seems to work.
Jia Zhang (1):
x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping
Mark Gross (4):
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
.../ABI/testing/sysfs-devices-system-cpu | 1 + .../special-register-buffer-data-sampling.rst | 148 ++++++++++++++++++ Documentation/kernel-parameters.txt | 20 +++ arch/x86/include/asm/acpi.h | 2 +- arch/x86/include/asm/cpu_device_id.h | 27 ++++ arch/x86/include/asm/cpufeatures.h | 2 + arch/x86/include/asm/msr-index.h | 4 + arch/x86/include/asm/processor.h | 2 +- arch/x86/kernel/amd_nb.c | 2 +- arch/x86/kernel/asm-offsets_32.c | 2 +- arch/x86/kernel/cpu/amd.c | 26 +-- arch/x86/kernel/cpu/bugs.c | 106 +++++++++++++ arch/x86/kernel/cpu/centaur.c | 4 +- arch/x86/kernel/cpu/common.c | 62 ++++++-- arch/x86/kernel/cpu/cpu.h | 1 + arch/x86/kernel/cpu/cyrix.c | 2 +- arch/x86/kernel/cpu/intel.c | 20 +-- arch/x86/kernel/cpu/match.c | 7 +- arch/x86/kernel/cpu/microcode/intel.c | 4 +- arch/x86/kernel/cpu/mtrr/generic.c | 2 +- arch/x86/kernel/cpu/mtrr/main.c | 4 +- arch/x86/kernel/cpu/perf_event_intel.c | 2 +- arch/x86/kernel/cpu/perf_event_intel_lbr.c | 2 +- arch/x86/kernel/cpu/perf_event_p6.c | 2 +- arch/x86/kernel/cpu/proc.c | 4 +- arch/x86/kernel/head_32.S | 4 +- arch/x86/kernel/mpparse.c | 2 +- drivers/base/cpu.c | 8 + drivers/char/hw_random/via-rng.c | 2 +- drivers/cpufreq/acpi-cpufreq.c | 2 +- drivers/cpufreq/longhaul.c | 6 +- drivers/cpufreq/p4-clockmod.c | 2 +- drivers/cpufreq/powernow-k7.c | 2 +- drivers/cpufreq/speedstep-centrino.c | 4 +- drivers/cpufreq/speedstep-lib.c | 6 +- drivers/crypto/padlock-aes.c | 2 +- drivers/edac/amd64_edac.c | 2 +- drivers/edac/mce_amd.c | 2 +- drivers/hwmon/coretemp.c | 6 +- drivers/hwmon/hwmon-vid.c | 2 +- drivers/hwmon/k10temp.c | 2 +- drivers/hwmon/k8temp.c | 2 +- drivers/video/fbdev/geode/video_gx.c | 2 +- include/linux/mod_devicetable.h | 6 + 44 files changed, 442 insertions(+), 80 deletions(-) create mode 100644 Documentation/hw-vuln/special-register-buffer-data-sampling.rst
Signature · 1 line
2.17.1
PATCH 2/5 Slow Randomizing Boosts DoS v4.4.219 backport 2
From: Mark Gross <[email protected]>
Subject: [PATCH 2/5] x86/cpu: Add a steppings field to struct x86_cpu_id
commit e9d7144597b10ff13ff2264c059f7d4a7fbc89ac upstream
Intel uses the same family/model for several CPUs. Sometimes the stepping must be checked to tell them apart.
On x86 there can be at most 16 steppings. Add a steppings bitmask to x86_cpu_id and a X86_MATCH_VENDOR_FAMILY_MODEL_STEPPING_FEATURE macro and support for matching against family/model/stepping.
[ bp: Massage.
tglx: Lightweight variant for backporting ]
Signed-off-by Mark Gross <[email protected]>
Signed-off-by Borislav Petkov <[email protected]>
Signed-off-by Thomas Gleixner <[email protected]>
Reviewed-by Tony Luck <[email protected]>
Reviewed-by Josh Poimboeuf <[email protected]>
--- arch/x86/include/asm/cpu_device_id.h | 27 +++++++++++++++++++++++++++ arch/x86/kernel/cpu/match.c | 7 ++++++- include/linux/mod_devicetable.h | 6 ++++++ 3 files changed, 39 insertions(+), 1 deletion(-)
arch/x86/include/asm/cpu_device_id.h +27 -0
@@ -8,6 +8,33 @@#include <linux/mod_devicetable.h> +#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
arch/x86/kernel/cpu/match.c +6 -1
@@ -33,13 +33,18 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)const struct x86_cpu_id *m;struct cpuinfo_x86 *c = &boot_cpu_data; -for (m = match; m->vendor | m->family | m->model | m->feature; m++) { +for (m = match; + m->vendor | m->family | m->model | m->steppings | 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;
include/linux/mod_devicetable.h +6 -0
@@ -572,6 +572,10 @@ 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_idstruct x86_cpu_id {
@@ -580,6 +584,7 @@ struct x86_cpu_id {__u16 model;__u16 feature;/* bit index */ kernel_ulong_t driver_data; +__u16 steppings; };#define X86_FEATURE_MATCH (x) \
@@ -588,6 +593,7 @@ 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 */ /*
Signature · 1 line
2.17.1
PATCH 1/5 Slow Randomizing Boosts DoS v4.4.219 backport 1
In reply to mark grossFrom: Jia Zhang <[email protected]>
Subject: [PATCH 1/5] x86/cpu: Rename cpu_data.x86_mask to
cpu_data.x86_stepping
commit b399151cb48db30ad1e0e93dd40d68c6d007b637 upstream.
x86_mask is a confusing name which is hard to associate with the processor's stepping.
Additionally, correct an indent issue in lib/cpu.c.
Signed-off-by Jia Zhang <[email protected]>
[ Updated it to more recent kernels. ]
Cc Linus Torvalds <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Thomas Gleixner <[email protected]>
Signed-off-by Ingo Molnar <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
Conflicts:
arch/x86/events/intel/core.c arch/x86/events/intel/lbr.c arch/x86/events/intel/p6.c arch/x86/kernel/cpu/common.c arch/x86/kernel/cpu/intel.c arch/x86/kernel/cpu/microcode/intel.c arch/x86/kernel/mpparse.c arch/x86/lib/cpu.c drivers/cpufreq/acpi-cpufreq.c drivers/cpufreq/powernow-k7.c --- arch/x86/include/asm/acpi.h | 2 +- arch/x86/include/asm/processor.h | 2 +- arch/x86/kernel/amd_nb.c | 2 +- arch/x86/kernel/asm-offsets_32.c | 2 +- arch/x86/kernel/cpu/amd.c | 26 +++++++++++----------- arch/x86/kernel/cpu/centaur.c | 4 ++-- arch/x86/kernel/cpu/common.c | 8 +++---- arch/x86/kernel/cpu/cyrix.c | 2 +- arch/x86/kernel/cpu/intel.c | 20 ++++++++--------- arch/x86/kernel/cpu/microcode/intel.c | 4 ++-- arch/x86/kernel/cpu/mtrr/generic.c | 2 +- arch/x86/kernel/cpu/mtrr/main.c | 4 ++-- arch/x86/kernel/cpu/perf_event_intel.c | 2 +- arch/x86/kernel/cpu/perf_event_intel_lbr.c | 2 +- arch/x86/kernel/cpu/perf_event_p6.c | 2 +- arch/x86/kernel/cpu/proc.c | 4 ++-- arch/x86/kernel/head_32.S | 4 ++-- arch/x86/kernel/mpparse.c | 2 +- drivers/char/hw_random/via-rng.c | 2 +- drivers/cpufreq/acpi-cpufreq.c | 2 +- drivers/cpufreq/longhaul.c | 6 ++--- drivers/cpufreq/p4-clockmod.c | 2 +- drivers/cpufreq/powernow-k7.c | 2 +- drivers/cpufreq/speedstep-centrino.c | 4 ++-- drivers/cpufreq/speedstep-lib.c | 6 ++--- drivers/crypto/padlock-aes.c | 2 +- drivers/edac/amd64_edac.c | 2 +- drivers/edac/mce_amd.c | 2 +- drivers/hwmon/coretemp.c | 6 ++--- drivers/hwmon/hwmon-vid.c | 2 +- drivers/hwmon/k10temp.c | 2 +- drivers/hwmon/k8temp.c | 2 +- drivers/video/fbdev/geode/video_gx.c | 2 +- 33 files changed, 69 insertions(+), 69 deletions(-)
arch/x86/include/asm/acpi.h +1 -1
@@ -92,7 +92,7 @@ static inline unsigned int acpi_processor_cstate_check(unsigned int max_cstate)if (boot_cpu_data.x86 ==0x0F && boot_cpu_data.x86_vendor ==X86_VENDOR_AMD && boot_cpu_data.x86_model <=0x05 && - boot_cpu_data.x86_mask <0x0A ) + boot_cpu_data.x86_stepping <0x0A )return 1 ;else if (amd_e400_c1e_detected)return 1 ;
arch/x86/include/asm/processor.h +1 -1
@@ -88,7 +88,7 @@ struct cpuinfo_x86 {__u8 x86;/* CPU family */ __u8 x86_vendor;/* CPU vendor */ __u8 x86_model; -__u8 x86_mask; +__u8 x86_stepping;#ifdef CONFIG_X86_32 char wp_works_ok;/* It doesn't on 386's */
arch/x86/kernel/amd_nb.c +1 -1
@@ -105,7 +105,7 @@ int amd_cache_northbridges(void)if (boot_cpu_data.x86 ==0x10 && boot_cpu_data.x86_model >=0x8 && (boot_cpu_data.x86_model >0x9 || - boot_cpu_data.x86_mask >=0x1 )) + boot_cpu_data.x86_stepping >=0x1 )) amd_northbridges.flags |=AMD_NB_L3_INDEX_DISABLE ;if (boot_cpu_data.x86 ==0x15 )
arch/x86/kernel/asm-offsets_32.c +1 -1
@@ -20,7 +20,7 @@ void foo(void)OFFSET (CPUINFO_x86, cpuinfo_x86, x86);OFFSET (CPUINFO_x86_vendor, cpuinfo_x86, x86_vendor);OFFSET (CPUINFO_x86_model, cpuinfo_x86, x86_model); -OFFSET (CPUINFO_x86_mask, cpuinfo_x86, x86_mask); +OFFSET (CPUINFO_x86_stepping, cpuinfo_x86, x86_stepping);OFFSET (CPUINFO_cpuid_level, cpuinfo_x86, cpuid_level);OFFSET (CPUINFO_x86_capability, cpuinfo_x86, x86_capability);OFFSET (CPUINFO_x86_vendor_id, cpuinfo_x86, x86_vendor_id);
arch/x86/kernel/cpu/amd.c +13 -13
@@ -112,7 +112,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)return ; } -if (c->x86_model ==6 && c->x86_mask ==1 ) { +if (c->x86_model ==6 && c->x86_stepping ==1 ) {const int K6_BUG_LOOP =1000000 ;int n;void (*f_vide)(void );
@@ -142,7 +142,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)/* K6 with old style WHCR */ if (c->x86_model <8 || - (c->x86_model ==8 && c->x86_mask <8 )) { + (c->x86_model ==8 && c->x86_stepping <8 )) {/* We can only write allocate on the low 508Mb */ if (mbytes >508 ) mbytes =508 ;
@@ -161,7 +161,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)return ; } -if ((c->x86_model ==8 && c->x86_mask >7 ) || +if ((c->x86_model ==8 && c->x86_stepping >7 ) || c->x86_model ==9 || c->x86_model ==13 ) {/* The more serious chips .. */
@@ -214,7 +214,7 @@ static void init_amd_k7(struct cpuinfo_x86 *c)* are more robust with CLK_CTL set to 200xxxxx instead of 600xxxxx * As per AMD technical note 27212 0.2 */ -if ((c->x86_model ==8 && c->x86_mask >=1 ) || (c->x86_model >8 )) { +if ((c->x86_model ==8 && c->x86_stepping >=1 ) || (c->x86_model >8 )) {rdmsr (MSR_K7_CLK_CTL , l, h);if ((l &0xfff00000 ) !=0x20000000 ) { printk(KERN_INFO
@@ -235,12 +235,12 @@ static void init_amd_k7(struct cpuinfo_x86 *c)* but they are not certified as MP capable. */ /* Athlon 660/661 is valid. */ -if ((c->x86_model ==6 ) && ((c->x86_mask ==0 ) || - (c->x86_mask ==1 ))) +if ((c->x86_model ==6 ) && ((c->x86_stepping ==0 ) || + (c->x86_stepping ==1 )))return ;/* Duron 670 is valid */ -if ((c->x86_model ==7 ) && (c->x86_mask ==0 )) +if ((c->x86_model ==7 ) && (c->x86_stepping ==0 ))return ;/*
@@ -250,8 +250,8 @@ static void init_amd_k7(struct cpuinfo_x86 *c)* See http://www.heise.de/newsticker/data/jow-18.10.01-000 for * more. */ -if (((c->x86_model ==6 ) && (c->x86_mask >=2 )) || - ((c->x86_model ==7 ) && (c->x86_mask >=1 )) || +if (((c->x86_model ==6 ) && (c->x86_stepping >=2 )) || + ((c->x86_model ==7 ) && (c->x86_stepping >=1 )) || (c->x86_model >7 ))if (cpu_has (c,X86_FEATURE_MP ))return ;
@@ -563,7 +563,7 @@ static void early_init_amd(struct cpuinfo_x86 *c)/* Set MTRR capability flag if appropriate */ if (c->x86 ==5 )if (c->x86_model ==13 || c->x86_model ==9 || - (c->x86_model ==8 && c->x86_mask >=8 )) + (c->x86_model ==8 && c->x86_stepping >=8 ))set_cpu_cap (c,X86_FEATURE_K6_MTRR );#endif #if defined(CONFIG_X86_LOCAL_APIC ) && defined(CONFIG_PCI )
@@ -902,11 +902,11 @@ static unsigned int amd_size_cache(struct cpuinfo_x86 *c, unsigned int size)/* AMD errata T13 (order #21922) */ if ((c->x86 ==6 )) {/* Duron Rev A0 */ -if (c->x86_model ==3 && c->x86_mask ==0 ) +if (c->x86_model ==3 && c->x86_stepping ==0 ) size =64 ;/* Tbird rev A1/A2 */ if (c->x86_model ==4 && - (c->x86_mask ==0 || c->x86_mask ==1 )) + (c->x86_stepping ==0 || c->x86_stepping ==1 )) size =256 ; }return size;
@@ -1043,7 +1043,7 @@ static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum) }/* OSVW unavailable or ID unknown, match family-model-stepping range */ - ms = (cpu->x86_model <<4 ) | cpu->x86_mask; + ms = (cpu->x86_model <<4 ) | cpu->x86_stepping;while ((range = *erratum++)) if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range)) && (ms >= AMD_MODEL_RANGE_START(range)) &&
arch/x86/kernel/cpu/centaur.c +2 -2
@@ -134,7 +134,7 @@ static void init_centaur(struct cpuinfo_x86 *c)clear_cpu_cap (c,X86_FEATURE_TSC );break ;case 8 : -switch (c->x86_mask) { +switch (c->x86_stepping) {default : name ="2" ;break ;
@@ -209,7 +209,7 @@ centaur_size_cache(struct cpuinfo_x86 *c, unsigned int size)* - Note, it seems this may only be in engineering samples. */ if ((c->x86 ==6 ) && (c->x86_model ==9 ) && - (c->x86_mask ==1 ) && (size ==65 )) + (c->x86_stepping ==1 ) && (size ==65 )) size -=1 ;return size; }
arch/x86/kernel/cpu/common.c +4 -4
@@ -652,7 +652,7 @@ void cpu_detect(struct cpuinfo_x86 *c)cpuid (0x00000001 , &tfms, &misc, &junk, &cap0); c->x86 = (tfms >>8 ) &0xf ; c->x86_model = (tfms >>4 ) &0xf ; - c->x86_mask = tfms &0xf ; + c->x86_stepping = tfms &0xf ;if (c->x86 ==0xf ) c->x86 += (tfms >>20 ) &0xff ;
@@ -1157,7 +1157,7 @@ static void identify_cpu(struct cpuinfo_x86 *c) c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size =0 ; c->x86_vendor =X86_VENDOR_UNKNOWN ; - c->x86_model = c->x86_mask =0 ;/* So far unknown... */ + c->x86_model = c->x86_stepping =0 ;/* So far unknown... */ c->x86_vendor_id[0 ] ='\0' ;/* Unset */ c->x86_model_id[0 ] ='\0' ;/* Unset */ c->x86_max_cores =1 ;
@@ -1403,8 +1403,8 @@ void print_cpu_info(struct cpuinfo_x86 *c)printk (KERN_CONT " (family: 0x%x, model: 0x%x" , c->x86, c->x86_model); -if (c->x86_mask || c->cpuid_level >=0 ) -printk (KERN_CONT ", stepping: 0x%x)\n" , c->x86_mask); +if (c->x86_stepping || c->cpuid_level >=0 ) +pr_cont (", stepping: 0x%x)\n" , c->x86_stepping);else printk (KERN_CONT ")\n" );
arch/x86/kernel/cpu/cyrix.c +1 -1
@@ -212,7 +212,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)/* common case step number/rev -- exceptions handled below */ c->x86_model = (dir1 >>4 ) +1 ; - c->x86_mask = dir1 &0xf ; + c->x86_stepping = dir1 &0xf ;/* Now cook; the original recipe is by Channing Corn, from Cyrix. * We do the same thing for each generation: we work out
arch/x86/kernel/cpu/intel.c +10 -10
@@ -80,7 +80,7 @@ static bool bad_spectre_microcode(struct cpuinfo_x86 *c)for (i =0 ; i <ARRAY_SIZE (spectre_bad_microcodes); i++) {if (c->x86_model == spectre_bad_microcodes[i].model && - c->x86_mask == spectre_bad_microcodes[i].stepping) + c->x86_stepping == spectre_bad_microcodes[i].stepping)return (c->microcode <= spectre_bad_microcodes[i].microcode); }return false;
@@ -130,7 +130,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)* need the microcode to have already been loaded... so if it is * not, recommend a BIOS update and disable large pages. */ -if (c->x86 ==6 && c->x86_model ==0x1c && c->x86_mask <=2 && +if (c->x86 ==6 && c->x86_model ==0x1c && c->x86_stepping <=2 && c->microcode <0x20e ) {printk (KERN_WARNING "Atom PSE erratum detected, BIOS microcode update recommended\n" );clear_cpu_cap (c,X86_FEATURE_PSE );
@@ -146,7 +146,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)/* CPUID workaround for 0F33/0F34 CPU */ if (c->x86 ==0xF && c->x86_model ==0x3 - && (c->x86_mask ==0x3 || c->x86_mask ==0x4 )) + && (c->x86_stepping ==0x3 || c->x86_stepping ==0x4 )) c->x86_phys_bits =36 ;/*
@@ -246,8 +246,8 @@ int ppro_with_ram_bug(void)if (boot_cpu_data.x86_vendor ==X86_VENDOR_INTEL && boot_cpu_data.x86 ==6 && boot_cpu_data.x86_model ==1 && - boot_cpu_data.x86_mask <8 ) { -printk (KERN_INFO "Pentium Pro with Errata#50 detected. Taking evasive action.\n" ); + boot_cpu_data.x86_stepping <8 ) { +pr_info ("Pentium Pro with Errata#50 detected. Taking evasive action.\n" );return 1 ; }return 0 ;
@@ -263,7 +263,7 @@ static void intel_smp_check(struct cpuinfo_x86 *c)* Mask B, Pentium, but not Pentium MMX */ if (c->x86 ==5 && - c->x86_mask >=1 && c->x86_mask <=4 && + c->x86_stepping >=1 && c->x86_stepping <=4 && c->x86_model <=3 ) {/* * Remember we have B step Pentia with bugs
@@ -306,7 +306,7 @@ static void intel_workarounds(struct cpuinfo_x86 *c)* SEP CPUID bug: Pentium Pro reports SEP but doesn't have it until * model 3 mask 3 */ -if ((c->x86<<8 | c->x86_model<<4 | c->x86_mask) <0x633 ) +if ((c->x86<<8 | c->x86_model<<4 | c->x86_stepping) <0x633 )clear_cpu_cap (c,X86_FEATURE_SEP );/*
@@ -324,7 +324,7 @@ static void intel_workarounds(struct cpuinfo_x86 *c)* P4 Xeon errata 037 workaround. * Hardware prefetcher may cause stale data to be loaded into the cache. */ -if ((c->x86 ==15 ) && (c->x86_model ==1 ) && (c->x86_mask ==1 )) { +if ((c->x86 ==15 ) && (c->x86_model ==1 ) && (c->x86_stepping ==1 )) {if (msr_set_bit (MSR_IA32_MISC_ENABLE ,MSR_IA32_MISC_ENABLE_PREFETCH_DISABLE_BIT ) >0 ) {
@@ -340,7 +340,7 @@ static void intel_workarounds(struct cpuinfo_x86 *c)* Specification Update"). */ if (cpu_has_apic && (c->x86<<8 | c->x86_model<<4 ) ==0x520 && - (c->x86_mask <0x6 || c->x86_mask ==0xb )) + (c->x86_stepping <0x6 || c->x86_stepping ==0xb ))set_cpu_bug (c,X86_BUG_11AP );
@@ -555,7 +555,7 @@ static void init_intel(struct cpuinfo_x86 *c)case 6 :if (l2 ==128 ) p ="Celeron (Mendocino)" ; -else if (c->x86_mask ==0 || c->x86_mask ==5 ) +else if (c->x86_stepping ==0 || c->x86_stepping ==5 ) p ="Celeron-A" ;break ;
arch/x86/kernel/cpu/microcode/intel.c +2 -2
@@ -1013,7 +1013,7 @@ static bool is_blacklisted(unsigned int cpu)*/ if (c->x86 ==6 && c->x86_model ==79 && - c->x86_mask ==0x01 && + c->x86_stepping ==0x01 && llc_size_per_core >2621440 && c->microcode <0x0b000021 ) {pr_err_once ("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n" , c->microcode);
@@ -1036,7 +1036,7 @@ static enum ucode_state request_microcode_fw(int cpu, struct device *device,return UCODE_NFOUND ;sprintf (name,"intel-ucode/%02x-%02x-%02x" , - c->x86, c->x86_model, c->x86_mask); + c->x86, c->x86_model, c->x86_stepping);if (request_firmware_direct (&firmware, name, device)) {pr_debug ("data file %s load failed\n" , name);
arch/x86/kernel/cpu/mtrr/generic.c +1 -1
@@ -860,7 +860,7 @@ int generic_validate_add_page(unsigned long base, unsigned long size,*/ if (is_cpu (INTEL ) && boot_cpu_data.x86 ==6 && boot_cpu_data.x86_model ==1 && - boot_cpu_data.x86_mask <=7 ) { + boot_cpu_data.x86_stepping <=7 ) {if (base & ((1 << (22 -PAGE_SHIFT )) -1 )) {pr_warning ("mtrr: base(0x%lx000) is not 4 MiB aligned\n" , base);return -EINVAL ;
arch/x86/kernel/cpu/mtrr/main.c +2 -2
@@ -699,8 +699,8 @@ void __init mtrr_bp_init(void)if (boot_cpu_data.x86_vendor ==X86_VENDOR_INTEL && boot_cpu_data.x86 ==0xF && boot_cpu_data.x86_model ==0x3 && - (boot_cpu_data.x86_mask ==0x3 || - boot_cpu_data.x86_mask ==0x4 )) + (boot_cpu_data.x86_stepping ==0x3 || + boot_cpu_data.x86_stepping ==0x4 )) phys_addr =36 ; size_or_mask =SIZE_OR_MASK_BITS (phys_addr);
arch/x86/kernel/cpu/perf_event_intel.c +1 -1
@@ -3051,7 +3051,7 @@ static int intel_snb_pebs_broken(int cpu)break ;case 45 :/* SNB-EP */ -switch (cpu_data (cpu).x86_mask) { +switch (cpu_data (cpu).x86_stepping) {case 6 : rev =0x618 ;break ;case 7 : rev =0x70c ;break ; }
arch/x86/kernel/cpu/perf_event_intel_lbr.c +1 -1
@@ -1017,7 +1017,7 @@ void __init intel_pmu_lbr_init_atom(void)* on PMU interrupt */ if (boot_cpu_data.x86_model ==28 - && boot_cpu_data.x86_mask <10 ) { + && boot_cpu_data.x86_stepping <10 ) {pr_cont ("LBR disabled due to erratum" );return ; }
arch/x86/kernel/cpu/perf_event_p6.c +1 -1
@@ -233,7 +233,7 @@ static __initconst const struct x86_pmu p6_pmu = {static __init void p6_pmu_rdpmc_quirk (void ) { -if (boot_cpu_data.x86_mask <9 ) { +if (boot_cpu_data.x86_stepping <9 ) {/* * PPro erratum 26; fixed in stepping 9 and above. */
arch/x86/kernel/cpu/proc.c +2 -2
@@ -70,8 +70,8 @@ static int show_cpuinfo(struct seq_file *m, void *v) c->x86_model, c->x86_model_id[0] ? c->x86_model_id : "unknown"); -if (c->x86_mask || c->cpuid_level >=0 ) -seq_printf (m,"stepping\t: %d\n" , c->x86_mask); +if (c->x86_stepping || c->cpuid_level >=0 ) +seq_printf (m,"stepping\t: %d\n" , c->x86_stepping);else seq_puts (m,"stepping\t: unknown\n" );if (c->microcode)
arch/x86/kernel/head_32.S +2 -2
@@ -34,7 +34,7 @@ #define X86 new_cpu_data+CPUINFO_x86 #define X86_VENDOR new_cpu_data+CPUINFO_x86_vendor #define X86_MODEL new_cpu_data+CPUINFO_x86_model -#define X86_MASK new_cpu_data+CPUINFO_x86_mask +#define X86_STEPPING new_cpu_data+CPUINFO_x86_stepping #define X86_HARD_MATH new_cpu_data+CPUINFO_hard_math #define X86_CPUID new_cpu_data+CPUINFO_cpuid_level #define X86_CAPABILITY new_cpu_data+CPUINFO_x86_capability
@@ -440,7 +440,7 @@ enable_paging: shrb $4,%al movb %al,X86_MODEL andb $0x0f,%cl # mask mask revision - movb %cl,X86_MASK + movb %cl,X86_STEPPING movl %edx,X86_CAPABILITY is486:
arch/x86/kernel/mpparse.c +1 -1
@@ -407,7 +407,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type) processor.apicver = mpc_default_type >4 ?0x10 :0x01 ; processor.cpuflag =CPU_ENABLED ; processor.cpufeature = (boot_cpu_data.x86 <<8 ) | - (boot_cpu_data.x86_model <<4 ) | boot_cpu_data.x86_mask; + (boot_cpu_data.x86_model <<4 ) | boot_cpu_data.x86_stepping; processor.featureflag = boot_cpu_data.x86_capability[0 ]; processor.reserved[0 ] =0 ; processor.reserved[1 ] =0 ;
drivers/char/hw_random/via-rng.c +1 -1
@@ -166,7 +166,7 @@ static int via_rng_init(struct hwrng *rng)/* Enable secondary noise source on CPUs where it is present. */ /* Nehemiah stepping 8 and higher */ -if ((c->x86_model ==9 ) && (c->x86_mask >7 )) +if ((c->x86_model ==9 ) && (c->x86_stepping >7 )) lo |=VIA_NOISESRC2 ;/* Esther */
drivers/cpufreq/acpi-cpufreq.c +1 -1
@@ -639,7 +639,7 @@ static int acpi_cpufreq_blacklist(struct cpuinfo_x86 *c)if (c->x86_vendor ==X86_VENDOR_INTEL ) {if ((c->x86 ==15 ) && (c->x86_model ==6 ) && - (c->x86_mask ==8 )) { + (c->x86_stepping ==8 )) {printk (KERN_INFO "acpi-cpufreq: Intel(R) " "Xeon(R) 7100 Errata AL30, processors may " "lock up on frequency changes: disabling "
drivers/cpufreq/longhaul.c +3 -3
@@ -786,7 +786,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy)break ;case 7 : -switch (c->x86_mask) { +switch (c->x86_stepping) {case 0 : longhaul_version =TYPE_LONGHAUL_V1 ; cpu_model =CPU_SAMUEL2 ;
@@ -798,7 +798,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy)break ; case 1 ... 15: longhaul_version =TYPE_LONGHAUL_V2 ; -if (c->x86_mask <8 ) { +if (c->x86_stepping <8 ) { cpu_model =CPU_SAMUEL2 ; cpuname ="C3 'Samuel 2' [C5B]" ; }else {
@@ -825,7 +825,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy) numscales =32 ;memcpy (mults, nehemiah_mults,sizeof (nehemiah_mults));memcpy (eblcr, nehemiah_eblcr,sizeof (nehemiah_eblcr)); -switch (c->x86_mask) { +switch (c->x86_stepping) { case 0 ... 1: cpu_model =CPU_NEHEMIAH ; cpuname ="C3 'Nehemiah A' [C5XLOE]" ;
drivers/cpufreq/p4-clockmod.c +1 -1
@@ -176,7 +176,7 @@ static int cpufreq_p4_cpu_init(struct cpufreq_policy *policy)#endif /* Errata workaround */ - cpuid = (c->x86 <<8 ) | (c->x86_model <<4 ) | c->x86_mask; + cpuid = (c->x86 <<8 ) | (c->x86_model <<4 ) | c->x86_stepping;switch (cpuid) {case 0x0f07 :case 0x0f0a :
drivers/cpufreq/powernow-k7.c +1 -1
@@ -132,7 +132,7 @@ static int check_powernow(void)return 0 ; } -if ((c->x86_model ==6 ) && (c->x86_mask ==0 )) { +if ((c->x86_model ==6 ) && (c->x86_stepping ==0 )) { printk(KERN_INFO PFX "K7 660[A0] core detected, " "enabling errata workarounds\n"); have_a0 =1 ;
drivers/cpufreq/speedstep-centrino.c +2 -2
@@ -36,7 +36,7 @@ struct cpu_id {__u8 x86;/* CPU family */ __u8 x86_model;/* model */ -__u8 x86_mask;/* stepping */ +__u8 x86_stepping;/* stepping */ };enum {
@@ -276,7 +276,7 @@ static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, {if ((c->x86 == x->x86) && (c->x86_model == x->x86_model) && - (c->x86_mask == x->x86_mask)) + (c->x86_stepping == x->x86_stepping))return 1 ;return 0 ; }
drivers/cpufreq/speedstep-lib.c +3 -3
@@ -270,9 +270,9 @@ unsigned int speedstep_detect_processor(void) ebx =cpuid_ebx (0x00000001 ); ebx &=0x000000FF ; -pr_debug ("ebx value is %x, x86_mask is %x\n" , ebx, c->x86_mask); +pr_debug ("ebx value is %x, x86_stepping is %x\n" , ebx, c->x86_stepping); -switch (c->x86_mask) { +switch (c->x86_stepping) {case 4 :/* * B-stepping [M-P4-M]
@@ -359,7 +359,7 @@ unsigned int speedstep_detect_processor(void) msr_lo, msr_hi);if ((msr_hi & (1 <<18 )) && (relaxed_check ?1 : (msr_hi & (3 <<24 )))) { -if (c->x86_mask ==0x01 ) { +if (c->x86_stepping ==0x01 ) {pr_debug ("early PIII version\n" );return SPEEDSTEP_CPU_PIII_C_EARLY ; }else
drivers/crypto/padlock-aes.c +1 -1
@@ -535,7 +535,7 @@ static int __init padlock_init(void) printk(KERN_NOTICE PFX "Using VIA PadLock ACE for AES algorithm.\n"); -if (c->x86 ==6 && c->x86_model ==15 && c->x86_mask ==2 ) { +if (c->x86 ==6 && c->x86_model ==15 && c->x86_stepping ==2 ) { ecb_fetch_blocks =MAX_ECB_FETCH_BLOCKS ; cbc_fetch_blocks =MAX_CBC_FETCH_BLOCKS ; printk(KERN_NOTICE PFX "VIA Nano stepping 2 detected: enabling workaround.\n");
drivers/edac/amd64_edac.c +1 -1
@@ -2715,7 +2715,7 @@ static struct amd64_family_type *per_family_init(struct amd64_pvt *pvt)struct amd64_family_type *fam_type =NULL ; pvt->ext_model = boot_cpu_data.x86_model >>4 ; - pvt->stepping = boot_cpu_data.x86_mask; + pvt->stepping = boot_cpu_data.x86_stepping; pvt->model = boot_cpu_data.x86_model; pvt->fam = boot_cpu_data.x86;
drivers/edac/mce_amd.c +1 -1
@@ -760,7 +760,7 @@ int amd_decode_mce(struct notifier_block *nb, unsigned long val, void *data) pr_emerg(HW_ERR "CPU:%d (%x:%x:%x) MC%d_STATUS[%s|%s|%s|%s|%s", m->extcpu, - c->x86, c->x86_model, c->x86_mask, + c->x86, c->x86_model, c->x86_stepping, m->bank, ((m->status & MCI_STATUS_OVER) ? "Over" : "-"), ((m->status & MCI_STATUS_UC) ? "UE" :
drivers/hwmon/coretemp.c +3 -3
@@ -269,13 +269,13 @@ static int adjust_tjmax(struct cpuinfo_x86 *c, u32 id, struct device *dev)for (i =0 ; i <ARRAY_SIZE (tjmax_model_table); i++) {const struct tjmax_model *tm = &tjmax_model_table[i];if (c->x86_model == tm->model && - (tm->mask ==ANY || c->x86_mask == tm->mask)) + (tm->mask ==ANY || c->x86_stepping == tm->mask))return tm->tjmax; }/* Early chips have no MSR for TjMax */ -if (c->x86_model ==0xf && c->x86_mask <4 ) +if (c->x86_model ==0xf && c->x86_stepping <4 ) usemsr_ee =0 ;if (c->x86_model >0xe && usemsr_ee) {
@@ -426,7 +426,7 @@ static int chk_ucode_version(unsigned int cpu)* Readings might stop update when processor visited too deep sleep, * fixed for stepping D0 (6EC). */ -if (c->x86_model ==0xe && c->x86_mask <0xc && c->microcode <0x39 ) { +if (c->x86_model ==0xe && c->x86_stepping <0xc && c->microcode <0x39 ) {pr_err ("Errata AE18 not fixed, update BIOS or microcode of the CPU!\n" );return -ENODEV ; }
drivers/hwmon/hwmon-vid.c +1 -1
@@ -293,7 +293,7 @@ u8 vid_which_vrm(void)if (c->x86 <6 )/* Any CPU with family lower than 6 */ return 0 ;/* doesn't have VID */ - vrm_ret =find_vrm (c->x86, c->x86_model, c->x86_mask, c->x86_vendor); + vrm_ret =find_vrm (c->x86, c->x86_model, c->x86_stepping, c->x86_vendor);if (vrm_ret ==134 ) vrm_ret =get_via_model_d_vrm ();if (vrm_ret ==0 )
drivers/hwmon/k10temp.c +1 -1
@@ -179,7 +179,7 @@ static bool has_erratum_319(struct pci_dev *pdev)* and AM3 formats, but that's the best we can do. */ return boot_cpu_data.x86_model <4 || - (boot_cpu_data.x86_model ==4 && boot_cpu_data.x86_mask <=2 ); + (boot_cpu_data.x86_model ==4 && boot_cpu_data.x86_stepping <=2 ); } static int k10temp_probe(struct pci_dev *pdev,
drivers/hwmon/k8temp.c +1 -1
@@ -187,7 +187,7 @@ static int k8temp_probe(struct pci_dev *pdev,return -ENOMEM ; model = boot_cpu_data.x86_model; - stepping = boot_cpu_data.x86_mask; + stepping = boot_cpu_data.x86_stepping;/* feature available since SH-C0, exclude older revisions */ if ((model == 4 && stepping == 0) ||
drivers/video/fbdev/geode/video_gx.c +1 -1
@@ -127,7 +127,7 @@ void gx_set_dclk_frequency(struct fb_info *info)int timeout =1000 ;/* Rev. 1 Geode GXs use a 14 MHz reference clock instead of 48 MHz. */ -if (cpu_data (0 ).x86_mask ==1 ) { +if (cpu_data (0 ).x86_stepping ==1 ) { pll_table = gx_pll_table_14MHz; pll_table_len =ARRAY_SIZE (gx_pll_table_14MHz); }else {
Signature · 1 line
2.17.1
PATCH 3/5 Slow Randomizing Boosts DoS v4.4.219 backport 3
In reply to mark grossFrom: Mark Gross <[email protected]>
Subject: [PATCH 3/5] x86/cpu: Add 'table' argument to cpu_matches()
commit 93920f61c2ad7edb01e63323832585796af75fc9 upstream
To make cpu_matches() reusable for other matching tables, have it take a pointer to a x86_cpu_id table as an argument.
[ bp: Flip arguments order. ]
Signed-off-by Mark Gross <[email protected]>
Signed-off-by Borislav Petkov <[email protected]>
Signed-off-by Thomas Gleixner <[email protected]>
Reviewed-by Josh Poimboeuf <[email protected]>
--- arch/x86/kernel/cpu/common.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-)
arch/x86/kernel/cpu/common.c +13 -10
@@ -912,9 +912,9 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = { {} }; -static bool __init cpu_matches (unsigned long which) +static bool __init cpu_matches (const struct x86_cpu_id *table,unsigned long which) { -const struct x86_cpu_id *m =x86_match_cpu (cpu_vuln_whitelist); +const struct x86_cpu_id *m =x86_match_cpu (table);return m && !!(m->driver_data & which); }
@@ -934,29 +934,32 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)u64 ia32_cap =x86_read_arch_cap_msr ();/* Set ITLB_MULTIHIT bug if cpu is not in the whitelist and not mitigated */ -if (!cpu_matches (NO_ITLB_MULTIHIT ) && !(ia32_cap &ARCH_CAP_PSCHANGE_MC_NO )) +if (!cpu_matches (cpu_vuln_whitelist,NO_ITLB_MULTIHIT ) && + !(ia32_cap &ARCH_CAP_PSCHANGE_MC_NO ))setup_force_cpu_bug (X86_BUG_ITLB_MULTIHIT ); -if (cpu_matches (NO_SPECULATION )) +if (cpu_matches (cpu_vuln_whitelist,NO_SPECULATION ))return ;setup_force_cpu_bug (X86_BUG_SPECTRE_V1 );setup_force_cpu_bug (X86_BUG_SPECTRE_V2 ); -if (!cpu_matches (NO_SSB ) && !(ia32_cap &ARCH_CAP_SSB_NO ) && +if (!cpu_matches (cpu_vuln_whitelist,NO_SSB ) && + !(ia32_cap &ARCH_CAP_SSB_NO ) && !cpu_has (c,X86_FEATURE_AMD_SSB_NO ))setup_force_cpu_bug (X86_BUG_SPEC_STORE_BYPASS );if (ia32_cap &ARCH_CAP_IBRS_ALL )setup_force_cpu_cap (X86_FEATURE_IBRS_ENHANCED ); -if (!cpu_matches (NO_MDS ) && !(ia32_cap &ARCH_CAP_MDS_NO )) { +if (!cpu_matches (cpu_vuln_whitelist,NO_MDS ) && + !(ia32_cap &ARCH_CAP_MDS_NO )) {setup_force_cpu_bug (X86_BUG_MDS ); -if (cpu_matches (MSBDS_ONLY )) +if (cpu_matches (cpu_vuln_whitelist,MSBDS_ONLY ))setup_force_cpu_bug (X86_BUG_MSBDS_ONLY ); } -if (!cpu_matches (NO_SWAPGS )) +if (!cpu_matches (cpu_vuln_whitelist,NO_SWAPGS ))setup_force_cpu_bug (X86_BUG_SWAPGS );/*
@@ -974,7 +977,7 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))setup_force_cpu_bug (X86_BUG_TAA ); -if (cpu_matches (NO_MELTDOWN )) +if (cpu_matches (cpu_vuln_whitelist,NO_MELTDOWN ))return ;/* Rogue Data Cache Load? No! */
@@ -983,7 +986,7 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)setup_force_cpu_bug (X86_BUG_CPU_MELTDOWN ); -if (cpu_matches (NO_L1TF )) +if (cpu_matches (cpu_vuln_whitelist,NO_L1TF ))return ;setup_force_cpu_bug (X86_BUG_L1TF );
Signature · 1 line
2.17.1
PATCH 4/5 Slow Randomizing Boosts DoS v4.4.219 backport 4
In reply to mark grossFrom: Mark Gross <[email protected]>
Subject: [PATCH 4/5] x86/speculation: Add Special Register Buffer Data
Sampling (SRBDS) mitigation
commit 7e5b3c267d256822407a22fdce6afdf9cd13f9fb upstream
SRBDS is an MDS-like speculative side channel that can leak bits from the random number generator (RNG) across cores and threads. New microcode serializes the processor access during the execution of RDRAND and RDSEED. This ensures that the shared buffer is overwritten before it is released for reuse.
While it is present on all affected CPU models, the microcode mitigation is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the cases where TSX is not supported or has been disabled with TSX_CTRL.
The mitigation is activated by default on affected processors and it increases latency for RDRAND and RDSEED instructions. Among other effects this will reduce throughput from /dev/urandom.
* Enable administrator to configure the mitigation off when desired using either mitigations=off or srbds=off.
* Export vulnerability status via sysfs
* Rename file-scoped macros to apply for non-whitelist table initializations.
[ bp: Massage,
- s/VULNBL_INTEL_STEPPING/VULNBL_INTEL_STEPPINGS/g,
- do not read arch cap MSR a second time in tsx_fused_off() - just pass it in,
- flip check in cpu_set_bug_bits() to save an indentation level,
- reflow comments.
jpoimboe: s/Mitigated/Mitigation/ in user-visible strings
tglx: Dropped the fused off magic for now
]
Signed-off-by Mark Gross <[email protected]>
Signed-off-by Borislav Petkov <[email protected]>
Signed-off-by Thomas Gleixner <[email protected]>
Reviewed-by Tony Luck <[email protected]>
Reviewed-by Pawan Gupta <[email protected]>
Reviewed-by Josh Poimboeuf <[email protected]>
Tested-by Neelima Krishnan <[email protected]>
--- .../ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/kernel-parameters.txt | 20 ++++ arch/x86/include/asm/cpufeatures.h | 2 + arch/x86/include/asm/msr-index.h | 4 + arch/x86/kernel/cpu/bugs.c | 106 ++++++++++++++++++ arch/x86/kernel/cpu/common.c | 31 +++++ arch/x86/kernel/cpu/cpu.h | 1 + drivers/base/cpu.c | 8 ++ 8 files changed, 173 insertions(+)
Documentation/ABI/testing/sysfs-devices-system-cpu +1 -0
@@ -279,6 +279,7 @@ What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds + /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018
Documentation/kernel-parameters.txt +20 -0
@@ -3787,6 +3787,26 @@ bytes respectively. Such letter suffixes can also be entirely omitted. spia_pedr= spia_peddr= + srbds= [X86,INTEL] + Control the Special Register Buffer Data Sampling + (SRBDS) mitigation. + + Certain CPUs are vulnerable to an MDS-like + exploit which can leak bits from the random + number generator. + + By default, this issue is mitigated by + microcode. However, the microcode fix can cause + the RDRAND and RDSEED instructions to become + much slower. Among other effects, this will + result in reduced throughput from /dev/urandom. + + The microcode mitigation can be disabled with + the following option: + + off: Disable mitigation and remove + performance impact to RDRAND and RDSEED + stack_guard_gap= [MM] override the default stack gap protection. The value is in page units and it defines how many pages prior
arch/x86/include/asm/cpufeatures.h +2 -0
@@ -312,6 +312,7 @@/* Intel-defined CPU features, CPUID level 0x00000007:0 (EDX), word 18 */ #define X86_FEATURE_AVX512_4VNNIW (18*32+ 2)/* AVX-512 Neural Network Instructions */ #define X86_FEATURE_AVX512_4FMAPS (18*32+ 3)/* AVX-512 Multiply Accumulation Single precision */ +#define X86_FEATURE_SRBDS_CTRL (18*32+ 9)/* "" SRBDS mitigation MSR available */ #define X86_FEATURE_MD_CLEAR (18*32+10)/* VERW clears CPU buffers */ #define X86_FEATURE_SPEC_CTRL (18*32+26)/* "" Speculation Control (IBRS + IBPB) */ #define X86_FEATURE_INTEL_STIBP (18*32+27)/* "" Single Thread Indirect Branch Predictors */
@@ -343,5 +344,6 @@#define X86_BUG_SWAPGS X86_BUG(21)/* CPU is affected by speculation through SWAPGS */ #define X86_BUG_TAA X86_BUG(22)/* CPU is affected by TSX Async Abort(TAA) */ #define X86_BUG_ITLB_MULTIHIT X86_BUG(23)/* CPU may incur MCE during certain page attribute changes */ +#define X86_BUG_SRBDS X86_BUG(24)/* CPU may leak RNG bits if not mitigated */ #endif /* _ASM_X86_CPUFEATURES_H */
arch/x86/include/asm/msr-index.h +4 -0
@@ -91,6 +91,10 @@#define TSX_CTRL_RTM_DISABLE BIT(0)/* Disable RTM feature */ #define TSX_CTRL_CPUID_CLEAR BIT(1)/* Disable TSX enumeration */ +/* SRBDS support */ +#define MSR_IA32_MCU_OPT_CTRL 0x00000123 +#define RNGDS_MITG_DIS BIT(0) +#define MSR_IA32_SYSENTER_CS 0x00000174#define MSR_IA32_SYSENTER_ESP 0x00000175#define MSR_IA32_SYSENTER_EIP 0x00000176
arch/x86/kernel/cpu/bugs.c +106 -0
140 lines not on this page · raw message
arch/x86/kernel/cpu/common.c +31 -0
@@ -912,6 +912,27 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = { {} }; +#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 SRBDS BIT(0) + +static const struct x86_cpu_id cpu_vuln_blacklist[]__initconst = { +VULNBL_INTEL_STEPPINGS (IVYBRIDGE ,X86_STEPPING_ANY ,SRBDS ), +VULNBL_INTEL_STEPPINGS (HASWELL_CORE ,X86_STEPPING_ANY ,SRBDS ), +VULNBL_INTEL_STEPPINGS (HASWELL_ULT ,X86_STEPPING_ANY ,SRBDS ), +VULNBL_INTEL_STEPPINGS (HASWELL_GT3E ,X86_STEPPING_ANY ,SRBDS ), +VULNBL_INTEL_STEPPINGS (BROADWELL_GT3E ,X86_STEPPING_ANY ,SRBDS ), +VULNBL_INTEL_STEPPINGS (BROADWELL_CORE ,X86_STEPPING_ANY ,SRBDS ), +VULNBL_INTEL_STEPPINGS (SKYLAKE_MOBILE ,X86_STEPPING_ANY ,SRBDS ), +VULNBL_INTEL_STEPPINGS (SKYLAKE_DESKTOP ,X86_STEPPING_ANY ,SRBDS ), +VULNBL_INTEL_STEPPINGS (KABYLAKE_MOBILE ,X86_STEPPINGS (0x0 ,0xC ),SRBDS ), +VULNBL_INTEL_STEPPINGS (KABYLAKE_DESKTOP ,X86_STEPPINGS (0x0 ,0xD ),SRBDS ), + {} +}; +static bool __init cpu_matches (const struct x86_cpu_id *table,unsigned long which) {const struct x86_cpu_id *m =x86_match_cpu (table);
@@ -977,6 +998,15 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))setup_force_cpu_bug (X86_BUG_TAA ); +/* +* SRBDS affects CPUs which support RDRAND or RDSEED and are listed +* in the vulnerability blacklist. +*/ +if ((cpu_has (c,X86_FEATURE_RDRAND ) || +cpu_has (c,X86_FEATURE_RDSEED )) && +cpu_matches (cpu_vuln_blacklist,SRBDS )) +setup_force_cpu_bug (X86_BUG_SRBDS ); +if (cpu_matches (cpu_vuln_whitelist,NO_MELTDOWN ))return ;
@@ -1330,6 +1360,7 @@ void identify_secondary_cpu(struct cpuinfo_x86 *c)#endif mtrr_ap_init ();x86_spec_ctrl_setup_ap (); +update_srbds_msr (); }struct msr_range {
arch/x86/kernel/cpu/cpu.h +1 -0
@@ -64,6 +64,7 @@ extern void get_cpu_cap(struct cpuinfo_x86 *c);extern void cpu_detect_cache_sizes (struct cpuinfo_x86 *c);extern void x86_spec_ctrl_setup_ap (void ); +extern void update_srbds_msr (void );extern u64 x86_read_arch_cap_msr (void );
drivers/base/cpu.c +8 -0
@@ -549,6 +549,12 @@ ssize_t __weak cpu_show_itlb_multihit(struct device *dev,return sprintf (buf,"Not affected\n" ); } +ssize_t __weak cpu_show_srbds (struct device *dev, +struct device_attribute *attr,char *buf) +{ +return sprintf (buf,"Not affected\n" ); +} + static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL); static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL); static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
@@ -557,6 +563,7 @@ static DEVICE_ATTR(l1tf, 0444, cpu_show_l1tf, NULL); static DEVICE_ATTR(mds, 0444, cpu_show_mds, NULL); static DEVICE_ATTR(tsx_async_abort, 0444, cpu_show_tsx_async_abort, NULL); static DEVICE_ATTR(itlb_multihit, 0444, cpu_show_itlb_multihit, NULL); +static DEVICE_ATTR(srbds, 0444, cpu_show_srbds, NULL);static struct attribute *cpu_root_vulnerabilities_attrs[] = { &dev_attr_meltdown.attr,
@@ -567,6 +574,7 @@ static struct attribute *cpu_root_vulnerabilities_attrs[] = { &dev_attr_mds.attr, &dev_attr_tsx_async_abort.attr, &dev_attr_itlb_multihit.attr, + &dev_attr_srbds.attr, NULL };
Signature · 1 line
2.17.1
PATCH 5/5 Slow Randomizing Boosts DoS v4.4.219 backport 5
In reply to mark grossFrom: Mark Gross <[email protected]>
Subject: [PATCH 5/5] x86/speculation: Add SRBDS vulnerability and mitigation
documentation
commit 7222a1b5b87417f22265c92deea76a6aecd0fb0f upstream
Add documentation for the SRBDS vulnerability and its mitigation.
[ bp: Massage.
jpoimboe: sysfs table strings. ]
Signed-off-by Mark Gross <[email protected]>
Signed-off-by Borislav Petkov <[email protected]>
Reviewed-by Tony Luck <[email protected]>
Reviewed-by Josh Poimboeuf <[email protected]>
--- .../special-register-buffer-data-sampling.rst | 148 ++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 Documentation/hw-vuln/special-register-buffer-data-sampling.rst
Documentation/hw-vuln/special-register-buffer-data-sampling.rst new file +148 -0
@@ -0,0 +1,148 @@ +.. SPDX-License-Identifier: GPL-2.0 + +SRBDS - Special Register Buffer Data Sampling +============================================= + +SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +infer values returned from special register accesses. Special register +accesses are accesses to off core registers. According to Intel's evaluation, +the special register reads that have a security expectation of privacy are +RDRAND, RDSEED and SGX EGETKEY. + +When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved +to the core through the special register mechanism that is susceptible +to MDS attacks. + +Affected processors +-------------------- +Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may +be affected. + +A processor is affected by SRBDS if its Family_Model and stepping is +in the following list, with the exception of the listed processors +exporting MDS_NO while Intel TSX is available yet not enabled. The +latter class of processors are only affected when Intel TSX is enabled +by software using TSX_CTRL_MSR otherwise they are not affected. + + ============= ============ ======== + common name Family_Model Stepping + ============= ============ ======== + Haswell 06_3CH All + Haswell_L 06_45H All + Haswell_G 06_46H All + + Broadwell_G 06_47H All + Broadwell 06_3DH All + + Skylake_L 06_4EH All + Skylake 06_5EH All + + Kabylake_L 06_8EH <=0xC + + Kabylake 06_9EH <=0xD + ============= ============ ======== + +Related CVEs +------------ + +The following CVE entry is related to this SRBDS issue: + + ============== ===== ===================================== + CVE-2020-0543 SRBDS Special Register Buffer Data Sampling + ============== ===== ===================================== + +Attack scenarios +---------------- +An unprivileged user can extract values returned from RDRAND and RDSEED +executed on another core or sibling thread using MDS techniques. + + +Mitigation mechanism +------------------- +Intel will release microcode updates that modify the RDRAND, RDSEED, and +EGETKEY instructions to overwrite secret special register data in the shared +staging buffer before the secret data can be accessed by another logical +processor. + +During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core +accesses from other logical processors will be delayed until the special +register read is complete and the secret data in the shared staging buffer is +overwritten. + +This has three effects on performance: + +#. RDRAND, RDSEED, or EGETKEY instructions have higher latency. + +#. Executing RDRAND at the same time on multiple logical processors will be + serialized, resulting in an overall reduction in the maximum RDRAND + bandwidth. + +#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other + logical processors that miss their core caches, with an impact similar to + legacy locked cache-line-split accesses. + +The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable +the mitigation for RDRAND and RDSEED instructions executed outside of Intel +Software Guard Extensions (Intel SGX) enclaves. On logical processors that +disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not +take longer to execute and do not impact performance of sibling logical +processors memory accesses. The opt-out mechanism does not affect Intel SGX +enclaves (including execution of RDRAND or RDSEED inside an enclave, as well +as EGETKEY execution). + +IA32_MCU_OPT_CTRL MSR Definition +-------------------------------- +Along with the mitigation for this issue, Intel added a new thread-scope +IA32_MCU_OPT_CTRL MSR, (address 0x123). The presence of this MSR and +RNGDS_MITG_DIS (bit 0) is enumerated by CPUID.(EAX=07H,ECX=0).EDX[SRBDS_CTRL = +9]==1. This MSR is introduced through the microcode update. + +Setting IA32_MCU_OPT_CTRL[0] (RNGDS_MITG_DIS) to 1 for a logical processor +disables the mitigation for RDRAND and RDSEED executed outside of an Intel SGX +enclave on that logical processor. Opting out of the mitigation for a +particular logical processor does not affect the RDRAND and RDSEED mitigations +for other logical processors. + +Note that inside of an Intel SGX enclave, the mitigation is applied regardless +of the value of RNGDS_MITG_DS. + +Mitigation control on the kernel command line +--------------------------------------------- +The kernel command line allows control over the SRBDS mitigation at boot time +with the option "srbds=". The option for this is: + + ============= ============================================================= + off This option disables SRBDS mitigation for RDRAND and RDSEED on + affected platforms. + ============= ============================================================= + +SRBDS System Information +----------------------- +The Linux kernel provides vulnerability status information through sysfs. For +SRBDS this can be accessed by the following sysfs file: +/sys/devices/system/cpu/vulnerabilities/srbds + +The possible values contained in this file are: + + ============================== ============================================= + Not affected Processor not vulnerable + Vulnerable Processor vulnerable and mitigation disabled + Vulnerable: No microcode Processor vulnerable and microcode is missing + mitigation + Mitigation: Microcode Processor is vulnerable and mitigation is in + effect. + Mitigation: TSX disabled Processor is only vulnerable when TSX is + enabled while this system was booted with TSX + disabled. + Unknown: Dependent on + hypervisor status Running on virtual guest processor that is + affected but with no way to know if host + processor is mitigated or vulnerable. + ============================== ============================================= + +SRBDS Default mitigation +------------------------ +This new microcode serializes processor access during execution of RDRAND, +RDSEED ensures that the shared buffer is overwritten before it is released for +reuse. Use the "srbds=off" kernel command line to disable the mitigation for +RDRAND and RDSEED.
Signature · 1 line
2.17.1
Mark,
Quoted 9 lines · speck for mark gross
From: mark gross <[email protected]>
Subject: [PATCH 0/5] Slow Ranomizing Boosts DoS linux-4.4.y backportThis is a backport of the backports done by Thomas for linux-4.14.y to linux-4.4.y.
The backport needed a backport of one additional dependency for cpu_data-x86_mask getting renamed to
x86_stepping.
Quoted 6 lines
This was tested by the test engineer who tested the other SRBDS implementations and it seems to work.
Jia Zhang (1):
x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping
This one is missing and rightfully so. Maybe you get your mail setup for sending patches right some day in the future.
This one has in the mail headers:
In-Reply-To: <[email protected]>
References: <[email protected]>
From: Jia Zhang <[email protected]>
Date: Mon, 1 Jan 2018 09:52:10 +0800
While it's correct that the patch is from Jia and was written on Jan. 1 2018, neither the From: nor the Date: header in the mail are correct.
That's commit b399151cb48db30ad1e0e93dd40d68c6d007b637 upstream. Do we really want to backport that thing to 4.4 or just live with the uglies of x86_cpuinfo::x86_mask ?
TBH, I don't care, but the stable people might have opinions.
FYI, the Date: headers are generally odd when you send patches as they are not reflecting when the mail is sent. They reflect when the patch was written.
Thanks,
tglx
Quoted 27 lines · Thomas Gleixner
Quoted 9 lines · speck for mark gross
From: mark gross <[email protected]>
Subject: [PATCH 0/5] Slow Ranomizing Boosts DoS linux-4.4.y backportThis is a backport of the backports done by Thomas for linux-4.14.y to linux-4.4.y.
The backport needed a backport of one additional dependency for cpu_data-x86_mask getting renamed to
x86_stepping.Quoted 6 lines
This was tested by the test engineer who tested the other SRBDS implementations and it seems to work.
Jia Zhang (1):
x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_steppingThis one is missing and rightfully so. Maybe you get your mail setup for sending patches right some day in the future.
This one has in the mail headers:
In-Reply-To: <[email protected]>
References: <[email protected]>
From: Jia Zhang <[email protected]>
Date: Mon, 1 Jan 2018 09:52:10 +0800
Quoted 6 lines
While it's correct that the patch is from Jia and was written on Jan. 1 2018, neither the From: nor the Date: header in the mail are correct.
That's commit
b399151cb48db30ad1e0e93dd40d68c6d007b637upstream. Do we really want to backport that thing to 4.4 or just live with the uglies ofx86_cpuinfo::x86_mask?
Fished it out from the moderator mail, applied it to 4.4.y and then ran:
# git grep 'x86_mask' arch/x86/kernel/cpu/amd.c: if (c->x86_model <= 1 && c->x86_mask <= 1)
I clearly can see how that was tested.
Thanks,
tglx
Quoted 31 lines · speck for Thomas Gleixner
Quoted 30 lines · Thomas Gleixner
Quoted 9 lines · speck for mark gross
From: mark gross <[email protected]>
Subject: [PATCH 0/5] Slow Ranomizing Boosts DoS linux-4.4.y backportThis is a backport of the backports done by Thomas for linux-4.14.y to linux-4.4.y.
The backport needed a backport of one additional dependency for cpu_data-x86_mask getting renamed to
x86_stepping.Quoted 6 lines
This was tested by the test engineer who tested the other SRBDS implementations and it seems to work.
Jia Zhang (1):
x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_steppingThis one is missing and rightfully so. Maybe you get your mail setup for sending patches right some day in the future.
This one has in the mail headers:
In-Reply-To: <[email protected]>
References: <[email protected]>
From: Jia Zhang <[email protected]>
Date: Mon, 1 Jan 2018 09:52:10 +0800While it's correct that the patch is from Jia and was written on Jan. 1 2018, neither the From: nor the Date: header in the mail are correct.
Quoted 8 lines
Quoted 3 lines
That's commit
b399151cb48db30ad1e0e93dd40d68c6d007b637upstream. Do we really want to backport that thing to 4.4 or just live with the uglies ofx86_cpuinfo::x86_mask?Fished it out from the moderator mail, applied it to 4.4.y and then ran:
# git grep 'x86_mask' arch/x86/kernel/cpu/amd.c: if (c->x86_model <= 1 && c->x86_mask <= 1)
yeah, I caught that in my backport that failed to send for some reason. There were a few places needing fixups.
Quoted 1 line
I clearly can see how that was tested.
I didn't test your backport of course.
But, I did do a allyesconfig build that hit that and then I followed up with a similar git grep.
FWIW :
1915 git checkout srbs-linux-4.4.y
1916 git cherry-pick 06be007aa436a
Then I did a few fixups including the same git grep x86_mask and allyes and allmod builds.
--mark
Quoted 7 lines · Thomas Gleixner
Thomas Gleixner <[email protected]> writes:
Fished it out from the moderator mail, applied it to 4.4.y and then ran:# git grep 'x86_mask' arch/x86/kernel/cpu/amd.c: if (c->x86_model <= 1 && c->x86_mask <= 1)I clearly can see how that was tested.
Apologies. My bad.
Tired brain tricked me to believe that I had updated the 4.4 branch to 4.4.220. Awake brain noticed and after really updating the above is gone.
Thanks,
tglx
Quoted 7 lines · speck for Thomas Gleixner
Quoted 6 lines · Thomas Gleixner
Thomas Gleixner <[email protected]> writes:
Fished it out from the moderator mail, applied it to 4.4.y and then ran:# git grep 'x86_mask' arch/x86/kernel/cpu/amd.c: if (c->x86_model <= 1 && c->x86_mask <= 1)
Quoted 6 lines
Quoted 1 line
I clearly can see how that was tested.
Apologies. My bad.
Tired brain tricked me to believe that I had updated the 4.4 branch to 4.4.220. Awake brain noticed and after really updating the above is gone.
NP.
--mark
Quoted 1 line
Quoted 16 lines · speck for Thomas Gleixner
Mark,
Quoted 13 lines · speck for mark gross
From: mark gross <[email protected]>
Subject: [PATCH 0/5] Slow Ranomizing Boosts DoS linux-4.4.y backportThis is a backport of the backports done by Thomas for linux-4.14.y to linux-4.4.y.
The backport needed a backport of one additional dependency for cpu_data-x86_mask getting renamed to
x86_stepping.This was tested by the test engineer who tested the other SRBDS implementations and it seems to work.
Quoted 5 lines
Quoted 2 lines
Jia Zhang (1):
x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_steppingThis one is missing and rightfully so. Maybe you get your mail setup for sending patches right some day in the future.
Thats strange. FWIW I did the following:
1996 vim mail/0000-cover-letter.patch 1997 speckify-gitmail -s "Slow Randomizing Boosts DoS v4.4.219 backport" mail/ spec/ 1998 ls spec/ 1999 cd spec/ 2000 for b in `ls`; do sendmail -t -i -f [email protected] < $b; done 2001 history
see patch that failed to send below
Quoted 9 lines
This one has in the mail headers:
In-Reply-To: <[email protected]>
References: <[email protected]>
From: Jia Zhang <[email protected]>
Date: Mon, 1 Jan 2018 09:52:10 +0800While it's correct that the patch is from Jia and was written on Jan. 1 2018, neither the From: nor the Date: header in the mail are correct.
I cherry-picked it from the linux-4.9.y version.
Quoted 7 lines
That's commit
b399151cb48db30ad1e0e93dd40d68c6d007b637upstream. Do we really want to backport that thing to 4.4 or just live with the uglies ofx86_cpuinfo::x86_mask?TBH, I don't care, but the stable people might have opinions.
Quoted 8 lines
FYI, the Date: headers are generally odd when you send patches as they are not reflecting when the mail is sent. They reflect when the patch was written.
Thanks,
tglx
-------------------
From 4db1a97738fbbe14af9a8c746ebd11699f903f76 Mon Sep 17 00:00:00 2001
Message-Id: <4db1a97738fbbe14af9a8c746ebd11699f903f76.1588001639.git.mgross@linux.intel.com>
In-Reply-To: <[email protected]>
References: <[email protected]>
From: Jia Zhang <[email protected]>
Date: Mon, 1 Jan 2018 09:52:10 +0800
Subject: [PATCH 1/5] x86/cpu: Rename cpu_data.x86_mask to
cpu_data.x86_stepping
To: [email protected]
commit b399151cb48db30ad1e0e93dd40d68c6d007b637 upstream.
x86_mask is a confusing name which is hard to associate with the processor's stepping.
Additionally, correct an indent issue in lib/cpu.c.
Signed-off-by Jia Zhang <[email protected]>
[ Updated it to more recent kernels. ]
Cc Linus Torvalds <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Thomas Gleixner <[email protected]>
Signed-off-by Ingo Molnar <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
Conflicts:
arch/x86/events/intel/core.c arch/x86/events/intel/lbr.c arch/x86/events/intel/p6.c arch/x86/kernel/cpu/common.c arch/x86/kernel/cpu/intel.c arch/x86/kernel/cpu/microcode/intel.c arch/x86/kernel/mpparse.c arch/x86/lib/cpu.c drivers/cpufreq/acpi-cpufreq.c drivers/cpufreq/powernow-k7.c --- arch/x86/include/asm/acpi.h | 2 +- arch/x86/include/asm/processor.h | 2 +- arch/x86/kernel/amd_nb.c | 2 +- arch/x86/kernel/asm-offsets_32.c | 2 +- arch/x86/kernel/cpu/amd.c | 26 +++++++++++----------- arch/x86/kernel/cpu/centaur.c | 4 ++-- arch/x86/kernel/cpu/common.c | 8 +++---- arch/x86/kernel/cpu/cyrix.c | 2 +- arch/x86/kernel/cpu/intel.c | 20 ++++++++--------- arch/x86/kernel/cpu/microcode/intel.c | 4 ++-- arch/x86/kernel/cpu/mtrr/generic.c | 2 +- arch/x86/kernel/cpu/mtrr/main.c | 4 ++-- arch/x86/kernel/cpu/perf_event_intel.c | 2 +- arch/x86/kernel/cpu/perf_event_intel_lbr.c | 2 +- arch/x86/kernel/cpu/perf_event_p6.c | 2 +- arch/x86/kernel/cpu/proc.c | 4 ++-- arch/x86/kernel/head_32.S | 4 ++-- arch/x86/kernel/mpparse.c | 2 +- drivers/char/hw_random/via-rng.c | 2 +- drivers/cpufreq/acpi-cpufreq.c | 2 +- drivers/cpufreq/longhaul.c | 6 ++--- drivers/cpufreq/p4-clockmod.c | 2 +- drivers/cpufreq/powernow-k7.c | 2 +- drivers/cpufreq/speedstep-centrino.c | 4 ++-- drivers/cpufreq/speedstep-lib.c | 6 ++--- drivers/crypto/padlock-aes.c | 2 +- drivers/edac/amd64_edac.c | 2 +- drivers/edac/mce_amd.c | 2 +- drivers/hwmon/coretemp.c | 6 ++--- drivers/hwmon/hwmon-vid.c | 2 +- drivers/hwmon/k10temp.c | 2 +- drivers/hwmon/k8temp.c | 2 +- drivers/video/fbdev/geode/video_gx.c | 2 +- 33 files changed, 69 insertions(+), 69 deletions(-)
arch/x86/include/asm/acpi.h +1 -1
@@ -92,7 +92,7 @@ static inline unsigned int acpi_processor_cstate_check(unsigned int max_cstate)if (boot_cpu_data.x86 ==0x0F && boot_cpu_data.x86_vendor ==X86_VENDOR_AMD && boot_cpu_data.x86_model <=0x05 && - boot_cpu_data.x86_mask <0x0A ) + boot_cpu_data.x86_stepping <0x0A )return 1 ;else if (amd_e400_c1e_detected)return 1 ;
arch/x86/include/asm/processor.h +1 -1
@@ -88,7 +88,7 @@ struct cpuinfo_x86 {__u8 x86;/* CPU family */ __u8 x86_vendor;/* CPU vendor */ __u8 x86_model; -__u8 x86_mask; +__u8 x86_stepping;#ifdef CONFIG_X86_32 char wp_works_ok;/* It doesn't on 386's */
arch/x86/kernel/amd_nb.c +1 -1
@@ -105,7 +105,7 @@ int amd_cache_northbridges(void)if (boot_cpu_data.x86 ==0x10 && boot_cpu_data.x86_model >=0x8 && (boot_cpu_data.x86_model >0x9 || - boot_cpu_data.x86_mask >=0x1 )) + boot_cpu_data.x86_stepping >=0x1 )) amd_northbridges.flags |=AMD_NB_L3_INDEX_DISABLE ;if (boot_cpu_data.x86 ==0x15 )
arch/x86/kernel/asm-offsets_32.c +1 -1
@@ -20,7 +20,7 @@ void foo(void)OFFSET (CPUINFO_x86, cpuinfo_x86, x86);OFFSET (CPUINFO_x86_vendor, cpuinfo_x86, x86_vendor);OFFSET (CPUINFO_x86_model, cpuinfo_x86, x86_model); -OFFSET (CPUINFO_x86_mask, cpuinfo_x86, x86_mask); +OFFSET (CPUINFO_x86_stepping, cpuinfo_x86, x86_stepping);OFFSET (CPUINFO_cpuid_level, cpuinfo_x86, cpuid_level);OFFSET (CPUINFO_x86_capability, cpuinfo_x86, x86_capability);OFFSET (CPUINFO_x86_vendor_id, cpuinfo_x86, x86_vendor_id);
arch/x86/kernel/cpu/amd.c +13 -13
@@ -112,7 +112,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)return ; } -if (c->x86_model ==6 && c->x86_mask ==1 ) { +if (c->x86_model ==6 && c->x86_stepping ==1 ) {const int K6_BUG_LOOP =1000000 ;int n;void (*f_vide)(void );
@@ -142,7 +142,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)/* K6 with old style WHCR */ if (c->x86_model <8 || - (c->x86_model ==8 && c->x86_mask <8 )) { + (c->x86_model ==8 && c->x86_stepping <8 )) {/* We can only write allocate on the low 508Mb */ if (mbytes >508 ) mbytes =508 ;
@@ -161,7 +161,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)return ; } -if ((c->x86_model ==8 && c->x86_mask >7 ) || +if ((c->x86_model ==8 && c->x86_stepping >7 ) || c->x86_model ==9 || c->x86_model ==13 ) {/* The more serious chips .. */
@@ -214,7 +214,7 @@ static void init_amd_k7(struct cpuinfo_x86 *c)* are more robust with CLK_CTL set to 200xxxxx instead of 600xxxxx * As per AMD technical note 27212 0.2 */ -if ((c->x86_model ==8 && c->x86_mask >=1 ) || (c->x86_model >8 )) { +if ((c->x86_model ==8 && c->x86_stepping >=1 ) || (c->x86_model >8 )) {rdmsr (MSR_K7_CLK_CTL , l, h);if ((l &0xfff00000 ) !=0x20000000 ) { printk(KERN_INFO
@@ -235,12 +235,12 @@ static void init_amd_k7(struct cpuinfo_x86 *c)* but they are not certified as MP capable. */ /* Athlon 660/661 is valid. */ -if ((c->x86_model ==6 ) && ((c->x86_mask ==0 ) || - (c->x86_mask ==1 ))) +if ((c->x86_model ==6 ) && ((c->x86_stepping ==0 ) || + (c->x86_stepping ==1 )))return ;/* Duron 670 is valid */ -if ((c->x86_model ==7 ) && (c->x86_mask ==0 )) +if ((c->x86_model ==7 ) && (c->x86_stepping ==0 ))return ;/*
@@ -250,8 +250,8 @@ static void init_amd_k7(struct cpuinfo_x86 *c)* See http://www.heise.de/newsticker/data/jow-18.10.01-000 for * more. */ -if (((c->x86_model ==6 ) && (c->x86_mask >=2 )) || - ((c->x86_model ==7 ) && (c->x86_mask >=1 )) || +if (((c->x86_model ==6 ) && (c->x86_stepping >=2 )) || + ((c->x86_model ==7 ) && (c->x86_stepping >=1 )) || (c->x86_model >7 ))if (cpu_has (c,X86_FEATURE_MP ))return ;
@@ -563,7 +563,7 @@ static void early_init_amd(struct cpuinfo_x86 *c)/* Set MTRR capability flag if appropriate */ if (c->x86 ==5 )if (c->x86_model ==13 || c->x86_model ==9 || - (c->x86_model ==8 && c->x86_mask >=8 )) + (c->x86_model ==8 && c->x86_stepping >=8 ))set_cpu_cap (c,X86_FEATURE_K6_MTRR );#endif #if defined(CONFIG_X86_LOCAL_APIC ) && defined(CONFIG_PCI )
@@ -902,11 +902,11 @@ static unsigned int amd_size_cache(struct cpuinfo_x86 *c, unsigned int size)/* AMD errata T13 (order #21922) */ if ((c->x86 ==6 )) {/* Duron Rev A0 */ -if (c->x86_model ==3 && c->x86_mask ==0 ) +if (c->x86_model ==3 && c->x86_stepping ==0 ) size =64 ;/* Tbird rev A1/A2 */ if (c->x86_model ==4 && - (c->x86_mask ==0 || c->x86_mask ==1 )) + (c->x86_stepping ==0 || c->x86_stepping ==1 )) size =256 ; }return size;
@@ -1043,7 +1043,7 @@ static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum) }/* OSVW unavailable or ID unknown, match family-model-stepping range */ - ms = (cpu->x86_model <<4 ) | cpu->x86_mask; + ms = (cpu->x86_model <<4 ) | cpu->x86_stepping;while ((range = *erratum++)) if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range)) && (ms >= AMD_MODEL_RANGE_START(range)) &&
arch/x86/kernel/cpu/centaur.c +2 -2
@@ -134,7 +134,7 @@ static void init_centaur(struct cpuinfo_x86 *c)clear_cpu_cap (c,X86_FEATURE_TSC );break ;case 8 : -switch (c->x86_mask) { +switch (c->x86_stepping) {default : name ="2" ;break ;
@@ -209,7 +209,7 @@ centaur_size_cache(struct cpuinfo_x86 *c, unsigned int size)* - Note, it seems this may only be in engineering samples. */ if ((c->x86 ==6 ) && (c->x86_model ==9 ) && - (c->x86_mask ==1 ) && (size ==65 )) + (c->x86_stepping ==1 ) && (size ==65 )) size -=1 ;return size; }
arch/x86/kernel/cpu/common.c +4 -4
@@ -652,7 +652,7 @@ void cpu_detect(struct cpuinfo_x86 *c)cpuid (0x00000001 , &tfms, &misc, &junk, &cap0); c->x86 = (tfms >>8 ) &0xf ; c->x86_model = (tfms >>4 ) &0xf ; - c->x86_mask = tfms &0xf ; + c->x86_stepping = tfms &0xf ;if (c->x86 ==0xf ) c->x86 += (tfms >>20 ) &0xff ;
@@ -1157,7 +1157,7 @@ static void identify_cpu(struct cpuinfo_x86 *c) c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size =0 ; c->x86_vendor =X86_VENDOR_UNKNOWN ; - c->x86_model = c->x86_mask =0 ;/* So far unknown... */ + c->x86_model = c->x86_stepping =0 ;/* So far unknown... */ c->x86_vendor_id[0 ] ='\0' ;/* Unset */ c->x86_model_id[0 ] ='\0' ;/* Unset */ c->x86_max_cores =1 ;
@@ -1403,8 +1403,8 @@ void print_cpu_info(struct cpuinfo_x86 *c)printk (KERN_CONT " (family: 0x%x, model: 0x%x" , c->x86, c->x86_model); -if (c->x86_mask || c->cpuid_level >=0 ) -printk (KERN_CONT ", stepping: 0x%x)\n" , c->x86_mask); +if (c->x86_stepping || c->cpuid_level >=0 ) +pr_cont (", stepping: 0x%x)\n" , c->x86_stepping);else printk (KERN_CONT ")\n" );
arch/x86/kernel/cpu/cyrix.c +1 -1
@@ -212,7 +212,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)/* common case step number/rev -- exceptions handled below */ c->x86_model = (dir1 >>4 ) +1 ; - c->x86_mask = dir1 &0xf ; + c->x86_stepping = dir1 &0xf ;/* Now cook; the original recipe is by Channing Corn, from Cyrix. * We do the same thing for each generation: we work out
arch/x86/kernel/cpu/intel.c +10 -10
@@ -80,7 +80,7 @@ static bool bad_spectre_microcode(struct cpuinfo_x86 *c)for (i =0 ; i <ARRAY_SIZE (spectre_bad_microcodes); i++) {if (c->x86_model == spectre_bad_microcodes[i].model && - c->x86_mask == spectre_bad_microcodes[i].stepping) + c->x86_stepping == spectre_bad_microcodes[i].stepping)return (c->microcode <= spectre_bad_microcodes[i].microcode); }return false;
@@ -130,7 +130,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)* need the microcode to have already been loaded... so if it is * not, recommend a BIOS update and disable large pages. */ -if (c->x86 ==6 && c->x86_model ==0x1c && c->x86_mask <=2 && +if (c->x86 ==6 && c->x86_model ==0x1c && c->x86_stepping <=2 && c->microcode <0x20e ) {printk (KERN_WARNING "Atom PSE erratum detected, BIOS microcode update recommended\n" );clear_cpu_cap (c,X86_FEATURE_PSE );
@@ -146,7 +146,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)/* CPUID workaround for 0F33/0F34 CPU */ if (c->x86 ==0xF && c->x86_model ==0x3 - && (c->x86_mask ==0x3 || c->x86_mask ==0x4 )) + && (c->x86_stepping ==0x3 || c->x86_stepping ==0x4 )) c->x86_phys_bits =36 ;/*
@@ -246,8 +246,8 @@ int ppro_with_ram_bug(void)if (boot_cpu_data.x86_vendor ==X86_VENDOR_INTEL && boot_cpu_data.x86 ==6 && boot_cpu_data.x86_model ==1 && - boot_cpu_data.x86_mask <8 ) { -printk (KERN_INFO "Pentium Pro with Errata#50 detected. Taking evasive action.\n" ); + boot_cpu_data.x86_stepping <8 ) { +pr_info ("Pentium Pro with Errata#50 detected. Taking evasive action.\n" );return 1 ; }return 0 ;
@@ -263,7 +263,7 @@ static void intel_smp_check(struct cpuinfo_x86 *c)* Mask B, Pentium, but not Pentium MMX */ if (c->x86 ==5 && - c->x86_mask >=1 && c->x86_mask <=4 && + c->x86_stepping >=1 && c->x86_stepping <=4 && c->x86_model <=3 ) {/* * Remember we have B step Pentia with bugs
@@ -306,7 +306,7 @@ static void intel_workarounds(struct cpuinfo_x86 *c)* SEP CPUID bug: Pentium Pro reports SEP but doesn't have it until * model 3 mask 3 */ -if ((c->x86<<8 | c->x86_model<<4 | c->x86_mask) <0x633 ) +if ((c->x86<<8 | c->x86_model<<4 | c->x86_stepping) <0x633 )clear_cpu_cap (c,X86_FEATURE_SEP );/*
@@ -324,7 +324,7 @@ static void intel_workarounds(struct cpuinfo_x86 *c)* P4 Xeon errata 037 workaround. * Hardware prefetcher may cause stale data to be loaded into the cache. */ -if ((c->x86 ==15 ) && (c->x86_model ==1 ) && (c->x86_mask ==1 )) { +if ((c->x86 ==15 ) && (c->x86_model ==1 ) && (c->x86_stepping ==1 )) {if (msr_set_bit (MSR_IA32_MISC_ENABLE ,MSR_IA32_MISC_ENABLE_PREFETCH_DISABLE_BIT ) >0 ) {
@@ -340,7 +340,7 @@ static void intel_workarounds(struct cpuinfo_x86 *c)* Specification Update"). */ if (cpu_has_apic && (c->x86<<8 | c->x86_model<<4 ) ==0x520 && - (c->x86_mask <0x6 || c->x86_mask ==0xb )) + (c->x86_stepping <0x6 || c->x86_stepping ==0xb ))set_cpu_bug (c,X86_BUG_11AP );
@@ -555,7 +555,7 @@ static void init_intel(struct cpuinfo_x86 *c)case 6 :if (l2 ==128 ) p ="Celeron (Mendocino)" ; -else if (c->x86_mask ==0 || c->x86_mask ==5 ) +else if (c->x86_stepping ==0 || c->x86_stepping ==5 ) p ="Celeron-A" ;break ;
arch/x86/kernel/cpu/microcode/intel.c +2 -2
@@ -1013,7 +1013,7 @@ static bool is_blacklisted(unsigned int cpu)*/ if (c->x86 ==6 && c->x86_model ==79 && - c->x86_mask ==0x01 && + c->x86_stepping ==0x01 && llc_size_per_core >2621440 && c->microcode <0x0b000021 ) {pr_err_once ("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n" , c->microcode);
@@ -1036,7 +1036,7 @@ static enum ucode_state request_microcode_fw(int cpu, struct device *device,return UCODE_NFOUND ;sprintf (name,"intel-ucode/%02x-%02x-%02x" , - c->x86, c->x86_model, c->x86_mask); + c->x86, c->x86_model, c->x86_stepping);if (request_firmware_direct (&firmware, name, device)) {pr_debug ("data file %s load failed\n" , name);
arch/x86/kernel/cpu/mtrr/generic.c +1 -1
@@ -860,7 +860,7 @@ int generic_validate_add_page(unsigned long base, unsigned long size,*/ if (is_cpu (INTEL ) && boot_cpu_data.x86 ==6 && boot_cpu_data.x86_model ==1 && - boot_cpu_data.x86_mask <=7 ) { + boot_cpu_data.x86_stepping <=7 ) {if (base & ((1 << (22 -PAGE_SHIFT )) -1 )) {pr_warning ("mtrr: base(0x%lx000) is not 4 MiB aligned\n" , base);return -EINVAL ;
arch/x86/kernel/cpu/mtrr/main.c +2 -2
@@ -699,8 +699,8 @@ void __init mtrr_bp_init(void)if (boot_cpu_data.x86_vendor ==X86_VENDOR_INTEL && boot_cpu_data.x86 ==0xF && boot_cpu_data.x86_model ==0x3 && - (boot_cpu_data.x86_mask ==0x3 || - boot_cpu_data.x86_mask ==0x4 )) + (boot_cpu_data.x86_stepping ==0x3 || + boot_cpu_data.x86_stepping ==0x4 )) phys_addr =36 ; size_or_mask =SIZE_OR_MASK_BITS (phys_addr);
arch/x86/kernel/cpu/perf_event_intel.c +1 -1
@@ -3051,7 +3051,7 @@ static int intel_snb_pebs_broken(int cpu)break ;case 45 :/* SNB-EP */ -switch (cpu_data (cpu).x86_mask) { +switch (cpu_data (cpu).x86_stepping) {case 6 : rev =0x618 ;break ;case 7 : rev =0x70c ;break ; }
arch/x86/kernel/cpu/perf_event_intel_lbr.c +1 -1
@@ -1017,7 +1017,7 @@ void __init intel_pmu_lbr_init_atom(void)* on PMU interrupt */ if (boot_cpu_data.x86_model ==28 - && boot_cpu_data.x86_mask <10 ) { + && boot_cpu_data.x86_stepping <10 ) {pr_cont ("LBR disabled due to erratum" );return ; }
arch/x86/kernel/cpu/perf_event_p6.c +1 -1
@@ -233,7 +233,7 @@ static __initconst const struct x86_pmu p6_pmu = {static __init void p6_pmu_rdpmc_quirk (void ) { -if (boot_cpu_data.x86_mask <9 ) { +if (boot_cpu_data.x86_stepping <9 ) {/* * PPro erratum 26; fixed in stepping 9 and above. */
arch/x86/kernel/cpu/proc.c +2 -2
@@ -70,8 +70,8 @@ static int show_cpuinfo(struct seq_file *m, void *v) c->x86_model, c->x86_model_id[0] ? c->x86_model_id : "unknown"); -if (c->x86_mask || c->cpuid_level >=0 ) -seq_printf (m,"stepping\t: %d\n" , c->x86_mask); +if (c->x86_stepping || c->cpuid_level >=0 ) +seq_printf (m,"stepping\t: %d\n" , c->x86_stepping);else seq_puts (m,"stepping\t: unknown\n" );if (c->microcode)
arch/x86/kernel/head_32.S +2 -2
@@ -34,7 +34,7 @@ #define X86 new_cpu_data+CPUINFO_x86 #define X86_VENDOR new_cpu_data+CPUINFO_x86_vendor #define X86_MODEL new_cpu_data+CPUINFO_x86_model -#define X86_MASK new_cpu_data+CPUINFO_x86_mask +#define X86_STEPPING new_cpu_data+CPUINFO_x86_stepping #define X86_HARD_MATH new_cpu_data+CPUINFO_hard_math #define X86_CPUID new_cpu_data+CPUINFO_cpuid_level #define X86_CAPABILITY new_cpu_data+CPUINFO_x86_capability
@@ -440,7 +440,7 @@ enable_paging: shrb $4,%al movb %al,X86_MODEL andb $0x0f,%cl # mask mask revision - movb %cl,X86_MASK + movb %cl,X86_STEPPING movl %edx,X86_CAPABILITY is486:
arch/x86/kernel/mpparse.c +1 -1
@@ -407,7 +407,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type) processor.apicver = mpc_default_type >4 ?0x10 :0x01 ; processor.cpuflag =CPU_ENABLED ; processor.cpufeature = (boot_cpu_data.x86 <<8 ) | - (boot_cpu_data.x86_model <<4 ) | boot_cpu_data.x86_mask; + (boot_cpu_data.x86_model <<4 ) | boot_cpu_data.x86_stepping; processor.featureflag = boot_cpu_data.x86_capability[0 ]; processor.reserved[0 ] =0 ; processor.reserved[1 ] =0 ;
drivers/char/hw_random/via-rng.c +1 -1
@@ -166,7 +166,7 @@ static int via_rng_init(struct hwrng *rng)/* Enable secondary noise source on CPUs where it is present. */ /* Nehemiah stepping 8 and higher */ -if ((c->x86_model ==9 ) && (c->x86_mask >7 )) +if ((c->x86_model ==9 ) && (c->x86_stepping >7 )) lo |=VIA_NOISESRC2 ;/* Esther */
drivers/cpufreq/acpi-cpufreq.c +1 -1
@@ -639,7 +639,7 @@ static int acpi_cpufreq_blacklist(struct cpuinfo_x86 *c)if (c->x86_vendor ==X86_VENDOR_INTEL ) {if ((c->x86 ==15 ) && (c->x86_model ==6 ) && - (c->x86_mask ==8 )) { + (c->x86_stepping ==8 )) {printk (KERN_INFO "acpi-cpufreq: Intel(R) " "Xeon(R) 7100 Errata AL30, processors may " "lock up on frequency changes: disabling "
drivers/cpufreq/longhaul.c +3 -3
@@ -786,7 +786,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy)break ;case 7 : -switch (c->x86_mask) { +switch (c->x86_stepping) {case 0 : longhaul_version =TYPE_LONGHAUL_V1 ; cpu_model =CPU_SAMUEL2 ;
@@ -798,7 +798,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy)break ; case 1 ... 15: longhaul_version =TYPE_LONGHAUL_V2 ; -if (c->x86_mask <8 ) { +if (c->x86_stepping <8 ) { cpu_model =CPU_SAMUEL2 ; cpuname ="C3 'Samuel 2' [C5B]" ; }else {
@@ -825,7 +825,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy) numscales =32 ;memcpy (mults, nehemiah_mults,sizeof (nehemiah_mults));memcpy (eblcr, nehemiah_eblcr,sizeof (nehemiah_eblcr)); -switch (c->x86_mask) { +switch (c->x86_stepping) { case 0 ... 1: cpu_model =CPU_NEHEMIAH ; cpuname ="C3 'Nehemiah A' [C5XLOE]" ;
drivers/cpufreq/p4-clockmod.c +1 -1
@@ -176,7 +176,7 @@ static int cpufreq_p4_cpu_init(struct cpufreq_policy *policy)#endif /* Errata workaround */ - cpuid = (c->x86 <<8 ) | (c->x86_model <<4 ) | c->x86_mask; + cpuid = (c->x86 <<8 ) | (c->x86_model <<4 ) | c->x86_stepping;switch (cpuid) {case 0x0f07 :case 0x0f0a :
drivers/cpufreq/powernow-k7.c +1 -1
@@ -132,7 +132,7 @@ static int check_powernow(void)return 0 ; } -if ((c->x86_model ==6 ) && (c->x86_mask ==0 )) { +if ((c->x86_model ==6 ) && (c->x86_stepping ==0 )) { printk(KERN_INFO PFX "K7 660[A0] core detected, " "enabling errata workarounds\n"); have_a0 =1 ;
drivers/cpufreq/speedstep-centrino.c +2 -2
@@ -36,7 +36,7 @@ struct cpu_id {__u8 x86;/* CPU family */ __u8 x86_model;/* model */ -__u8 x86_mask;/* stepping */ +__u8 x86_stepping;/* stepping */ };enum {
@@ -276,7 +276,7 @@ static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, {if ((c->x86 == x->x86) && (c->x86_model == x->x86_model) && - (c->x86_mask == x->x86_mask)) + (c->x86_stepping == x->x86_stepping))return 1 ;return 0 ; }
drivers/cpufreq/speedstep-lib.c +3 -3
@@ -270,9 +270,9 @@ unsigned int speedstep_detect_processor(void) ebx =cpuid_ebx (0x00000001 ); ebx &=0x000000FF ; -pr_debug ("ebx value is %x, x86_mask is %x\n" , ebx, c->x86_mask); +pr_debug ("ebx value is %x, x86_stepping is %x\n" , ebx, c->x86_stepping); -switch (c->x86_mask) { +switch (c->x86_stepping) {case 4 :/* * B-stepping [M-P4-M]
@@ -359,7 +359,7 @@ unsigned int speedstep_detect_processor(void) msr_lo, msr_hi);if ((msr_hi & (1 <<18 )) && (relaxed_check ?1 : (msr_hi & (3 <<24 )))) { -if (c->x86_mask ==0x01 ) { +if (c->x86_stepping ==0x01 ) {pr_debug ("early PIII version\n" );return SPEEDSTEP_CPU_PIII_C_EARLY ; }else
drivers/crypto/padlock-aes.c +1 -1
@@ -535,7 +535,7 @@ static int __init padlock_init(void) printk(KERN_NOTICE PFX "Using VIA PadLock ACE for AES algorithm.\n"); -if (c->x86 ==6 && c->x86_model ==15 && c->x86_mask ==2 ) { +if (c->x86 ==6 && c->x86_model ==15 && c->x86_stepping ==2 ) { ecb_fetch_blocks =MAX_ECB_FETCH_BLOCKS ; cbc_fetch_blocks =MAX_CBC_FETCH_BLOCKS ; printk(KERN_NOTICE PFX "VIA Nano stepping 2 detected: enabling workaround.\n");
drivers/edac/amd64_edac.c +1 -1
@@ -2715,7 +2715,7 @@ static struct amd64_family_type *per_family_init(struct amd64_pvt *pvt)struct amd64_family_type *fam_type =NULL ; pvt->ext_model = boot_cpu_data.x86_model >>4 ; - pvt->stepping = boot_cpu_data.x86_mask; + pvt->stepping = boot_cpu_data.x86_stepping; pvt->model = boot_cpu_data.x86_model; pvt->fam = boot_cpu_data.x86;
drivers/edac/mce_amd.c +1 -1
@@ -760,7 +760,7 @@ int amd_decode_mce(struct notifier_block *nb, unsigned long val, void *data) pr_emerg(HW_ERR "CPU:%d (%x:%x:%x) MC%d_STATUS[%s|%s|%s|%s|%s", m->extcpu, - c->x86, c->x86_model, c->x86_mask, + c->x86, c->x86_model, c->x86_stepping, m->bank, ((m->status & MCI_STATUS_OVER) ? "Over" : "-"), ((m->status & MCI_STATUS_UC) ? "UE" :
drivers/hwmon/coretemp.c +3 -3
@@ -269,13 +269,13 @@ static int adjust_tjmax(struct cpuinfo_x86 *c, u32 id, struct device *dev)for (i =0 ; i <ARRAY_SIZE (tjmax_model_table); i++) {const struct tjmax_model *tm = &tjmax_model_table[i];if (c->x86_model == tm->model && - (tm->mask ==ANY || c->x86_mask == tm->mask)) + (tm->mask ==ANY || c->x86_stepping == tm->mask))return tm->tjmax; }/* Early chips have no MSR for TjMax */ -if (c->x86_model ==0xf && c->x86_mask <4 ) +if (c->x86_model ==0xf && c->x86_stepping <4 ) usemsr_ee =0 ;if (c->x86_model >0xe && usemsr_ee) {
@@ -426,7 +426,7 @@ static int chk_ucode_version(unsigned int cpu)* Readings might stop update when processor visited too deep sleep, * fixed for stepping D0 (6EC). */ -if (c->x86_model ==0xe && c->x86_mask <0xc && c->microcode <0x39 ) { +if (c->x86_model ==0xe && c->x86_stepping <0xc && c->microcode <0x39 ) {pr_err ("Errata AE18 not fixed, update BIOS or microcode of the CPU!\n" );return -ENODEV ; }
drivers/hwmon/hwmon-vid.c +1 -1
@@ -293,7 +293,7 @@ u8 vid_which_vrm(void)if (c->x86 <6 )/* Any CPU with family lower than 6 */ return 0 ;/* doesn't have VID */ - vrm_ret =find_vrm (c->x86, c->x86_model, c->x86_mask, c->x86_vendor); + vrm_ret =find_vrm (c->x86, c->x86_model, c->x86_stepping, c->x86_vendor);if (vrm_ret ==134 ) vrm_ret =get_via_model_d_vrm ();if (vrm_ret ==0 )
drivers/hwmon/k10temp.c +1 -1
@@ -179,7 +179,7 @@ static bool has_erratum_319(struct pci_dev *pdev)* and AM3 formats, but that's the best we can do. */ return boot_cpu_data.x86_model <4 || - (boot_cpu_data.x86_model ==4 && boot_cpu_data.x86_mask <=2 ); + (boot_cpu_data.x86_model ==4 && boot_cpu_data.x86_stepping <=2 ); } static int k10temp_probe(struct pci_dev *pdev,
drivers/hwmon/k8temp.c +1 -1
@@ -187,7 +187,7 @@ static int k8temp_probe(struct pci_dev *pdev,return -ENOMEM ; model = boot_cpu_data.x86_model; - stepping = boot_cpu_data.x86_mask; + stepping = boot_cpu_data.x86_stepping;/* feature available since SH-C0, exclude older revisions */ if ((model == 4 && stepping == 0) ||
drivers/video/fbdev/geode/video_gx.c +1 -1
@@ -127,7 +127,7 @@ void gx_set_dclk_frequency(struct fb_info *info)int timeout =1000 ;/* Rev. 1 Geode GXs use a 14 MHz reference clock instead of 48 MHz. */ -if (cpu_data (0 ).x86_mask ==1 ) { +if (cpu_data (0 ).x86_stepping ==1 ) { pll_table = gx_pll_table_14MHz; pll_table_len =ARRAY_SIZE (gx_pll_table_14MHz); }else {
Signature · 1 line
2.17.1
Greg KH
maintainerQuoted 91 lines · speck for mark gross
Quoted 16 lines · speck for Thomas Gleixner
Mark,
Quoted 13 lines · speck for mark gross
From: mark gross <[email protected]>
Subject: [PATCH 0/5] Slow Ranomizing Boosts DoS linux-4.4.y backportThis is a backport of the backports done by Thomas for linux-4.14.y to linux-4.4.y.
The backport needed a backport of one additional dependency for cpu_data-x86_mask getting renamed to
x86_stepping.This was tested by the test engineer who tested the other SRBDS implementations and it seems to work.
Quoted 5 lines
Quoted 2 lines
Jia Zhang (1):
x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_steppingThis one is missing and rightfully so. Maybe you get your mail setup for sending patches right some day in the future.
Thats strange. FWIW I did the following:
1996 vim mail/0000-cover-letter.patch 1997 speckify-gitmail -s "Slow Randomizing Boosts DoS v4.4.219 backport" mail/ spec/ 1998 ls spec/ 1999 cd spec/ 2000 for b in `ls`; do sendmail -t -i -f [email protected] < $b; done 2001 historysee patch that failed to send below
Quoted 9 lines
This one has in the mail headers:
In-Reply-To: <[email protected]>
References: <[email protected]>
From: Jia Zhang <[email protected]>
Date: Mon, 1 Jan 2018 09:52:10 +0800While it's correct that the patch is from Jia and was written on Jan. 1 2018, neither the From: nor the Date: header in the mail are correct.
I cherry-picked it from the linux-4.9.y version.
Quoted 7 lines
That's commit
b399151cb48db30ad1e0e93dd40d68c6d007b637upstream. Do we really want to backport that thing to 4.4 or just live with the uglies ofx86_cpuinfo::x86_mask?TBH, I don't care, but the stable people might have opinions.
Quoted 8 lines
FYI, the Date: headers are generally odd when you send patches as they are not reflecting when the mail is sent. They reflect when the patch was written.
Thanks,
tglx
-------------------
From
4db1a97738fbbe14af9a8c746ebd11699f903f76Mon Sep 17 00:00:00 2001
Message-Id: <4db1a97738fbbe14af9a8c746ebd11699f903f76.1588001639.git.mgross@linux.intel.com>
In-Reply-To: <[email protected]>
References: <[email protected]>
From: Jia Zhang <[email protected]>
Date: Mon, 1 Jan 2018 09:52:10 +0800
Subject: [PATCH 1/5] x86/cpu: Rename cpu_data.x86_mask to
cpu_data.x86_stepping
To: [email protected]commit
b399151cb48db30ad1e0e93dd40d68c6d007b637upstream.
x86_maskis a confusing name which is hard to associate with the processor's stepping.Additionally, correct an indent issue in
lib/cpu.c.Signed-off-by Jia Zhang <[email protected]>[ Updated it to more recent kernels. ]Cc Linus Torvalds <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Thomas Gleixner <[email protected]>Signed-off-by Ingo Molnar <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Conflicts:
Quoted 10 lines
arch/x86/events/intel/core.c arch/x86/events/intel/lbr.c arch/x86/events/intel/p6.c arch/x86/kernel/cpu/common.c arch/x86/kernel/cpu/intel.c arch/x86/kernel/cpu/microcode/intel.c arch/x86/kernel/mpparse.c arch/x86/lib/cpu.c drivers/cpufreq/acpi-cpufreq.c drivers/cpufreq/powernow-k7.c
What's that here for?
Can you resend this series in a format I can use?
thanks,
greg k-h
Quoted 103 lines · speck for Greg KH
Quoted 91 lines · speck for mark gross
Quoted 16 lines · speck for Thomas Gleixner
Mark,
Quoted 13 lines · speck for mark gross
From: mark gross <[email protected]>
Subject: [PATCH 0/5] Slow Ranomizing Boosts DoS linux-4.4.y backportThis is a backport of the backports done by Thomas for linux-4.14.y to linux-4.4.y.
The backport needed a backport of one additional dependency for cpu_data-x86_mask getting renamed to
x86_stepping.This was tested by the test engineer who tested the other SRBDS implementations and it seems to work.
Quoted 5 lines
Quoted 2 lines
Jia Zhang (1):
x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_steppingThis one is missing and rightfully so. Maybe you get your mail setup for sending patches right some day in the future.
Thats strange. FWIW I did the following:
1996 vim mail/0000-cover-letter.patch 1997 speckify-gitmail -s "Slow Randomizing Boosts DoS v4.4.219 backport" mail/ spec/ 1998 ls spec/ 1999 cd spec/ 2000 for b in `ls`; do sendmail -t -i -f [email protected] < $b; done 2001 historysee patch that failed to send below
Quoted 9 lines
This one has in the mail headers:
In-Reply-To: <[email protected]>
References: <[email protected]>
From: Jia Zhang <[email protected]>
Date: Mon, 1 Jan 2018 09:52:10 +0800While it's correct that the patch is from Jia and was written on Jan. 1 2018, neither the From: nor the Date: header in the mail are correct.
I cherry-picked it from the linux-4.9.y version.
Quoted 7 lines
That's commit
b399151cb48db30ad1e0e93dd40d68c6d007b637upstream. Do we really want to backport that thing to 4.4 or just live with the uglies ofx86_cpuinfo::x86_mask?TBH, I don't care, but the stable people might have opinions.
Quoted 8 lines
FYI, the Date: headers are generally odd when you send patches as they are not reflecting when the mail is sent. They reflect when the patch was written.
Thanks,
tglx
-------------------
From
4db1a97738fbbe14af9a8c746ebd11699f903f76Mon Sep 17 00:00:00 2001
Message-Id: <4db1a97738fbbe14af9a8c746ebd11699f903f76.1588001639.git.mgross@linux.intel.com>
In-Reply-To: <[email protected]>
References: <[email protected]>
From: Jia Zhang <[email protected]>
Date: Mon, 1 Jan 2018 09:52:10 +0800
Subject: [PATCH 1/5] x86/cpu: Rename cpu_data.x86_mask to
cpu_data.x86_stepping
To: [email protected]commit
b399151cb48db30ad1e0e93dd40d68c6d007b637upstream.
x86_maskis a confusing name which is hard to associate with the processor's stepping.Additionally, correct an indent issue in
lib/cpu.c.Signed-off-by Jia Zhang <[email protected]>[ Updated it to more recent kernels. ]Cc Linus Torvalds <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Thomas Gleixner <[email protected]>Signed-off-by Ingo Molnar <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Conflicts:
Quoted 10 lines
arch/x86/events/intel/core.c arch/x86/events/intel/lbr.c arch/x86/events/intel/p6.c arch/x86/kernel/cpu/common.c arch/x86/kernel/cpu/intel.c arch/x86/kernel/cpu/microcode/intel.c arch/x86/kernel/mpparse.c arch/x86/lib/cpu.c drivers/cpufreq/acpi-cpufreq.c drivers/cpufreq/powernow-k7.c
Quoted 1 line
What's that here for?
Its a habit I got into on my previous job where me and a team where doing a lot of rebases of an intel vendor kernel to track upstream. I think its useful information to see where there where merge or rebase conflicts. Thats where screw up's tended to happen and I just got into a habbit of saving the confilct list.
I'm happy to remove those.
Quoted 2 lines
Can you resend this series in a format I can use?
I will certainly try but, other than the smtp send failure dropping the one patch and dropping the Conflicts list in the backport is there something else I need to look out for? I "backported" the 4.9.y backport of Jia's patch I think that may be one thing Thomas was calling out. Is that ok or should I redo that backport using the original version it first landed in?
--mark
Quoted 6 lines · speck for mark gross
Quoted 1 line
Can you resend this series in a format I can use?
I will certainly try but, other than the smtp send failure dropping the one patch and dropping the Conflicts list in the backport is there something else I need to look out for? I "backported" the 4.9.y backport of Jia's patch I think that may be one thing Thomas was calling out. Is that ok or should I redo that backport using the original version it first landed in?
It's all sorted and pushed out to the speck repo and the bundles are there as well. Nothing to do right now.
Thanks,
tglx
Quoted 11 lines · speck for Thomas Gleixner
Quoted 6 lines · speck for mark gross
Quoted 1 line
Can you resend this series in a format I can use?
I will certainly try but, other than the smtp send failure dropping the one patch and dropping the Conflicts list in the backport is there something else I need to look out for? I "backported" the 4.9.y backport of Jia's patch I think that may be one thing Thomas was calling out. Is that ok or should I redo that backport using the original version it first landed in?
It's all sorted and pushed out to the speck repo and the bundles are there as well. Nothing to do right now.
Thank you very much!
FWIW I do appreciate your help and everyone who provided feedback to me throughout the prosecution of this issue and I plan to do noticeably better when the next one pops up.
--mark