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

803 lines
18 KiB
C
Raw Normal View History

/*
* AMD CPU Microcode Update Driver for Linux
*
* This driver allows to upgrade microcode on F10h AMD
* CPUs and later.
*
* Copyright (C) 2008-2011 Advanced Micro Devices Inc.
* 2013-2016 Borislav Petkov <bp@alien8.de>
*
* Author: Peter Oruba <peter.oruba@amd.com>
*
* Based on work by:
* Tigran Aivazian <aivazian.tigran@gmail.com>
*
* early loader:
* Copyright (C) 2013 Advanced Micro Devices, Inc.
*
* Author: Jacob Shin <jacob.shin@amd.com>
* Fixes: Borislav Petkov <bp@suse.de>
*
* Licensed under the terms of the GNU General Public
* License version 2. See file COPYING for details.
*/
#define pr_fmt(fmt) "microcode: " fmt
#include <linux/earlycpio.h>
#include <linux/firmware.h>
#include <linux/uaccess.h>
#include <linux/vmalloc.h>
#include <linux/initrd.h>
#include <linux/kernel.h>
#include <linux/pci.h>
#include <asm/microcode_amd.h>
#include <asm/microcode.h>
#include <asm/processor.h>
#include <asm/setup.h>
#include <asm/cpu.h>
#include <asm/msr.h>
static struct equiv_cpu_entry *equiv_cpu_table;
/*
* This points to the current valid container of microcode patches which we will
* save from the initrd/builtin before jettisoning its contents. @mc is the
* microcode patch we found to match.
*/
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
struct cont_desc {
struct microcode_amd *mc;
u32 cpuid_1_eax;
u32 psize;
u8 *data;
size_t size;
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
};
static u32 ucode_new_rev;
static u8 amd_ucode_patch[PATCH_MAX_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 09:55:21 +00:00
/*
* Microcode patch container file is prepended to the initrd in cpio
* format. See Documentation/x86/early-microcode.txt
*/
static const char
ucode_path[] __maybe_unused = "kernel/x86/microcode/AuthenticAMD.bin";
static u16 find_equiv_id(struct equiv_cpu_entry *equiv_table, u32 sig)
{
for (; equiv_table && equiv_table->installed_cpu; equiv_table++) {
if (sig == equiv_table->installed_cpu)
return equiv_table->equiv_cpu;
}
return 0;
}
/*
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 09:55:21 +00:00
* This scans the ucode blob for the proper container as we can have multiple
* containers glued together. Returns the equivalence ID from the equivalence
* table or 0 if none found.
* Returns the amount of bytes consumed while scanning. @desc contains all the
* data we're going to use in later stages of the application.
*/
static ssize_t parse_container(u8 *ucode, ssize_t size, struct cont_desc *desc)
{
struct equiv_cpu_entry *eq;
ssize_t orig_size = size;
u32 *hdr = (u32 *)ucode;
u16 eq_id;
u8 *buf;
/* Am I looking at an equivalence table header? */
if (hdr[0] != UCODE_MAGIC ||
hdr[1] != UCODE_EQUIV_CPU_TABLE_TYPE ||
hdr[2] == 0)
return CONTAINER_HDR_SZ;
buf = ucode;
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 09:55:21 +00:00
eq = (struct equiv_cpu_entry *)(buf + CONTAINER_HDR_SZ);
/* Find the equivalence ID of our CPU in this table: */
eq_id = find_equiv_id(eq, desc->cpuid_1_eax);
buf += hdr[2] + CONTAINER_HDR_SZ;
size -= hdr[2] + CONTAINER_HDR_SZ;
/*
* Scan through the rest of the container to find where it ends. We do
* some basic sanity-checking too.
*/
while (size > 0) {
struct microcode_amd *mc;
u32 patch_size;
hdr = (u32 *)buf;
if (hdr[0] != UCODE_UCODE_TYPE)
break;
/* Sanity-check patch size. */
patch_size = hdr[1];
if (patch_size > PATCH_MAX_SIZE)
break;
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 09:55:21 +00:00
/* Skip patch section header: */
buf += SECTION_HDR_SIZE;
size -= SECTION_HDR_SIZE;
mc = (struct microcode_amd *)buf;
if (eq_id == mc->hdr.processor_rev_id) {
desc->psize = patch_size;
desc->mc = mc;
}
buf += patch_size;
size -= patch_size;
}
/*
* If we have found a patch (desc->mc), it means we're looking at the
* container which has a patch for this CPU so return 0 to mean, @ucode
* already points to the proper container. Otherwise, we return the size
* we scanned so that we can advance to the next container in the
* buffer.
*/
if (desc->mc) {
desc->data = ucode;
desc->size = orig_size - size;
return 0;
}
return orig_size - size;
}
/*
* Scan the ucode blob for the proper container as we can have multiple
* containers glued together.
*/
static void scan_containers(u8 *ucode, size_t size, struct cont_desc *desc)
{
ssize_t rem = size;
while (rem >= 0) {
ssize_t s = parse_container(ucode, rem, desc);
if (!s)
return;
ucode += s;
rem -= s;
}
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 09:55:21 +00:00
}
static int __apply_microcode_amd(struct microcode_amd *mc)
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 09:55:21 +00:00
{
u32 rev, dummy;
native_wrmsrl(MSR_AMD64_PATCH_LOADER, (u64)(long)&mc->hdr.data_code);
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 09:55:21 +00:00
/* verify patch application was successful */
native_rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy);
if (rev != mc->hdr.patch_id)
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 09:55:21 +00:00
return -1;
return 0;
}
/*
* Early load occurs before we can vmalloc(). So we look for the microcode
* patch container file in initrd, traverse equivalent cpu table, look for a
* matching microcode patch, and update, all in initrd memory in place.
* When vmalloc() is available for use later -- on 64-bit during first AP load,
* and on 32-bit during save_microcode_in_initrd_amd() -- we can call
* load_microcode_amd() to save equivalent cpu table and microcode patches in
* kernel heap memory.
*
* Returns true if container found (sets @desc), false otherwise.
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 09:55:21 +00:00
*/
static bool
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
apply_microcode_early_amd(u32 cpuid_1_eax, void *ucode, size_t size, bool save_patch)
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 09:55:21 +00:00
{
struct cont_desc desc = { 0 };
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 09:55:21 +00:00
u8 (*patch)[PATCH_MAX_SIZE];
struct microcode_amd *mc;
u32 rev, dummy, *new_rev;
bool ret = false;
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 09:55:21 +00:00
#ifdef CONFIG_X86_32
new_rev = (u32 *)__pa_nodebug(&ucode_new_rev);
patch = (u8 (*)[PATCH_MAX_SIZE])__pa_nodebug(&amd_ucode_patch);
#else
new_rev = &ucode_new_rev;
patch = &amd_ucode_patch;
#endif
desc.cpuid_1_eax = cpuid_1_eax;
scan_containers(ucode, size, &desc);
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 09:55:21 +00:00
mc = desc.mc;
if (!mc)
return ret;
native_rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy);
if (rev >= mc->hdr.patch_id)
return ret;
if (!__apply_microcode_amd(mc)) {
*new_rev = mc->hdr.patch_id;
ret = true;
if (save_patch)
memcpy(patch, mc, min_t(u32, desc.psize, PATCH_MAX_SIZE));
}
return ret;
}
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 09:55:21 +00:00
static bool get_builtin_microcode(struct cpio_data *cp, unsigned int family)
{
#ifdef CONFIG_X86_64
char fw_name[36] = "amd-ucode/microcode_amd.bin";
if (family >= 0x15)
snprintf(fw_name, sizeof(fw_name),
"amd-ucode/microcode_amd_fam%.2xh.bin", family);
return get_builtin_firmware(cp, fw_name);
#else
return false;
#endif
}
static void __load_ucode_amd(unsigned int cpuid_1_eax, struct cpio_data *ret)
{
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 09:55:21 +00:00
struct ucode_cpu_info *uci;
struct cpio_data cp;
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 09:55:21 +00:00
const char *path;
bool use_pa;
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 09:55:21 +00:00
if (IS_ENABLED(CONFIG_X86_32)) {
uci = (struct ucode_cpu_info *)__pa_nodebug(ucode_cpu_info);
path = (const char *)__pa_nodebug(ucode_path);
use_pa = true;
} else {
uci = ucode_cpu_info;
path = ucode_path;
use_pa = false;
}
if (!get_builtin_microcode(&cp, x86_family(cpuid_1_eax)))
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 09:55:21 +00:00
cp = find_microcode_in_initrd(path, use_pa);
/* Needed in load_microcode_amd() */
uci->cpu_sig.sig = cpuid_1_eax;
*ret = cp;
}
void __init load_ucode_amd_bsp(unsigned int cpuid_1_eax)
{
struct cpio_data cp = { };
__load_ucode_amd(cpuid_1_eax, &cp);
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 09:55:21 +00:00
if (!(cp.data && cp.size))
return;
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
apply_microcode_early_amd(cpuid_1_eax, cp.data, cp.size, true);
}
void load_ucode_amd_ap(unsigned int cpuid_1_eax)
{
struct microcode_amd *mc;
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
struct cpio_data cp;
u32 *new_rev, rev, dummy;
if (IS_ENABLED(CONFIG_X86_32)) {
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
mc = (struct microcode_amd *)__pa_nodebug(amd_ucode_patch);
new_rev = (u32 *)__pa_nodebug(&ucode_new_rev);
} else {
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
mc = (struct microcode_amd *)amd_ucode_patch;
new_rev = &ucode_new_rev;
}
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
native_rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy);
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 09:55:21 +00:00
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
/* Check whether we have saved a new patch already: */
if (*new_rev && rev < mc->hdr.patch_id) {
if (!__apply_microcode_amd(mc)) {
*new_rev = mc->hdr.patch_id;
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 09:55:21 +00:00
return;
}
}
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
__load_ucode_amd(cpuid_1_eax, &cp);
if (!(cp.data && cp.size))
return;
x86/microcode/AMD: Remove AP scanning optimization The idea was to not scan the microcode blob on each AP (Application Processor) during boot and thus save us some milliseconds. However, on architectures where the microcode engine is shared between threads, this doesn't work. Here's why: The microcode on CPU0, i.e., the first thread, gets updated. The second thread, i.e., CPU1, i.e., the first AP walks into load_ucode_amd_ap(), sees that there's no container cached and goes and scans for the proper blob. It finds it and as a last step of apply_microcode_early_amd(), it tries to apply the patch but that core has already the updated microcode revision which it has received through CPU0's update. So it returns false and we do desc->size = -1 to prevent other APs from scanning. However, the next AP, CPU2, has a different microcode engine which hasn't been updated yet. The desc->size == -1 test prevents it from scanning the blob anew and we fail to update it. The fix is much more straight-forward than it looks: the BSP (BootStrapping Processor), i.e., CPU0, caches the microcode patch in amd_ucode_patch. We use that on the AP and try to apply it. In the 99.9999% of cases where we have homogeneous cores - *not* mixed-steppings - the application will be successful and we're good to go. In the remaining small set of systems, we will simply rescan the blob and find (or not, if none present) the proper patch and apply it then. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-16-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-01-20 20:29:54 +00:00
apply_microcode_early_amd(cpuid_1_eax, cp.data, cp.size, false);
}
static enum ucode_state
load_microcode_amd(bool save, u8 family, const u8 *data, size_t size);
int __init save_microcode_in_initrd_amd(unsigned int cpuid_1_eax)
{
struct cont_desc desc = { 0 };
enum ucode_state ret;
struct cpio_data cp;
cp = find_microcode_in_initrd(ucode_path, false);
if (!(cp.data && cp.size))
return -EINVAL;
desc.cpuid_1_eax = cpuid_1_eax;
scan_containers(cp.data, cp.size, &desc);
if (!desc.mc)
return -EINVAL;
ret = load_microcode_amd(true, x86_family(cpuid_1_eax), desc.data, desc.size);
if (ret != UCODE_OK)
return -EINVAL;
return 0;
}
void reload_ucode_amd(void)
{
struct microcode_amd *mc;
u32 rev, dummy;
mc = (struct microcode_amd *)amd_ucode_patch;
rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy);
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 09:55:21 +00:00
if (rev < mc->hdr.patch_id) {
if (!__apply_microcode_amd(mc)) {
ucode_new_rev = mc->hdr.patch_id;
pr_info("reload patch_level=0x%08x\n", ucode_new_rev);
}
}
}
static u16 __find_equiv_id(unsigned int cpu)
{
struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
return find_equiv_id(equiv_cpu_table, uci->cpu_sig.sig);
}
static u32 find_cpu_family_by_equiv_cpu(u16 equiv_cpu)
{
int i = 0;
BUG_ON(!equiv_cpu_table);
while (equiv_cpu_table[i].equiv_cpu != 0) {
if (equiv_cpu == equiv_cpu_table[i].equiv_cpu)
return equiv_cpu_table[i].installed_cpu;
i++;
}
return 0;
}
/*
* a small, trivial cache of per-family ucode patches
*/
static struct ucode_patch *cache_find_patch(u16 equiv_cpu)
{
struct ucode_patch *p;
list_for_each_entry(p, &microcode_cache, plist)
if (p->equiv_cpu == equiv_cpu)
return p;
return NULL;
}
static void update_cache(struct ucode_patch *new_patch)
{
struct ucode_patch *p;
list_for_each_entry(p, &microcode_cache, plist) {
if (p->equiv_cpu == new_patch->equiv_cpu) {
if (p->patch_id >= new_patch->patch_id) {
/* we already have the latest patch */
kfree(new_patch->data);
kfree(new_patch);
return;
}
list_replace(&p->plist, &new_patch->plist);
kfree(p->data);
kfree(p);
return;
}
}
/* no patch found, add it */
list_add_tail(&new_patch->plist, &microcode_cache);
}
static void free_cache(void)
{
struct ucode_patch *p, *tmp;
list_for_each_entry_safe(p, tmp, &microcode_cache, plist) {
__list_del(p->plist.prev, p->plist.next);
kfree(p->data);
kfree(p);
}
}
static struct ucode_patch *find_patch(unsigned int cpu)
{
u16 equiv_id;
equiv_id = __find_equiv_id(cpu);
if (!equiv_id)
return NULL;
return cache_find_patch(equiv_id);
}
static int collect_cpu_info_amd(int cpu, struct cpu_signature *csig)
{
struct cpuinfo_x86 *c = &cpu_data(cpu);
struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
struct ucode_patch *p;
csig->sig = cpuid_eax(0x00000001);
csig->rev = c->microcode;
/*
* a patch could have been loaded early, set uci->mc so that
* mc_bp_resume() can call apply_microcode()
*/
p = find_patch(cpu);
if (p && (p->patch_id == csig->rev))
uci->mc = p->data;
pr_info("CPU%d: patch_level=0x%08x\n", cpu, csig->rev);
return 0;
}
static unsigned int verify_patch_size(u8 family, u32 patch_size,
unsigned int size)
{
u32 max_size;
#define F1XH_MPB_MAX_SIZE 2048
#define F14H_MPB_MAX_SIZE 1824
#define F15H_MPB_MAX_SIZE 4096
#define F16H_MPB_MAX_SIZE 3458
#define F17H_MPB_MAX_SIZE 3200
switch (family) {
case 0x14:
max_size = F14H_MPB_MAX_SIZE;
break;
case 0x15:
max_size = F15H_MPB_MAX_SIZE;
break;
case 0x16:
max_size = F16H_MPB_MAX_SIZE;
break;
case 0x17:
max_size = F17H_MPB_MAX_SIZE;
break;
default:
max_size = F1XH_MPB_MAX_SIZE;
break;
}
if (patch_size > min_t(u32, size, max_size)) {
pr_err("patch size mismatch\n");
return 0;
}
return patch_size;
}
static enum ucode_state apply_microcode_amd(int cpu)
{
struct cpuinfo_x86 *c = &cpu_data(cpu);
struct microcode_amd *mc_amd;
struct ucode_cpu_info *uci;
struct ucode_patch *p;
u32 rev, dummy;
BUG_ON(raw_smp_processor_id() != cpu);
uci = ucode_cpu_info + cpu;
p = find_patch(cpu);
if (!p)
return UCODE_NFOUND;
mc_amd = p->data;
uci->mc = p->data;
rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy);
/* need to apply patch? */
if (rev >= mc_amd->hdr.patch_id) {
c->microcode = rev;
uci->cpu_sig.rev = rev;
return UCODE_OK;
}
if (__apply_microcode_amd(mc_amd)) {
pr_err("CPU%d: update failed for patch_level=0x%08x\n",
cpu, mc_amd->hdr.patch_id);
return UCODE_ERROR;
}
pr_info("CPU%d: new patch_level=0x%08x\n", cpu,
mc_amd->hdr.patch_id);
uci->cpu_sig.rev = mc_amd->hdr.patch_id;
c->microcode = mc_amd->hdr.patch_id;
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 21:48:27 +00:00
return UCODE_UPDATED;
}
static int install_equiv_cpu_table(const u8 *buf)
{
unsigned int *ibuf = (unsigned int *)buf;
unsigned int type = ibuf[1];
unsigned int size = ibuf[2];
if (type != UCODE_EQUIV_CPU_TABLE_TYPE || !size) {
pr_err("empty section/"
"invalid type field in container file section header\n");
return -EINVAL;
}
equiv_cpu_table = vmalloc(size);
if (!equiv_cpu_table) {
pr_err("failed to allocate equivalent CPU table\n");
return -ENOMEM;
}
memcpy(equiv_cpu_table, buf + CONTAINER_HDR_SZ, size);
/* add header length */
return size + CONTAINER_HDR_SZ;
}
static void free_equiv_cpu_table(void)
{
vfree(equiv_cpu_table);
equiv_cpu_table = NULL;
}
static void cleanup(void)
{
free_equiv_cpu_table();
free_cache();
}
/*
* We return the current size even if some of the checks failed so that
* we can skip over the next patch. If we return a negative value, we
* signal a grave error like a memory allocation has failed and the
* driver cannot continue functioning normally. In such cases, we tear
* down everything we've used up so far and exit.
*/
static int verify_and_add_patch(u8 family, u8 *fw, unsigned int leftover)
{
struct microcode_header_amd *mc_hdr;
struct ucode_patch *patch;
unsigned int patch_size, crnt_size, ret;
u32 proc_fam;
u16 proc_id;
patch_size = *(u32 *)(fw + 4);
crnt_size = patch_size + SECTION_HDR_SIZE;
mc_hdr = (struct microcode_header_amd *)(fw + SECTION_HDR_SIZE);
proc_id = mc_hdr->processor_rev_id;
proc_fam = find_cpu_family_by_equiv_cpu(proc_id);
if (!proc_fam) {
pr_err("No patch family for equiv ID: 0x%04x\n", proc_id);
return crnt_size;
}
/* check if patch is for the current family */
proc_fam = ((proc_fam >> 8) & 0xf) + ((proc_fam >> 20) & 0xff);
if (proc_fam != family)
return crnt_size;
if (mc_hdr->nb_dev_id || mc_hdr->sb_dev_id) {
pr_err("Patch-ID 0x%08x: chipset-specific code unsupported.\n",
mc_hdr->patch_id);
return crnt_size;
}
ret = verify_patch_size(family, patch_size, leftover);
if (!ret) {
pr_err("Patch-ID 0x%08x: size mismatch.\n", mc_hdr->patch_id);
return crnt_size;
}
patch = kzalloc(sizeof(*patch), GFP_KERNEL);
if (!patch) {
pr_err("Patch allocation failure.\n");
return -EINVAL;
}
patch->data = kmemdup(fw + SECTION_HDR_SIZE, patch_size, GFP_KERNEL);
if (!patch->data) {
pr_err("Patch data allocation failure.\n");
kfree(patch);
return -EINVAL;
}
INIT_LIST_HEAD(&patch->plist);
patch->patch_id = mc_hdr->patch_id;
patch->equiv_cpu = proc_id;
pr_debug("%s: Added patch_id: 0x%08x, proc_id: 0x%04x\n",
__func__, patch->patch_id, proc_id);
/* ... and add to cache. */
update_cache(patch);
return crnt_size;
}
static enum ucode_state __load_microcode_amd(u8 family, const u8 *data,
size_t size)
{
enum ucode_state ret = UCODE_ERROR;
unsigned int leftover;
u8 *fw = (u8 *)data;
int crnt_size = 0;
int offset;
offset = install_equiv_cpu_table(data);
if (offset < 0) {
pr_err("failed to create equivalent cpu table\n");
return ret;
}
fw += offset;
leftover = size - offset;
if (*(u32 *)fw != UCODE_UCODE_TYPE) {
pr_err("invalid type field in container file section header\n");
free_equiv_cpu_table();
return ret;
}
while (leftover) {
crnt_size = verify_and_add_patch(family, fw, leftover);
if (crnt_size < 0)
return ret;
fw += crnt_size;
leftover -= crnt_size;
}
return UCODE_OK;
}
static enum ucode_state
load_microcode_amd(bool save, u8 family, const u8 *data, size_t size)
{
enum ucode_state ret;
/* free old equiv table */
free_equiv_cpu_table();
ret = __load_microcode_amd(family, data, size);
if (ret != UCODE_OK)
cleanup();
#ifdef CONFIG_X86_32
/* save BSP's matching patch for early load */
if (save) {
struct ucode_patch *p = find_patch(0);
if (p) {
memset(amd_ucode_patch, 0, PATCH_MAX_SIZE);
memcpy(amd_ucode_patch, p->data, min_t(u32, ksize(p->data),
PATCH_MAX_SIZE));
}
}
#endif
return ret;
}
/*
* AMD microcode firmware naming convention, up to family 15h they are in
* the legacy file:
*
* amd-ucode/microcode_amd.bin
*
* This legacy file is always smaller than 2K in size.
*
* Beginning with family 15h, they are in family-specific firmware files:
*
* amd-ucode/microcode_amd_fam15h.bin
* amd-ucode/microcode_amd_fam16h.bin
* ...
*
* These might be larger than 2K.
*/
static enum ucode_state request_microcode_amd(int cpu, struct device *device,
bool refresh_fw)
{
char fw_name[36] = "amd-ucode/microcode_amd.bin";
struct cpuinfo_x86 *c = &cpu_data(cpu);
bool bsp = c->cpu_index == boot_cpu_data.cpu_index;
enum ucode_state ret = UCODE_NFOUND;
const struct firmware *fw;
/* reload ucode container only on the boot cpu */
if (!refresh_fw || !bsp)
return UCODE_OK;
if (c->x86 >= 0x15)
snprintf(fw_name, sizeof(fw_name), "amd-ucode/microcode_amd_fam%.2xh.bin", c->x86);
if (request_firmware_direct(&fw, (const char *)fw_name, device)) {
pr_debug("failed to load file %s\n", fw_name);
goto out;
}
ret = UCODE_ERROR;
if (*(u32 *)fw->data != UCODE_MAGIC) {
pr_err("invalid magic value (0x%08x)\n", *(u32 *)fw->data);
goto fw_release;
}
ret = load_microcode_amd(bsp, c->x86, fw->data, fw->size);
fw_release:
release_firmware(fw);
out:
return ret;
}
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 21:48:27 +00:00
static enum ucode_state
request_microcode_user(int cpu, const void __user *buf, size_t size)
{
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 21:48:27 +00:00
return UCODE_ERROR;
}
static void microcode_fini_cpu_amd(int cpu)
{
struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
uci->mc = NULL;
}
static struct microcode_ops microcode_amd_ops = {
.request_microcode_user = request_microcode_user,
.request_microcode_fw = request_microcode_amd,
.collect_cpu_info = collect_cpu_info_amd,
.apply_microcode = apply_microcode_amd,
.microcode_fini_cpu = microcode_fini_cpu_amd,
};
struct microcode_ops * __init init_amd_microcode(void)
{
struct cpuinfo_x86 *c = &boot_cpu_data;
if (c->x86_vendor != X86_VENDOR_AMD || c->x86 < 0x10) {
pr_warn("AMD CPU family 0x%x not supported\n", c->x86);
return NULL;
}
if (ucode_new_rev)
pr_info_once("microcode updated early to new patch_level=0x%08x\n",
ucode_new_rev);
return &microcode_amd_ops;
}
void __exit exit_amd_microcode(void)
{
cleanup();
}