x86/microcode/intel: Extend BDW late-loading further with LLC size check
Subsystems (2)
Borislav Petkov
maintainerPATCH 1/2 x86/microcode/intel: Extend BDW late-loading further with LLC size check
From: Jia Zhang <[email protected]>
The commit
b94b73733171 ("x86/microcode/intel: Extend BDW late-loading with a revision check")
reduced the impact of erratum BDF90 for Broadwell model 79.
The impact can be reduced further by checking the size of the last level cache portion per core.
Tony: "The erratum says the problem only occurs on the large-cache SKUs. So we only need to avoid the update if we are on a big cache SKU that is also running old microcode."
For more details, see erratum BDF90 in document #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family Specification Update) from September 2017.
--- arch/x86/kernel/cpu/microcode/intel.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)
arch/x86/kernel/cpu/microcode/intel.c +18 -2
@@ -45,6 +45,9 @@ static const char ucode_path[] = "kernel/x86/microcode/GenuineIntel.bin";/* Current microcode patch used in early patching on the APs. */ static struct microcode_intel *intel_ucode_patch; +/* last level cache size per core */ +static int llc_size_per_core; +static inline bool cpu_signatures_match (unsigned int s1,unsigned int p1,unsigned int s2,unsigned int p2) {
@@ -912,12 +915,14 @@ static bool is_blacklisted(unsigned int cpu)/* * Late loading on model 79 with microcode revision less than 0x0b000021 -* may result in a system hang. This behavior is documented in item -* BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family). +* and LLC size per core bigger than 2.5MB may result in a system hang. +* This behavior is documented in item BDF90, #334165 (Intel Xeon +* Processor E7-8800/4800 v4 Product Family). */ if (c->x86 ==6 && c->x86_model ==INTEL_FAM6_BROADWELL_X && c->x86_mask ==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);pr_err_once ("Please consider either early loading through initrd/built-in or a potential BIOS update.\n" );
@@ -975,6 +980,15 @@ static struct microcode_ops microcode_intel_ops = { .apply_microcode = apply_microcode_intel, }; +static int __init calc_llc_size_per_core (struct cpuinfo_x86 *c) +{ +u64 llc_size = c->x86_cache_size *1024 ; + +do_div (llc_size, c->x86_max_cores); + +return (int )llc_size; +} +struct microcode_ops *__init init_intel_microcode (void ) {struct cpuinfo_x86 *c = &boot_cpu_data;
@@ -985,5 +999,7 @@ struct microcode_ops * __init init_intel_microcode(void)return NULL ; } + llc_size_per_core =calc_llc_size_per_core (c); +return µcode_intel_ops; }
Signature · 1 line
2.13.0
Borislav Petkov
maintainerPATCH 2/2 x86/microcode: Fix again accessing initrd after having been freed
From: Borislav Petkov <[email protected]>
Commit
24c2503255d3 ("x86/microcode: Do not access the initrd after it has been freed")
fixed attempts to access initrd from the microcode loader after it has been freed. However, a similar KASAN warning was reported (stack trace edited):
smpboot: Booting Node 0 Processor 1 APIC 0x11
==================================================================
BUG: KASAN: use-after-free in find_cpio_data+0x9b5/0xa50
Read of size 1 at addr ffff880035ffd000 by task swapper/1/0
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.8-slack #7
Hardware name: System manufacturer System Product Name/A88X-PLUS, BIOS 3003 03/10/2016
Call Trace:
dump_stack
print_address_description
kasan_report
? find_cpio_data
__asan_report_load1_noabort
find_cpio_data
find_microcode_in_initrd
__load_ucode_amd
load_ucode_amd_ap
load_ucode_apAfter some investigation, it turned out that a merge was done using the wrong side to resolve, leading to picking up the previous state, before the 24c2503255d3 fix. Therefore the Fixes tag below contains a merge commit.
Revert the mismerge by catching the save_microcode_in_initrd_amd() retval and thus letting the function exit with the last return statement so that initrd_gone can be set to true.
--- arch/x86/kernel/cpu/microcode/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/cpu/microcode/core.c +1 -1
@@ -239,7 +239,7 @@ static int __init save_microcode_in_initrd(void)break ;case X86_VENDOR_AMD :if (c->x86 >=0x10 ) -return save_microcode_in_initrd_amd (cpuid_eax (1 )); + ret =save_microcode_in_initrd_amd (cpuid_eax (1 ));break ;default :break ;
Signature · 1 line
2.13.0
tip-bot for Borislav Petkov
merge bot[tip:x86/urgent] x86/microcode: Fix again accessing initrd after having been freed
x86/microcode: Fix again accessing initrd after having been freed
Commit-ID: 1d080f096fe33f031d26e19b3ef0146f66b8b0f1 Gitweb: https://git.kernel.org/tip/1d080f096fe33f031d26e19b3ef0146f66b8b0f1 Author: Borislav Petkov <[email protected]> AuthorDate: Tue, 23 Jan 2018 11:41:33 +0100 Committer: Thomas Gleixner <[email protected]> CommitDate: Wed, 24 Jan 2018 13:00:35 +0100
x86/microcode: Fix again accessing initrd after having been freed
Commit 24c2503255d3 ("x86/microcode: Do not access the initrd after it has been freed") fixed attempts to access initrd from the microcode loader after it has been freed. However, a similar KASAN warning was reported (stack trace edited):
smpboot: Booting Node 0 Processor 1 APIC 0x11
==================================================================
BUG: KASAN: use-after-free in find_cpio_data+0x9b5/0xa50
Read of size 1 at addr ffff880035ffd000 by task swapper/1/0
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.8-slack #7
Hardware name: System manufacturer System Product Name/A88X-PLUS, BIOS 3003 03/10/2016
Call Trace:
dump_stack
print_address_description
kasan_report
? find_cpio_data
__asan_report_load1_noabort
find_cpio_data
find_microcode_in_initrd
__load_ucode_amd
load_ucode_amd_ap
load_ucode_apAfter some investigation, it turned out that a merge was done using the wrong side to resolve, leading to picking up the previous state, before the 24c2503255d3 fix. Therefore the Fixes tag below contains a merge commit.
Revert the mismerge by catching the save_microcode_in_initrd_amd() retval and thus letting the function exit with the last return statement so that initrd_gone can be set to true.
--- arch/x86/kernel/cpu/microcode/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/cpu/microcode/core.c +1 -1
@@ -239,7 +239,7 @@ static int __init save_microcode_in_initrd(void)break ;case X86_VENDOR_AMD :if (c->x86 >=0x10 ) -return save_microcode_in_initrd_amd (cpuid_eax (1 )); + ret =save_microcode_in_initrd_amd (cpuid_eax (1 ));break ;default :break ;