linux/arch/x86/kernel/cpu/microcode/intel.c

661 lines
17 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Intel CPU Microcode Update Driver for Linux
*
* Copyright (C) 2000-2006 Tigran Aivazian <aivazian.tigran@gmail.com>
* 2006 Shaohua Li <shaohua.li@intel.com>
*
* Intel CPU microcode early update for Linux
*
* Copyright (C) 2012 Fenghua Yu <fenghua.yu@intel.com>
* H Peter Anvin" <hpa@zytor.com>
*/
#define pr_fmt(fmt) "microcode: " fmt
#include <linux/earlycpio.h>
#include <linux/firmware.h>
#include <linux/uaccess.h>
#include <linux/initrd.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/cpu.h>
#include <linux/uio.h>
#include <linux/mm.h>
#include <asm/cpu_device_id.h>
#include <asm/processor.h>
#include <asm/tlbflush.h>
#include <asm/setup.h>
#include <asm/msr.h>
#include "internal.h"
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
static const char ucode_path[] = "kernel/x86/microcode/GenuineIntel.bin";
#define UCODE_BSP_LOADED ((struct microcode_intel *)0x1UL)
/* Current microcode patch used in early patching on the APs. */
static struct microcode_intel *ucode_patch_va __read_mostly;
static struct microcode_intel *ucode_patch_late __read_mostly;
/* last level cache size per core */
static unsigned int llc_size_per_core __ro_after_init;
/* microcode format is extended from prescott processors */
struct extended_signature {
unsigned int sig;
unsigned int pf;
unsigned int cksum;
};
struct extended_sigtable {
unsigned int count;
unsigned int cksum;
unsigned int reserved[3];
struct extended_signature sigs[];
};
#define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_SIZE)
#define EXT_HEADER_SIZE (sizeof(struct extended_sigtable))
#define EXT_SIGNATURE_SIZE (sizeof(struct extended_signature))
static inline unsigned int get_totalsize(struct microcode_header_intel *hdr)
{
return hdr->datasize ? hdr->totalsize : DEFAULT_UCODE_TOTALSIZE;
}
static inline unsigned int exttable_size(struct extended_sigtable *et)
{
return et->count * EXT_SIGNATURE_SIZE + EXT_HEADER_SIZE;
}
void intel_collect_cpu_info(struct cpu_signature *sig)
{
sig->sig = cpuid_eax(1);
sig->pf = 0;
sig->rev = intel_get_microcode_revision();
if (x86_model(sig->sig) >= 5 || x86_family(sig->sig) > 6) {
unsigned int val[2];
/* get processor flags from MSR 0x17 */
native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
sig->pf = 1 << ((val[1] >> 18) & 7);
}
}
EXPORT_SYMBOL_GPL(intel_collect_cpu_info);
static inline bool cpu_signatures_match(struct cpu_signature *s1, unsigned int sig2,
unsigned int pf2)
{
if (s1->sig != sig2)
return false;
/* Processor flags are either both 0 or they intersect. */
return ((!s1->pf && !pf2) || (s1->pf & pf2));
}
bool intel_find_matching_signature(void *mc, struct cpu_signature *sig)
{
struct microcode_header_intel *mc_hdr = mc;
struct extended_signature *ext_sig;
struct extended_sigtable *ext_hdr;
int i;
if (cpu_signatures_match(sig, mc_hdr->sig, mc_hdr->pf))
return true;
/* Look for ext. headers: */
if (get_totalsize(mc_hdr) <= intel_microcode_get_datasize(mc_hdr) + MC_HEADER_SIZE)
return false;
ext_hdr = mc + intel_microcode_get_datasize(mc_hdr) + MC_HEADER_SIZE;
ext_sig = (void *)ext_hdr + EXT_HEADER_SIZE;
for (i = 0; i < ext_hdr->count; i++) {
if (cpu_signatures_match(sig, ext_sig->sig, ext_sig->pf))
return true;
ext_sig++;
}
return 0;
}
EXPORT_SYMBOL_GPL(intel_find_matching_signature);
/**
* intel_microcode_sanity_check() - Sanity check microcode file.
* @mc: Pointer to the microcode file contents.
* @print_err: Display failure reason if true, silent if false.
* @hdr_type: Type of file, i.e. normal microcode file or In Field Scan file.
* Validate if the microcode header type matches with the type
* specified here.
*
* Validate certain header fields and verify if computed checksum matches
* with the one specified in the header.
*
* Return: 0 if the file passes all the checks, -EINVAL if any of the checks
* fail.
*/
int intel_microcode_sanity_check(void *mc, bool print_err, int hdr_type)
{
unsigned long total_size, data_size, ext_table_size;
struct microcode_header_intel *mc_header = mc;
struct extended_sigtable *ext_header = NULL;
u32 sum, orig_sum, ext_sigcount = 0, i;
struct extended_signature *ext_sig;
total_size = get_totalsize(mc_header);
data_size = intel_microcode_get_datasize(mc_header);
if (data_size + MC_HEADER_SIZE > total_size) {
if (print_err)
pr_err("Error: bad microcode data file size.\n");
return -EINVAL;
}
if (mc_header->ldrver != 1 || mc_header->hdrver != hdr_type) {
if (print_err)
pr_err("Error: invalid/unknown microcode update format. Header type %d\n",
mc_header->hdrver);
return -EINVAL;
}
ext_table_size = total_size - (MC_HEADER_SIZE + data_size);
if (ext_table_size) {
u32 ext_table_sum = 0;
u32 *ext_tablep;
if (ext_table_size < EXT_HEADER_SIZE ||
((ext_table_size - EXT_HEADER_SIZE) % EXT_SIGNATURE_SIZE)) {
if (print_err)
pr_err("Error: truncated extended signature table.\n");
return -EINVAL;
}
ext_header = mc + MC_HEADER_SIZE + data_size;
if (ext_table_size != exttable_size(ext_header)) {
if (print_err)
pr_err("Error: extended signature table size mismatch.\n");
return -EFAULT;
}
ext_sigcount = ext_header->count;
/*
* Check extended table checksum: the sum of all dwords that
* comprise a valid table must be 0.
*/
ext_tablep = (u32 *)ext_header;
i = ext_table_size / sizeof(u32);
while (i--)
ext_table_sum += ext_tablep[i];
if (ext_table_sum) {
if (print_err)
pr_warn("Bad extended signature table checksum, aborting.\n");
return -EINVAL;
}
}
/*
* Calculate the checksum of update data and header. The checksum of
* valid update data and header including the extended signature table
* must be 0.
*/
orig_sum = 0;
i = (MC_HEADER_SIZE + data_size) / sizeof(u32);
while (i--)
orig_sum += ((u32 *)mc)[i];
if (orig_sum) {
if (print_err)
pr_err("Bad microcode data checksum, aborting.\n");
return -EINVAL;
}
if (!ext_table_size)
return 0;
/*
* Check extended signature checksum: 0 => valid.
*/
for (i = 0; i < ext_sigcount; i++) {
ext_sig = (void *)ext_header + EXT_HEADER_SIZE +
EXT_SIGNATURE_SIZE * i;
sum = (mc_header->sig + mc_header->pf + mc_header->cksum) -
(ext_sig->sig + ext_sig->pf + ext_sig->cksum);
if (sum) {
if (print_err)
pr_err("Bad extended signature checksum, aborting.\n");
return -EINVAL;
}
}
return 0;
}
EXPORT_SYMBOL_GPL(intel_microcode_sanity_check);
static void update_ucode_pointer(struct microcode_intel *mc)
{
kvfree(ucode_patch_va);
/*
* Save the virtual address for early loading and for eventual free
* on late loading.
*/
ucode_patch_va = mc;
}
static void save_microcode_patch(struct microcode_intel *patch)
{
unsigned int size = get_totalsize(&patch->hdr);
struct microcode_intel *mc;
mc = kvmemdup(patch, size, GFP_KERNEL);
if (mc)
update_ucode_pointer(mc);
else
pr_err("Unable to allocate microcode memory size: %u\n", size);
}
/* Scan blob for microcode matching the boot CPUs family, model, stepping */
static __init struct microcode_intel *scan_microcode(void *data, size_t size,
struct ucode_cpu_info *uci,
bool save)
{
struct microcode_header_intel *mc_header;
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
struct microcode_intel *patch = NULL;
u32 cur_rev = uci->cpu_sig.rev;
unsigned int mc_size;
for (; size >= sizeof(struct microcode_header_intel); size -= mc_size, data += mc_size) {
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
mc_header = (struct microcode_header_intel *)data;
mc_size = get_totalsize(mc_header);
if (!mc_size || mc_size > size ||
intel_microcode_sanity_check(data, false, MC_HEADER_TYPE_MICROCODE) < 0)
break;
if (!intel_find_matching_signature(data, &uci->cpu_sig))
continue;
/*
* For saving the early microcode, find the matching revision which
* was loaded on the BSP.
*
* On the BSP during early boot, find a newer revision than
* actually loaded in the CPU.
*/
if (save) {
if (cur_rev != mc_header->rev)
continue;
} else if (cur_rev >= mc_header->rev) {
continue;
}
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
patch = data;
cur_rev = mc_header->rev;
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
}
return size ? NULL : patch;
}
static enum ucode_state __apply_microcode(struct ucode_cpu_info *uci,
struct microcode_intel *mc,
u32 *cur_rev)
{
u32 rev;
if (!mc)
return UCODE_NFOUND;
/*
* Save us the MSR write below - which is a particular expensive
* operation - when the other hyperthread has updated the microcode
* already.
*/
*cur_rev = intel_get_microcode_revision();
if (*cur_rev >= mc->hdr.rev) {
uci->cpu_sig.rev = *cur_rev;
return UCODE_OK;
}
/*
* Writeback and invalidate caches before updating microcode to avoid
* internal issues depending on what the microcode is updating.
*/
native_wbinvd();
/* write microcode via MSR 0x79 */
native_wrmsrl(MSR_IA32_UCODE_WRITE, (unsigned long)mc->bits);
rev = intel_get_microcode_revision();
if (rev != mc->hdr.rev)
return UCODE_ERROR;
uci->cpu_sig.rev = rev;
return UCODE_UPDATED;
}
static enum ucode_state apply_microcode_early(struct ucode_cpu_info *uci)
{
struct microcode_intel *mc = uci->mc;
u32 cur_rev;
return __apply_microcode(uci, mc, &cur_rev);
}
static __init bool load_builtin_intel_microcode(struct cpio_data *cp)
{
unsigned int eax = 1, ebx, ecx = 0, edx;
struct firmware fw;
char name[30];
if (IS_ENABLED(CONFIG_X86_32))
return false;
native_cpuid(&eax, &ebx, &ecx, &edx);
sprintf(name, "intel-ucode/%02x-%02x-%02x",
x86_family(eax), x86_model(eax), x86_stepping(eax));
if (firmware_request_builtin(&fw, name)) {
cp->size = fw.size;
cp->data = (void *)fw.data;
return true;
}
return false;
}
static __init struct microcode_intel *get_microcode_blob(struct ucode_cpu_info *uci, bool save)
{
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
struct cpio_data cp;
intel_collect_cpu_info(&uci->cpu_sig);
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
if (!load_builtin_intel_microcode(&cp))
x86/microcode/32: Move early loading after paging enable 32-bit loads microcode before paging is enabled. The commit which introduced that has zero justification in the changelog. The cover letter has slightly more content, but it does not give any technical justification either: "The problem in current microcode loading method is that we load a microcode way, way too late; ideally we should load it before turning paging on. This may only be practical on 32 bits since we can't get to 64-bit mode without paging on, but we should still do it as early as at all possible." Handwaving word salad with zero technical content. Someone claimed in an offlist conversation that this is required for curing the ATOM erratum AAE44/AAF40/AAG38/AAH41. That erratum requires an microcode update in order to make the usage of PSE safe. But during early boot, PSE is completely irrelevant and it is evaluated way later. Neither is it relevant for the AP on single core HT enabled CPUs as the microcode loading on the AP is not doing anything. On dual core CPUs there is a theoretical problem if a split of an executable large page between enabling paging including PSE and loading the microcode happens. But that's only theoretical, it's practically irrelevant because the affected dual core CPUs are 64bit enabled and therefore have paging and PSE enabled before loading the microcode on the second core. So why would it work on 64-bit but not on 32-bit? The erratum: "AAG38 Code Fetch May Occur to Incorrect Address After a Large Page is Split Into 4-Kbyte Pages Problem: If software clears the PS (page size) bit in a present PDE (page directory entry), that will cause linear addresses mapped through this PDE to use 4-KByte pages instead of using a large page after old TLB entries are invalidated. Due to this erratum, if a code fetch uses this PDE before the TLB entry for the large page is invalidated then it may fetch from a different physical address than specified by either the old large page translation or the new 4-KByte page translation. This erratum may also cause speculative code fetches from incorrect addresses." The practical relevance for this is exactly zero because there is no splitting of large text pages during early boot-time, i.e. between paging enable and microcode loading, and neither during CPU hotplug. IOW, this load microcode before paging enable is yet another voodoo programming solution in search of a problem. What's worse is that it causes at least two serious problems: 1) When stackprotector is enabled, the microcode loader code has the stackprotector mechanics enabled. The read from the per CPU variable __stack_chk_guard is always accessing the virtual address either directly on UP or via %fs on SMP. In physical address mode this results in an access to memory above 3GB. So this works by chance as the hardware returns the same value when there is no RAM at this physical address. When there is RAM populated above 3G then the read is by chance the same as nothing changes that memory during the very early boot stage. That's not necessarily true during runtime CPU hotplug. 2) When function tracing is enabled, the relevant microcode loader functions and the functions invoked from there will call into the tracing code and evaluate global and per CPU variables in physical address mode. What could potentially go wrong? Cure this and move the microcode loading after the early paging enable, use the new temporary initrd mapping and remove the gunk in the microcode loader which is required to handle physical address mode. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231017211722.348298216@linutronix.de
2023-10-17 23:23:32 +02:00
cp = find_microcode_in_initrd(ucode_path);
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
if (!(cp.data && cp.size))
return NULL;
return scan_microcode(cp.data, cp.size, uci, save);
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
}
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
/*
* Invoked from an early init call to save the microcode blob which was
* selected during early boot when mm was not usable. The microcode must be
* saved because initrd is going away. It's an early init call so the APs
* just can use the pointer and do not have to scan initrd/builtin firmware
* again.
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
*/
static int __init save_builtin_microcode(void)
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
{
struct ucode_cpu_info uci;
if (xchg(&ucode_patch_va, NULL) != UCODE_BSP_LOADED)
return 0;
if (dis_ucode_ldr || boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
return 0;
uci.mc = get_microcode_blob(&uci, true);
if (uci.mc)
save_microcode_patch(uci.mc);
return 0;
}
early_initcall(save_builtin_microcode);
/* Load microcode on BSP from initrd or builtin blobs */
void __init load_ucode_intel_bsp(struct early_load_data *ed)
{
struct ucode_cpu_info uci;
uci.mc = get_microcode_blob(&uci, false);
ed->old_rev = uci.cpu_sig.rev;
if (uci.mc && apply_microcode_early(&uci) == UCODE_UPDATED) {
ucode_patch_va = UCODE_BSP_LOADED;
ed->new_rev = uci.cpu_sig.rev;
}
}
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
void load_ucode_intel_ap(void)
{
x86/microcode: Rework microcode loading Yeah, I know, I know, this is a huuge patch and reviewing it is hard. Sorry but this is the only way I could think of in which I can rewrite the microcode patches loading procedure without breaking (knowingly) the driver. So maybe this patch is easier to review if one looks at the files after the patch has been applied instead at the diff. Because then it becomes pretty obvious: * The BSP-loading path - load_ucode_bsp() is working independently from the AP path now and it doesn't save any pointers or patches anymore - it solely parses the builtin or initrd microcode and applies the patch. That's it. This fixes the CONFIG_RANDOMIZE_MEMORY offset fun more solidly. * The AP-loading path - load_ucode_ap() then goes and scans builtin/initrd *again* for the microcode patches but it caches them this time so that we don't have to do that scan on each AP but only once. This simplifies the code considerably. Then, when we save the microcode from the initrd/builtin, we go and add the relevant patches to our own cache. The AMD side did do that and now the Intel side does it too. So no more pointer copying and blabla, we save the microcode patches ourselves and are independent from initrd/builtin. This whole conversion gives us other benefits like unifying the initrd parsing into a single function: find_microcode_in_initrd() is used by both. The diffstat speaks for itself: 456 insertions(+), 695 deletions(-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20161025095522.11964-12-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-25 11:55:21 +02:00
struct ucode_cpu_info uci;
uci.mc = ucode_patch_va;
if (uci.mc)
apply_microcode_early(&uci);
}
/* Reload microcode on resume */
void reload_ucode_intel(void)
{
struct ucode_cpu_info uci = { .mc = ucode_patch_va, };
if (uci.mc)
apply_microcode_early(&uci);
}
static int collect_cpu_info(int cpu_num, struct cpu_signature *csig)
{
intel_collect_cpu_info(csig);
return 0;
}
static enum ucode_state apply_microcode_late(int cpu)
{
struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
struct microcode_intel *mc = ucode_patch_late;
enum ucode_state ret;
u32 cur_rev;
if (WARN_ON_ONCE(smp_processor_id() != cpu))
return UCODE_ERROR;
ret = __apply_microcode(uci, mc, &cur_rev);
if (ret != UCODE_UPDATED && ret != UCODE_OK)
return ret;
cpu_data(cpu).microcode = uci->cpu_sig.rev;
if (!cpu)
boot_cpu_data.microcode = uci->cpu_sig.rev;
return ret;
}
x86/microcode/intel: Add a minimum required revision for late loading In general users, don't have the necessary information to determine whether late loading of a new microcode version is safe and does not modify anything which the currently running kernel uses already, e.g. removal of CPUID bits or behavioural changes of MSRs. To address this issue, Intel has added a "minimum required version" field to a previously reserved field in the microcode header. Microcode updates should only be applied if the current microcode version is equal to, or greater than this minimum required version. Thomas made some suggestions on how meta-data in the microcode file could provide Linux with information to decide if the new microcode is suitable candidate for late loading. But even the "simpler" option requires a lot of metadata and corresponding kernel code to parse it, so the final suggestion was to add the 'minimum required version' field in the header. When microcode changes visible features, microcode will set the minimum required version to its own revision which prevents late loading. Old microcode blobs have the minimum revision field always set to 0, which indicates that there is no information and the kernel considers it unsafe. This is a pure OS software mechanism. The hardware/firmware ignores this header field. For early loading there is no restriction because OS visible features are enumerated after the early load and therefore a change has no effect. The check is always enabled, but by default not enforced. It can be enforced via Kconfig or kernel command line. If enforced, the kernel refuses to late load microcode with a minimum required version field which is zero or when the currently loaded microcode revision is smaller than the minimum required revision. If not enforced the load happens independent of the revision check to stay compatible with the existing behaviour, but it influences the decision whether the kernel is tainted or not. If the check signals that the late load is safe, then the kernel is not tainted. Early loading is not affected by this. [ tglx: Massaged changelog and fixed up the implementation ] Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231002115903.776467264@linutronix.de
2023-10-02 14:00:11 +02:00
static bool ucode_validate_minrev(struct microcode_header_intel *mc_header)
{
int cur_rev = boot_cpu_data.microcode;
/*
* When late-loading, ensure the header declares a minimum revision
* required to perform a late-load. The previously reserved field
* is 0 in older microcode blobs.
*/
if (!mc_header->min_req_ver) {
pr_info("Unsafe microcode update: Microcode header does not specify a required min version\n");
return false;
}
/*
* Check whether the current revision is either greater or equal to
* to the minimum revision specified in the header.
*/
if (cur_rev < mc_header->min_req_ver) {
pr_info("Unsafe microcode update: Current revision 0x%x too old\n", cur_rev);
pr_info("Current should be at 0x%x or higher. Use early loading instead\n", mc_header->min_req_ver);
return false;
}
return true;
}
static enum ucode_state parse_microcode_blobs(int cpu, struct iov_iter *iter)
{
struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
x86/microcode/intel: Add a minimum required revision for late loading In general users, don't have the necessary information to determine whether late loading of a new microcode version is safe and does not modify anything which the currently running kernel uses already, e.g. removal of CPUID bits or behavioural changes of MSRs. To address this issue, Intel has added a "minimum required version" field to a previously reserved field in the microcode header. Microcode updates should only be applied if the current microcode version is equal to, or greater than this minimum required version. Thomas made some suggestions on how meta-data in the microcode file could provide Linux with information to decide if the new microcode is suitable candidate for late loading. But even the "simpler" option requires a lot of metadata and corresponding kernel code to parse it, so the final suggestion was to add the 'minimum required version' field in the header. When microcode changes visible features, microcode will set the minimum required version to its own revision which prevents late loading. Old microcode blobs have the minimum revision field always set to 0, which indicates that there is no information and the kernel considers it unsafe. This is a pure OS software mechanism. The hardware/firmware ignores this header field. For early loading there is no restriction because OS visible features are enumerated after the early load and therefore a change has no effect. The check is always enabled, but by default not enforced. It can be enforced via Kconfig or kernel command line. If enforced, the kernel refuses to late load microcode with a minimum required version field which is zero or when the currently loaded microcode revision is smaller than the minimum required revision. If not enforced the load happens independent of the revision check to stay compatible with the existing behaviour, but it influences the decision whether the kernel is tainted or not. If the check signals that the late load is safe, then the kernel is not tainted. Early loading is not affected by this. [ tglx: Massaged changelog and fixed up the implementation ] Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231002115903.776467264@linutronix.de
2023-10-02 14:00:11 +02:00
bool is_safe, new_is_safe = false;
int cur_rev = uci->cpu_sig.rev;
unsigned int curr_mc_size = 0;
u8 *new_mc = NULL, *mc = NULL;
while (iov_iter_count(iter)) {
struct microcode_header_intel mc_header;
unsigned int mc_size, data_size;
u8 *data;
if (!copy_from_iter_full(&mc_header, sizeof(mc_header), iter)) {
pr_err("error! Truncated or inaccessible header in microcode data file\n");
goto fail;
}
mc_size = get_totalsize(&mc_header);
if (mc_size < sizeof(mc_header)) {
pr_err("error! Bad data in microcode data file (totalsize too small)\n");
goto fail;
}
data_size = mc_size - sizeof(mc_header);
if (data_size > iov_iter_count(iter)) {
pr_err("error! Bad data in microcode data file (truncated file?)\n");
goto fail;
}
/* For performance reasons, reuse mc area when possible */
if (!mc || mc_size > curr_mc_size) {
kvfree(mc);
mc = kvmalloc(mc_size, GFP_KERNEL);
if (!mc)
goto fail;
curr_mc_size = mc_size;
}
memcpy(mc, &mc_header, sizeof(mc_header));
data = mc + sizeof(mc_header);
if (!copy_from_iter_full(data, data_size, iter) ||
intel_microcode_sanity_check(mc, true, MC_HEADER_TYPE_MICROCODE) < 0)
goto fail;
if (cur_rev >= mc_header.rev)
continue;
if (!intel_find_matching_signature(mc, &uci->cpu_sig))
continue;
x86/microcode/intel: Add a minimum required revision for late loading In general users, don't have the necessary information to determine whether late loading of a new microcode version is safe and does not modify anything which the currently running kernel uses already, e.g. removal of CPUID bits or behavioural changes of MSRs. To address this issue, Intel has added a "minimum required version" field to a previously reserved field in the microcode header. Microcode updates should only be applied if the current microcode version is equal to, or greater than this minimum required version. Thomas made some suggestions on how meta-data in the microcode file could provide Linux with information to decide if the new microcode is suitable candidate for late loading. But even the "simpler" option requires a lot of metadata and corresponding kernel code to parse it, so the final suggestion was to add the 'minimum required version' field in the header. When microcode changes visible features, microcode will set the minimum required version to its own revision which prevents late loading. Old microcode blobs have the minimum revision field always set to 0, which indicates that there is no information and the kernel considers it unsafe. This is a pure OS software mechanism. The hardware/firmware ignores this header field. For early loading there is no restriction because OS visible features are enumerated after the early load and therefore a change has no effect. The check is always enabled, but by default not enforced. It can be enforced via Kconfig or kernel command line. If enforced, the kernel refuses to late load microcode with a minimum required version field which is zero or when the currently loaded microcode revision is smaller than the minimum required revision. If not enforced the load happens independent of the revision check to stay compatible with the existing behaviour, but it influences the decision whether the kernel is tainted or not. If the check signals that the late load is safe, then the kernel is not tainted. Early loading is not affected by this. [ tglx: Massaged changelog and fixed up the implementation ] Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231002115903.776467264@linutronix.de
2023-10-02 14:00:11 +02:00
is_safe = ucode_validate_minrev(&mc_header);
if (force_minrev && !is_safe)
continue;
kvfree(new_mc);
cur_rev = mc_header.rev;
new_mc = mc;
x86/microcode/intel: Add a minimum required revision for late loading In general users, don't have the necessary information to determine whether late loading of a new microcode version is safe and does not modify anything which the currently running kernel uses already, e.g. removal of CPUID bits or behavioural changes of MSRs. To address this issue, Intel has added a "minimum required version" field to a previously reserved field in the microcode header. Microcode updates should only be applied if the current microcode version is equal to, or greater than this minimum required version. Thomas made some suggestions on how meta-data in the microcode file could provide Linux with information to decide if the new microcode is suitable candidate for late loading. But even the "simpler" option requires a lot of metadata and corresponding kernel code to parse it, so the final suggestion was to add the 'minimum required version' field in the header. When microcode changes visible features, microcode will set the minimum required version to its own revision which prevents late loading. Old microcode blobs have the minimum revision field always set to 0, which indicates that there is no information and the kernel considers it unsafe. This is a pure OS software mechanism. The hardware/firmware ignores this header field. For early loading there is no restriction because OS visible features are enumerated after the early load and therefore a change has no effect. The check is always enabled, but by default not enforced. It can be enforced via Kconfig or kernel command line. If enforced, the kernel refuses to late load microcode with a minimum required version field which is zero or when the currently loaded microcode revision is smaller than the minimum required revision. If not enforced the load happens independent of the revision check to stay compatible with the existing behaviour, but it influences the decision whether the kernel is tainted or not. If the check signals that the late load is safe, then the kernel is not tainted. Early loading is not affected by this. [ tglx: Massaged changelog and fixed up the implementation ] Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231002115903.776467264@linutronix.de
2023-10-02 14:00:11 +02:00
new_is_safe = is_safe;
mc = NULL;
}
if (iov_iter_count(iter))
goto fail;
kvfree(mc);
if (!new_mc)
return UCODE_NFOUND;
ucode_patch_late = (struct microcode_intel *)new_mc;
x86/microcode/intel: Add a minimum required revision for late loading In general users, don't have the necessary information to determine whether late loading of a new microcode version is safe and does not modify anything which the currently running kernel uses already, e.g. removal of CPUID bits or behavioural changes of MSRs. To address this issue, Intel has added a "minimum required version" field to a previously reserved field in the microcode header. Microcode updates should only be applied if the current microcode version is equal to, or greater than this minimum required version. Thomas made some suggestions on how meta-data in the microcode file could provide Linux with information to decide if the new microcode is suitable candidate for late loading. But even the "simpler" option requires a lot of metadata and corresponding kernel code to parse it, so the final suggestion was to add the 'minimum required version' field in the header. When microcode changes visible features, microcode will set the minimum required version to its own revision which prevents late loading. Old microcode blobs have the minimum revision field always set to 0, which indicates that there is no information and the kernel considers it unsafe. This is a pure OS software mechanism. The hardware/firmware ignores this header field. For early loading there is no restriction because OS visible features are enumerated after the early load and therefore a change has no effect. The check is always enabled, but by default not enforced. It can be enforced via Kconfig or kernel command line. If enforced, the kernel refuses to late load microcode with a minimum required version field which is zero or when the currently loaded microcode revision is smaller than the minimum required revision. If not enforced the load happens independent of the revision check to stay compatible with the existing behaviour, but it influences the decision whether the kernel is tainted or not. If the check signals that the late load is safe, then the kernel is not tainted. Early loading is not affected by this. [ tglx: Massaged changelog and fixed up the implementation ] Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231002115903.776467264@linutronix.de
2023-10-02 14:00:11 +02:00
return new_is_safe ? UCODE_NEW_SAFE : UCODE_NEW;
fail:
kvfree(mc);
kvfree(new_mc);
return UCODE_ERROR;
}
static bool is_blacklisted(unsigned int cpu)
{
struct cpuinfo_x86 *c = &cpu_data(cpu);
/*
* Late loading on model 79 with microcode revision less than 0x0b000021
* 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_vfm == INTEL_BROADWELL_X &&
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);
pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n");
return true;
}
return false;
}
static enum ucode_state request_microcode_fw(int cpu, struct device *device)
{
struct cpuinfo_x86 *c = &cpu_data(cpu);
const struct firmware *firmware;
struct iov_iter iter;
x86: microcode: use smp_call_function_single instead of set_cpus_allowed, cleanup of synchronization logic * Solve issues described in 6f66cbc63081fd70e3191b4dbb796746780e5ae1 in a way that doesn't resort to set_cpus_allowed(); * in fact, only collect_cpu_info and apply_microcode callbacks must run on a target cpu, others will do just fine on any other. smp_call_function_single() (as suggested by Ingo) is used to run these callbacks on a target cpu. * cleanup of synchronization logic of the 'microcode_core' part The generic 'microcode_core' part guarantees that only a single cpu (be it a full-fledged cpu, one of the cores or HT) is being updated at any particular moment of time. In general, there is no need for any additional sync. mechanism in arch-specific parts (the patch removes existing spinlocks). See also the "Synchronization" section in microcode_core.c. * return -EINVAL instead of -1 (which is translated into -EPERM) in microcode_write(), reload_cpu() and mc_sysdev_add(). Other suggestions for an error code? * use 'enum ucode_state' as return value of request_microcode_{fw, user} to gain more flexibility by distinguishing between real error cases and situations when an appropriate ucode was not found (which is not an error per-se). * some minor cleanups Thanks a lot to Hugh Dickins for review/suggestions/testing! Reference: http://marc.info/?l=linux-kernel&m=124025889012541&w=2 [ Impact: refactor and clean up microcode driver locking code ] Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com> Acked-by: Hugh Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Peter Oruba <peter.oruba@amd.com> Cc: Arjan van de Ven <arjan@infradead.org> LKML-Reference: <1242078507.5560.9.camel@earth> [ did some more cleanups ] Signed-off-by: Ingo Molnar <mingo@elte.hu> arch/x86/include/asm/microcode.h | 25 ++ arch/x86/kernel/microcode_amd.c | 58 ++---- arch/x86/kernel/microcode_core.c | 326 +++++++++++++++++++++----------------- arch/x86/kernel/microcode_intel.c | 92 +++------- 4 files changed, 261 insertions(+), 240 deletions(-) (~20 new comment lines)
2009-05-11 23:48:27 +02:00
enum ucode_state ret;
struct kvec kvec;
char name[30];
if (is_blacklisted(cpu))
return UCODE_NFOUND;
sprintf(name, "intel-ucode/%02x-%02x-%02x",
c->x86, c->x86_model, c->x86_stepping);
x86: microcode: use smp_call_function_single instead of set_cpus_allowed, cleanup of synchronization logic * Solve issues described in 6f66cbc63081fd70e3191b4dbb796746780e5ae1 in a way that doesn't resort to set_cpus_allowed(); * in fact, only collect_cpu_info and apply_microcode callbacks must run on a target cpu, others will do just fine on any other. smp_call_function_single() (as suggested by Ingo) is used to run these callbacks on a target cpu. * cleanup of synchronization logic of the 'microcode_core' part The generic 'microcode_core' part guarantees that only a single cpu (be it a full-fledged cpu, one of the cores or HT) is being updated at any particular moment of time. In general, there is no need for any additional sync. mechanism in arch-specific parts (the patch removes existing spinlocks). See also the "Synchronization" section in microcode_core.c. * return -EINVAL instead of -1 (which is translated into -EPERM) in microcode_write(), reload_cpu() and mc_sysdev_add(). Other suggestions for an error code? * use 'enum ucode_state' as return value of request_microcode_{fw, user} to gain more flexibility by distinguishing between real error cases and situations when an appropriate ucode was not found (which is not an error per-se). * some minor cleanups Thanks a lot to Hugh Dickins for review/suggestions/testing! Reference: http://marc.info/?l=linux-kernel&m=124025889012541&w=2 [ Impact: refactor and clean up microcode driver locking code ] Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com> Acked-by: Hugh Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Peter Oruba <peter.oruba@amd.com> Cc: Arjan van de Ven <arjan@infradead.org> LKML-Reference: <1242078507.5560.9.camel@earth> [ did some more cleanups ] Signed-off-by: Ingo Molnar <mingo@elte.hu> arch/x86/include/asm/microcode.h | 25 ++ arch/x86/kernel/microcode_amd.c | 58 ++---- arch/x86/kernel/microcode_core.c | 326 +++++++++++++++++++++----------------- arch/x86/kernel/microcode_intel.c | 92 +++------- 4 files changed, 261 insertions(+), 240 deletions(-) (~20 new comment lines)
2009-05-11 23:48:27 +02:00
if (request_firmware_direct(&firmware, name, device)) {
pr_debug("data file %s load failed\n", name);
x86: microcode: use smp_call_function_single instead of set_cpus_allowed, cleanup of synchronization logic * Solve issues described in 6f66cbc63081fd70e3191b4dbb796746780e5ae1 in a way that doesn't resort to set_cpus_allowed(); * in fact, only collect_cpu_info and apply_microcode callbacks must run on a target cpu, others will do just fine on any other. smp_call_function_single() (as suggested by Ingo) is used to run these callbacks on a target cpu. * cleanup of synchronization logic of the 'microcode_core' part The generic 'microcode_core' part guarantees that only a single cpu (be it a full-fledged cpu, one of the cores or HT) is being updated at any particular moment of time. In general, there is no need for any additional sync. mechanism in arch-specific parts (the patch removes existing spinlocks). See also the "Synchronization" section in microcode_core.c. * return -EINVAL instead of -1 (which is translated into -EPERM) in microcode_write(), reload_cpu() and mc_sysdev_add(). Other suggestions for an error code? * use 'enum ucode_state' as return value of request_microcode_{fw, user} to gain more flexibility by distinguishing between real error cases and situations when an appropriate ucode was not found (which is not an error per-se). * some minor cleanups Thanks a lot to Hugh Dickins for review/suggestions/testing! Reference: http://marc.info/?l=linux-kernel&m=124025889012541&w=2 [ Impact: refactor and clean up microcode driver locking code ] Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com> Acked-by: Hugh Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Peter Oruba <peter.oruba@amd.com> Cc: Arjan van de Ven <arjan@infradead.org> LKML-Reference: <1242078507.5560.9.camel@earth> [ did some more cleanups ] Signed-off-by: Ingo Molnar <mingo@elte.hu> arch/x86/include/asm/microcode.h | 25 ++ arch/x86/kernel/microcode_amd.c | 58 ++---- arch/x86/kernel/microcode_core.c | 326 +++++++++++++++++++++----------------- arch/x86/kernel/microcode_intel.c | 92 +++------- 4 files changed, 261 insertions(+), 240 deletions(-) (~20 new comment lines)
2009-05-11 23:48:27 +02:00
return UCODE_NFOUND;
}
kvec.iov_base = (void *)firmware->data;
kvec.iov_len = firmware->size;
iov_iter_kvec(&iter, ITER_SOURCE, &kvec, 1, firmware->size);
ret = parse_microcode_blobs(cpu, &iter);
release_firmware(firmware);
return ret;
}
static void finalize_late_load(int result)
{
if (!result)
update_ucode_pointer(ucode_patch_late);
else
kvfree(ucode_patch_late);
ucode_patch_late = NULL;
}
static struct microcode_ops microcode_intel_ops = {
.request_microcode_fw = request_microcode_fw,
.collect_cpu_info = collect_cpu_info,
.apply_microcode = apply_microcode_late,
.finalize_late_load = finalize_late_load,
.use_nmi = IS_ENABLED(CONFIG_X86_64),
};
static __init void calc_llc_size_per_core(struct cpuinfo_x86 *c)
{
u64 llc_size = c->x86_cache_size * 1024ULL;
do_div(llc_size, topology_num_cores_per_package());
llc_size_per_core = (unsigned int)llc_size;
}
struct microcode_ops * __init init_intel_microcode(void)
{
struct cpuinfo_x86 *c = &boot_cpu_data;
if (c->x86_vendor != X86_VENDOR_INTEL || c->x86 < 6 ||
cpu_has(c, X86_FEATURE_IA64)) {
pr_err("Intel CPU family 0x%x not supported\n", c->x86);
return NULL;
}
calc_llc_size_per_core(c);
return &microcode_intel_ops;
}