2019-05-27 08:55:01 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2008-07-28 18:44:17 +02:00
|
|
|
/*
|
2015-05-11 10:15:47 +02:00
|
|
|
* CPU Microcode Update Driver for Linux
|
2008-07-28 18:44:17 +02:00
|
|
|
*
|
2017-05-12 15:46:44 -07:00
|
|
|
* Copyright (C) 2000-2006 Tigran Aivazian <aivazian.tigran@gmail.com>
|
2015-05-11 10:15:47 +02:00
|
|
|
* 2006 Shaohua Li <shaohua.li@intel.com>
|
2016-10-25 11:55:22 +02:00
|
|
|
* 2013-2016 Borislav Petkov <bp@alien8.de>
|
2008-07-28 18:44:17 +02:00
|
|
|
*
|
2015-10-20 11:54:45 +02:00
|
|
|
* X86 CPU microcode early update for Linux:
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2012 Fenghua Yu <fenghua.yu@intel.com>
|
|
|
|
|
* H Peter Anvin" <hpa@zytor.com>
|
|
|
|
|
* (C) 2015 Borislav Petkov <bp@alien8.de>
|
|
|
|
|
*
|
2015-05-11 10:15:47 +02:00
|
|
|
* This driver allows to upgrade microcode on x86 processors.
|
2008-07-28 18:44:17 +02:00
|
|
|
*/
|
2009-12-08 22:30:50 -08:00
|
|
|
|
2015-10-20 11:54:46 +02:00
|
|
|
#define pr_fmt(fmt) "microcode: " fmt
|
2009-12-08 22:30:50 -08:00
|
|
|
|
2008-07-28 18:44:17 +02:00
|
|
|
#include <linux/platform_device.h>
|
2018-02-28 11:28:46 +01:00
|
|
|
#include <linux/stop_machine.h>
|
2015-10-20 11:54:45 +02:00
|
|
|
#include <linux/syscore_ops.h>
|
2009-03-11 11:19:46 +01:00
|
|
|
#include <linux/miscdevice.h>
|
2009-05-11 23:48:27 +02:00
|
|
|
#include <linux/capability.h>
|
2015-10-20 11:54:45 +02:00
|
|
|
#include <linux/firmware.h>
|
2023-10-02 14:00:05 +02:00
|
|
|
#include <linux/cpumask.h>
|
2009-03-11 11:19:46 +01:00
|
|
|
#include <linux/kernel.h>
|
2018-02-28 11:28:46 +01:00
|
|
|
#include <linux/delay.h>
|
2009-03-11 11:19:46 +01:00
|
|
|
#include <linux/mutex.h>
|
|
|
|
|
#include <linux/cpu.h>
|
2018-02-28 11:28:46 +01:00
|
|
|
#include <linux/nmi.h>
|
2009-03-11 11:19:46 +01:00
|
|
|
#include <linux/fs.h>
|
|
|
|
|
#include <linux/mm.h>
|
2008-07-28 18:44:17 +02:00
|
|
|
|
2023-10-02 14:00:05 +02:00
|
|
|
#include <asm/apic.h>
|
2015-10-20 11:54:45 +02:00
|
|
|
#include <asm/cpu_device_id.h>
|
|
|
|
|
#include <asm/perf_event.h>
|
2009-03-11 11:19:46 +01:00
|
|
|
#include <asm/processor.h>
|
2015-10-20 11:54:45 +02:00
|
|
|
#include <asm/cmdline.h>
|
2016-10-25 11:55:21 +02:00
|
|
|
#include <asm/setup.h>
|
2008-07-28 18:44:17 +02:00
|
|
|
|
2023-08-12 21:58:47 +02:00
|
|
|
#include "internal.h"
|
|
|
|
|
|
2009-03-11 11:19:46 +01:00
|
|
|
static struct microcode_ops *microcode_ops;
|
2023-10-02 13:59:43 +02:00
|
|
|
bool dis_ucode_ldr = true;
|
2015-10-20 11:54:46 +02:00
|
|
|
|
2023-10-17 23:24:16 +02:00
|
|
|
bool force_minrev = IS_ENABLED(CONFIG_MICROCODE_LATE_FORCE_MINREV);
|
|
|
|
|
module_param(force_minrev, bool, S_IRUSR | S_IWUSR);
|
|
|
|
|
|
2009-05-11 23:48:27 +02:00
|
|
|
/*
|
|
|
|
|
* Synchronization.
|
|
|
|
|
*
|
|
|
|
|
* All non cpu-hotplug-callback call sites use:
|
|
|
|
|
*
|
2021-08-03 16:15:51 +02:00
|
|
|
* - cpus_read_lock/unlock() to synchronize with
|
2009-05-11 23:48:27 +02:00
|
|
|
* the cpu-hotplug-callback call sites.
|
|
|
|
|
*
|
|
|
|
|
* We guarantee that only a single cpu is being
|
|
|
|
|
* updated at any particular moment of time.
|
|
|
|
|
*/
|
2009-03-11 11:19:46 +01:00
|
|
|
struct ucode_cpu_info ucode_cpu_info[NR_CPUS];
|
2008-07-28 18:44:17 +02:00
|
|
|
|
2017-01-20 21:29:51 +01:00
|
|
|
/*
|
|
|
|
|
* Those patch levels cannot be updated to newer ones and thus should be final.
|
|
|
|
|
*/
|
|
|
|
|
static u32 final_levels[] = {
|
|
|
|
|
0x01000098,
|
|
|
|
|
0x0100009f,
|
|
|
|
|
0x010000af,
|
|
|
|
|
0, /* T-101 terminator */
|
|
|
|
|
};
|
|
|
|
|
|
2023-11-15 22:02:12 +01:00
|
|
|
struct early_load_data early_data;
|
|
|
|
|
|
2017-01-20 21:29:51 +01:00
|
|
|
/*
|
|
|
|
|
* Check the current patch level on this CPU.
|
|
|
|
|
*
|
|
|
|
|
* Returns:
|
|
|
|
|
* - true: if update should stop
|
|
|
|
|
* - false: otherwise
|
|
|
|
|
*/
|
|
|
|
|
static bool amd_check_current_patch_level(void)
|
|
|
|
|
{
|
|
|
|
|
u32 lvl, dummy, i;
|
|
|
|
|
u32 *levels;
|
|
|
|
|
|
|
|
|
|
native_rdmsr(MSR_AMD64_PATCH_LEVEL, lvl, dummy);
|
|
|
|
|
|
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
|
|
|
levels = final_levels;
|
2017-01-20 21:29:51 +01:00
|
|
|
|
|
|
|
|
for (i = 0; levels[i]; i++) {
|
|
|
|
|
if (lvl == levels[i])
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-20 11:54:45 +02:00
|
|
|
static bool __init check_loader_disabled_bsp(void)
|
|
|
|
|
{
|
2016-02-03 12:33:31 +01:00
|
|
|
static const char *__dis_opt_str = "dis_ucode_ldr";
|
2015-10-20 11:54:45 +02:00
|
|
|
const char *cmdline = boot_command_line;
|
2016-02-03 12:33:31 +01:00
|
|
|
const char *option = __dis_opt_str;
|
2015-10-20 11:54:45 +02:00
|
|
|
|
2016-12-18 17:44:13 +01:00
|
|
|
/*
|
|
|
|
|
* CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
|
|
|
|
|
* completely accurate as xen pv guests don't see that CPUID bit set but
|
|
|
|
|
* that's good enough as they don't land on the BSP path anyway.
|
|
|
|
|
*/
|
2017-01-20 21:29:47 +01:00
|
|
|
if (native_cpuid_ecx(1) & BIT(31))
|
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
|
|
|
return true;
|
2016-12-18 17:44:13 +01:00
|
|
|
|
2017-01-20 21:29:51 +01:00
|
|
|
if (x86_cpuid_vendor() == X86_VENDOR_AMD) {
|
|
|
|
|
if (amd_check_current_patch_level())
|
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
|
|
|
return true;
|
2017-01-20 21:29:51 +01:00
|
|
|
}
|
|
|
|
|
|
2016-12-18 17:44:13 +01:00
|
|
|
if (cmdline_find_option_bool(cmdline, option) <= 0)
|
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
|
|
|
dis_ucode_ldr = false;
|
2015-10-20 11:54:45 +02:00
|
|
|
|
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
|
|
|
return dis_ucode_ldr;
|
2015-10-20 11:54:45 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void __init load_ucode_bsp(void)
|
|
|
|
|
{
|
2017-01-20 21:29:50 +01:00
|
|
|
unsigned int cpuid_1_eax;
|
2017-10-12 13:23:16 +02:00
|
|
|
bool intel = true;
|
2015-10-20 11:54:45 +02:00
|
|
|
|
2017-10-12 13:23:16 +02:00
|
|
|
if (!have_cpuid_p())
|
2015-10-20 11:54:45 +02:00
|
|
|
return;
|
|
|
|
|
|
2017-01-20 21:29:47 +01:00
|
|
|
cpuid_1_eax = native_cpuid_eax(1);
|
2015-10-20 11:54:45 +02:00
|
|
|
|
2017-01-20 21:29:50 +01:00
|
|
|
switch (x86_cpuid_vendor()) {
|
2015-10-20 11:54:45 +02:00
|
|
|
case X86_VENDOR_INTEL:
|
2017-10-12 13:23:16 +02:00
|
|
|
if (x86_family(cpuid_1_eax) < 6)
|
|
|
|
|
return;
|
2015-10-20 11:54:45 +02:00
|
|
|
break;
|
2017-10-12 13:23:16 +02:00
|
|
|
|
2015-10-20 11:54:45 +02:00
|
|
|
case X86_VENDOR_AMD:
|
2017-10-12 13:23:16 +02:00
|
|
|
if (x86_family(cpuid_1_eax) < 0x10)
|
|
|
|
|
return;
|
|
|
|
|
intel = false;
|
2015-10-20 11:54:45 +02:00
|
|
|
break;
|
2017-10-12 13:23:16 +02:00
|
|
|
|
2015-10-20 11:54:45 +02:00
|
|
|
default:
|
2017-10-12 13:23:16 +02:00
|
|
|
return;
|
2015-10-20 11:54:45 +02:00
|
|
|
}
|
2017-10-12 13:23:16 +02:00
|
|
|
|
|
|
|
|
if (check_loader_disabled_bsp())
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (intel)
|
2023-11-15 22:02:12 +01:00
|
|
|
load_ucode_intel_bsp(&early_data);
|
2017-10-12 13:23:16 +02:00
|
|
|
else
|
2023-11-15 22:02:12 +01:00
|
|
|
load_ucode_amd_bsp(&early_data, cpuid_1_eax);
|
2015-10-20 11:54:45 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void load_ucode_ap(void)
|
|
|
|
|
{
|
2017-01-20 21:29:50 +01:00
|
|
|
unsigned int cpuid_1_eax;
|
2015-10-20 11:54:45 +02:00
|
|
|
|
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
|
|
|
if (dis_ucode_ldr)
|
2015-10-20 11:54:45 +02:00
|
|
|
return;
|
|
|
|
|
|
2017-01-20 21:29:47 +01:00
|
|
|
cpuid_1_eax = native_cpuid_eax(1);
|
2015-10-20 11:54:45 +02:00
|
|
|
|
2017-01-20 21:29:50 +01:00
|
|
|
switch (x86_cpuid_vendor()) {
|
2015-10-20 11:54:45 +02:00
|
|
|
case X86_VENDOR_INTEL:
|
2017-01-20 21:29:47 +01:00
|
|
|
if (x86_family(cpuid_1_eax) >= 6)
|
2015-10-20 11:54:45 +02:00
|
|
|
load_ucode_intel_ap();
|
|
|
|
|
break;
|
|
|
|
|
case X86_VENDOR_AMD:
|
2017-01-20 21:29:47 +01:00
|
|
|
if (x86_family(cpuid_1_eax) >= 0x10)
|
2023-10-17 23:23:55 +02:00
|
|
|
load_ucode_amd_ap(cpuid_1_eax);
|
2015-10-20 11:54:45 +02:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-17 23:23:56 +02:00
|
|
|
struct cpio_data __init find_microcode_in_initrd(const char *path)
|
2016-10-25 11:55:21 +02:00
|
|
|
{
|
|
|
|
|
#ifdef CONFIG_BLK_DEV_INITRD
|
|
|
|
|
unsigned long start = 0;
|
|
|
|
|
size_t size;
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_32
|
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
|
|
|
size = boot_params.hdr.ramdisk_size;
|
|
|
|
|
/* Early load on BSP has a temporary mapping. */
|
2016-10-25 11:55:21 +02:00
|
|
|
if (size)
|
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
|
|
|
start = initrd_start_early;
|
2016-10-25 11:55:21 +02:00
|
|
|
|
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
|
|
|
#else /* CONFIG_X86_64 */
|
2016-10-25 11:55:21 +02:00
|
|
|
size = (unsigned long)boot_params.ext_ramdisk_size << 32;
|
|
|
|
|
size |= boot_params.hdr.ramdisk_size;
|
|
|
|
|
|
|
|
|
|
if (size) {
|
|
|
|
|
start = (unsigned long)boot_params.ext_ramdisk_image << 32;
|
|
|
|
|
start |= boot_params.hdr.ramdisk_image;
|
|
|
|
|
start += PAGE_OFFSET;
|
|
|
|
|
}
|
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
|
|
|
#endif
|
2016-10-25 11:55:21 +02:00
|
|
|
|
|
|
|
|
/*
|
2016-12-20 11:54:30 +01:00
|
|
|
* Fixup the start address: after reserve_initrd() runs, initrd_start
|
|
|
|
|
* has the virtual address of the beginning of the initrd. It also
|
|
|
|
|
* possibly relocates the ramdisk. In either case, initrd_start contains
|
|
|
|
|
* the updated address so use that instead.
|
2016-10-25 11:55:21 +02:00
|
|
|
*/
|
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
|
|
|
if (initrd_start)
|
|
|
|
|
start = initrd_start;
|
2016-10-25 11:55:21 +02:00
|
|
|
|
|
|
|
|
return find_cpio_data(path, (void *)start, size, NULL);
|
|
|
|
|
#else /* !CONFIG_BLK_DEV_INITRD */
|
|
|
|
|
return (struct cpio_data){ NULL, 0, "" };
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-12 21:58:44 +02:00
|
|
|
static void reload_early_microcode(unsigned int cpu)
|
2015-10-20 11:54:45 +02:00
|
|
|
{
|
|
|
|
|
int vendor, family;
|
|
|
|
|
|
2015-11-23 11:12:21 +01:00
|
|
|
vendor = x86_cpuid_vendor();
|
|
|
|
|
family = x86_cpuid_family();
|
2015-10-20 11:54:45 +02:00
|
|
|
|
|
|
|
|
switch (vendor) {
|
|
|
|
|
case X86_VENDOR_INTEL:
|
|
|
|
|
if (family >= 6)
|
|
|
|
|
reload_ucode_intel();
|
|
|
|
|
break;
|
|
|
|
|
case X86_VENDOR_AMD:
|
|
|
|
|
if (family >= 0x10)
|
2023-01-26 00:08:03 +01:00
|
|
|
reload_ucode_amd(cpu);
|
2015-10-20 11:54:45 +02:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2008-07-28 18:44:17 +02:00
|
|
|
/* fake device for request_firmware */
|
2009-03-11 11:19:46 +01:00
|
|
|
static struct platform_device *microcode_pdev;
|
2008-07-28 18:44:17 +02:00
|
|
|
|
2022-05-25 18:12:30 +02:00
|
|
|
#ifdef CONFIG_MICROCODE_LATE_LOADING
|
2018-02-28 11:28:46 +01:00
|
|
|
/*
|
|
|
|
|
* Late loading dance. Why the heavy-handed stomp_machine effort?
|
|
|
|
|
*
|
|
|
|
|
* - HT siblings must be idle and not execute other code while the other sibling
|
|
|
|
|
* is loading microcode in order to avoid any negative interactions caused by
|
|
|
|
|
* the loading.
|
|
|
|
|
*
|
|
|
|
|
* - In addition, microcode update on the cores must be serialized until this
|
|
|
|
|
* requirement can be relaxed in the future. Right now, this is conservative
|
|
|
|
|
* and good.
|
|
|
|
|
*/
|
2023-10-02 14:00:01 +02:00
|
|
|
enum sibling_ctrl {
|
|
|
|
|
/* Spinwait with timeout */
|
|
|
|
|
SCTRL_WAIT,
|
|
|
|
|
/* Invoke the microcode_apply() callback */
|
|
|
|
|
SCTRL_APPLY,
|
|
|
|
|
/* Proceed without invoking the microcode_apply() callback */
|
|
|
|
|
SCTRL_DONE,
|
|
|
|
|
};
|
|
|
|
|
|
2023-10-17 23:24:05 +02:00
|
|
|
struct microcode_ctrl {
|
2023-10-02 14:00:01 +02:00
|
|
|
enum sibling_ctrl ctrl;
|
2023-10-17 23:24:05 +02:00
|
|
|
enum ucode_state result;
|
2023-10-02 14:00:01 +02:00
|
|
|
unsigned int ctrl_cpu;
|
2023-10-02 14:00:05 +02:00
|
|
|
bool nmi_enabled;
|
2023-10-17 23:24:05 +02:00
|
|
|
};
|
|
|
|
|
|
2023-10-02 14:00:05 +02:00
|
|
|
DEFINE_STATIC_KEY_FALSE(microcode_nmi_handler_enable);
|
2023-10-17 23:24:05 +02:00
|
|
|
static DEFINE_PER_CPU(struct microcode_ctrl, ucode_ctrl);
|
2023-10-02 14:00:08 +02:00
|
|
|
static atomic_t late_cpus_in, offline_in_nmi;
|
2023-10-02 14:00:06 +02:00
|
|
|
static unsigned int loops_per_usec;
|
2023-10-02 14:00:08 +02:00
|
|
|
static cpumask_t cpu_offline_mask;
|
2018-02-28 11:28:46 +01:00
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
static noinstr bool wait_for_cpus(atomic_t *cnt)
|
2018-03-14 19:36:15 +01:00
|
|
|
{
|
2023-10-02 14:00:06 +02:00
|
|
|
unsigned int timeout, loops;
|
2018-03-14 19:36:15 +01:00
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
WARN_ON_ONCE(raw_atomic_dec_return(cnt) < 0);
|
2018-03-14 19:36:15 +01:00
|
|
|
|
2023-10-02 13:59:59 +02:00
|
|
|
for (timeout = 0; timeout < USEC_PER_SEC; timeout++) {
|
2023-10-02 14:00:06 +02:00
|
|
|
if (!raw_atomic_read(cnt))
|
2023-10-02 13:59:59 +02:00
|
|
|
return true;
|
2018-03-14 19:36:15 +01:00
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
for (loops = 0; loops < loops_per_usec; loops++)
|
|
|
|
|
cpu_relax();
|
2018-03-14 19:36:15 +01:00
|
|
|
|
2023-10-02 14:00:05 +02:00
|
|
|
/* If invoked directly, tickle the NMI watchdog */
|
2023-10-02 14:00:06 +02:00
|
|
|
if (!microcode_ops->use_nmi && !(timeout % USEC_PER_MSEC)) {
|
|
|
|
|
instrumentation_begin();
|
2023-10-02 13:59:59 +02:00
|
|
|
touch_nmi_watchdog();
|
2023-10-02 14:00:06 +02:00
|
|
|
instrumentation_end();
|
|
|
|
|
}
|
2018-03-14 19:36:15 +01:00
|
|
|
}
|
2023-10-02 13:59:59 +02:00
|
|
|
/* Prevent the late comers from making progress and let them time out */
|
2023-10-02 14:00:06 +02:00
|
|
|
raw_atomic_inc(cnt);
|
2023-10-02 13:59:59 +02:00
|
|
|
return false;
|
2018-03-14 19:36:15 +01:00
|
|
|
}
|
2018-02-28 11:28:46 +01:00
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
static noinstr bool wait_for_ctrl(void)
|
2023-10-02 14:00:02 +02:00
|
|
|
{
|
2023-10-02 14:00:06 +02:00
|
|
|
unsigned int timeout, loops;
|
2023-10-02 14:00:02 +02:00
|
|
|
|
|
|
|
|
for (timeout = 0; timeout < USEC_PER_SEC; timeout++) {
|
2023-10-02 14:00:06 +02:00
|
|
|
if (raw_cpu_read(ucode_ctrl.ctrl) != SCTRL_WAIT)
|
2023-10-02 14:00:02 +02:00
|
|
|
return true;
|
2023-10-02 14:00:06 +02:00
|
|
|
|
|
|
|
|
for (loops = 0; loops < loops_per_usec; loops++)
|
|
|
|
|
cpu_relax();
|
|
|
|
|
|
2023-10-02 14:00:05 +02:00
|
|
|
/* If invoked directly, tickle the NMI watchdog */
|
2023-10-02 14:00:06 +02:00
|
|
|
if (!microcode_ops->use_nmi && !(timeout % USEC_PER_MSEC)) {
|
|
|
|
|
instrumentation_begin();
|
2023-10-02 14:00:02 +02:00
|
|
|
touch_nmi_watchdog();
|
2023-10-02 14:00:06 +02:00
|
|
|
instrumentation_end();
|
|
|
|
|
}
|
2023-10-02 14:00:02 +02:00
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
/*
|
|
|
|
|
* Protected against instrumentation up to the point where the primary
|
|
|
|
|
* thread completed the update. See microcode_nmi_handler() for details.
|
|
|
|
|
*/
|
|
|
|
|
static noinstr bool load_secondary_wait(unsigned int ctrl_cpu)
|
2023-10-02 14:00:02 +02:00
|
|
|
{
|
|
|
|
|
/* Initial rendezvous to ensure that all CPUs have arrived */
|
|
|
|
|
if (!wait_for_cpus(&late_cpus_in)) {
|
2023-10-02 14:00:06 +02:00
|
|
|
raw_cpu_write(ucode_ctrl.result, UCODE_TIMEOUT);
|
|
|
|
|
return false;
|
2023-10-02 14:00:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Wait for primary threads to complete. If one of them hangs due
|
|
|
|
|
* to the update, there is no way out. This is non-recoverable
|
|
|
|
|
* because the CPU might hold locks or resources and confuse the
|
|
|
|
|
* scheduler, watchdogs etc. There is no way to safely evacuate the
|
|
|
|
|
* machine.
|
|
|
|
|
*/
|
2023-10-02 14:00:06 +02:00
|
|
|
if (wait_for_ctrl())
|
|
|
|
|
return true;
|
2023-10-02 14:00:02 +02:00
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
instrumentation_begin();
|
|
|
|
|
panic("Microcode load: Primary CPU %d timed out\n", ctrl_cpu);
|
|
|
|
|
instrumentation_end();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Protected against instrumentation up to the point where the primary
|
|
|
|
|
* thread completed the update. See microcode_nmi_handler() for details.
|
|
|
|
|
*/
|
|
|
|
|
static noinstr void load_secondary(unsigned int cpu)
|
|
|
|
|
{
|
|
|
|
|
unsigned int ctrl_cpu = raw_cpu_read(ucode_ctrl.ctrl_cpu);
|
|
|
|
|
enum ucode_state ret;
|
|
|
|
|
|
|
|
|
|
if (!load_secondary_wait(ctrl_cpu)) {
|
|
|
|
|
instrumentation_begin();
|
|
|
|
|
pr_err_once("load: %d CPUs timed out\n",
|
|
|
|
|
atomic_read(&late_cpus_in) - 1);
|
|
|
|
|
instrumentation_end();
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Primary thread completed. Allow to invoke instrumentable code */
|
|
|
|
|
instrumentation_begin();
|
2023-10-02 14:00:02 +02:00
|
|
|
/*
|
|
|
|
|
* If the primary succeeded then invoke the apply() callback,
|
|
|
|
|
* otherwise copy the state from the primary thread.
|
|
|
|
|
*/
|
|
|
|
|
if (this_cpu_read(ucode_ctrl.ctrl) == SCTRL_APPLY)
|
|
|
|
|
ret = microcode_ops->apply_microcode(cpu);
|
|
|
|
|
else
|
|
|
|
|
ret = per_cpu(ucode_ctrl.result, ctrl_cpu);
|
|
|
|
|
|
|
|
|
|
this_cpu_write(ucode_ctrl.result, ret);
|
|
|
|
|
this_cpu_write(ucode_ctrl.ctrl, SCTRL_DONE);
|
2023-10-02 14:00:06 +02:00
|
|
|
instrumentation_end();
|
2023-10-02 14:00:02 +02:00
|
|
|
}
|
|
|
|
|
|
2023-10-02 14:00:08 +02:00
|
|
|
static void __load_primary(unsigned int cpu)
|
2023-10-02 14:00:02 +02:00
|
|
|
{
|
|
|
|
|
struct cpumask *secondaries = topology_sibling_cpumask(cpu);
|
|
|
|
|
enum sibling_ctrl ctrl;
|
|
|
|
|
enum ucode_state ret;
|
|
|
|
|
unsigned int sibling;
|
|
|
|
|
|
|
|
|
|
/* Initial rendezvous to ensure that all CPUs have arrived */
|
|
|
|
|
if (!wait_for_cpus(&late_cpus_in)) {
|
|
|
|
|
this_cpu_write(ucode_ctrl.result, UCODE_TIMEOUT);
|
|
|
|
|
pr_err_once("load: %d CPUs timed out\n", atomic_read(&late_cpus_in) - 1);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret = microcode_ops->apply_microcode(cpu);
|
|
|
|
|
this_cpu_write(ucode_ctrl.result, ret);
|
|
|
|
|
this_cpu_write(ucode_ctrl.ctrl, SCTRL_DONE);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the update was successful, let the siblings run the apply()
|
|
|
|
|
* callback. If not, tell them it's done. This also covers the
|
|
|
|
|
* case where the CPU has uniform loading at package or system
|
|
|
|
|
* scope implemented but does not advertise it.
|
|
|
|
|
*/
|
|
|
|
|
if (ret == UCODE_UPDATED || ret == UCODE_OK)
|
|
|
|
|
ctrl = SCTRL_APPLY;
|
|
|
|
|
else
|
|
|
|
|
ctrl = SCTRL_DONE;
|
|
|
|
|
|
|
|
|
|
for_each_cpu(sibling, secondaries) {
|
|
|
|
|
if (sibling != cpu)
|
|
|
|
|
per_cpu(ucode_ctrl.ctrl, sibling) = ctrl;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-02 14:00:08 +02:00
|
|
|
static bool kick_offline_cpus(unsigned int nr_offl)
|
|
|
|
|
{
|
|
|
|
|
unsigned int cpu, timeout;
|
|
|
|
|
|
|
|
|
|
for_each_cpu(cpu, &cpu_offline_mask) {
|
|
|
|
|
/* Enable the rendezvous handler and send NMI */
|
|
|
|
|
per_cpu(ucode_ctrl.nmi_enabled, cpu) = true;
|
|
|
|
|
apic_send_nmi_to_offline_cpu(cpu);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Wait for them to arrive */
|
|
|
|
|
for (timeout = 0; timeout < (USEC_PER_SEC / 2); timeout++) {
|
|
|
|
|
if (atomic_read(&offline_in_nmi) == nr_offl)
|
|
|
|
|
return true;
|
|
|
|
|
udelay(1);
|
|
|
|
|
}
|
|
|
|
|
/* Let the others time out */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void release_offline_cpus(void)
|
|
|
|
|
{
|
|
|
|
|
unsigned int cpu;
|
|
|
|
|
|
|
|
|
|
for_each_cpu(cpu, &cpu_offline_mask)
|
|
|
|
|
per_cpu(ucode_ctrl.ctrl, cpu) = SCTRL_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void load_primary(unsigned int cpu)
|
|
|
|
|
{
|
|
|
|
|
unsigned int nr_offl = cpumask_weight(&cpu_offline_mask);
|
|
|
|
|
bool proceed = true;
|
|
|
|
|
|
|
|
|
|
/* Kick soft-offlined SMT siblings if required */
|
|
|
|
|
if (!cpu && nr_offl)
|
|
|
|
|
proceed = kick_offline_cpus(nr_offl);
|
|
|
|
|
|
|
|
|
|
/* If the soft-offlined CPUs did not respond, abort */
|
|
|
|
|
if (proceed)
|
|
|
|
|
__load_primary(cpu);
|
|
|
|
|
|
|
|
|
|
/* Unconditionally release soft-offlined SMT siblings if required */
|
|
|
|
|
if (!cpu && nr_offl)
|
|
|
|
|
release_offline_cpus();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Minimal stub rendezvous handler for soft-offlined CPUs which participate
|
|
|
|
|
* in the NMI rendezvous to protect against a concurrent NMI on affected
|
|
|
|
|
* CPUs.
|
|
|
|
|
*/
|
|
|
|
|
void noinstr microcode_offline_nmi_handler(void)
|
|
|
|
|
{
|
|
|
|
|
if (!raw_cpu_read(ucode_ctrl.nmi_enabled))
|
|
|
|
|
return;
|
|
|
|
|
raw_cpu_write(ucode_ctrl.nmi_enabled, false);
|
|
|
|
|
raw_cpu_write(ucode_ctrl.result, UCODE_OFFLINE);
|
|
|
|
|
raw_atomic_inc(&offline_in_nmi);
|
|
|
|
|
wait_for_ctrl();
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
static noinstr bool microcode_update_handler(void)
|
2009-03-11 16:32:36 +10:30
|
|
|
{
|
2023-10-02 14:00:06 +02:00
|
|
|
unsigned int cpu = raw_smp_processor_id();
|
2009-03-11 16:32:36 +10:30
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
if (raw_cpu_read(ucode_ctrl.ctrl_cpu) == cpu) {
|
|
|
|
|
instrumentation_begin();
|
2023-10-02 14:00:03 +02:00
|
|
|
load_primary(cpu);
|
2023-10-02 14:00:06 +02:00
|
|
|
instrumentation_end();
|
|
|
|
|
} else {
|
2023-10-02 14:00:03 +02:00
|
|
|
load_secondary(cpu);
|
2023-10-02 14:00:06 +02:00
|
|
|
}
|
2018-02-28 11:28:46 +01:00
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
instrumentation_begin();
|
2023-10-02 14:00:05 +02:00
|
|
|
touch_nmi_watchdog();
|
2023-10-02 14:00:06 +02:00
|
|
|
instrumentation_end();
|
|
|
|
|
|
2023-10-02 14:00:05 +02:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
/*
|
|
|
|
|
* Protection against instrumentation is required for CPUs which are not
|
|
|
|
|
* safe against an NMI which is delivered to the secondary SMT sibling
|
|
|
|
|
* while the primary thread updates the microcode. Instrumentation can end
|
|
|
|
|
* up in #INT3, #DB and #PF. The IRET from those exceptions reenables NMI
|
|
|
|
|
* which is the opposite of what the NMI rendezvous is trying to achieve.
|
|
|
|
|
*
|
|
|
|
|
* The primary thread is safe versus instrumentation as the actual
|
|
|
|
|
* microcode update handles this correctly. It's only the sibling code
|
|
|
|
|
* path which must be NMI safe until the primary thread completed the
|
|
|
|
|
* update.
|
|
|
|
|
*/
|
|
|
|
|
bool noinstr microcode_nmi_handler(void)
|
2023-10-02 14:00:05 +02:00
|
|
|
{
|
2023-10-02 14:00:06 +02:00
|
|
|
if (!raw_cpu_read(ucode_ctrl.nmi_enabled))
|
2023-10-02 14:00:05 +02:00
|
|
|
return false;
|
|
|
|
|
|
2023-10-02 14:00:06 +02:00
|
|
|
raw_cpu_write(ucode_ctrl.nmi_enabled, false);
|
2023-10-02 14:00:05 +02:00
|
|
|
return microcode_update_handler();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int load_cpus_stopped(void *unused)
|
|
|
|
|
{
|
|
|
|
|
if (microcode_ops->use_nmi) {
|
|
|
|
|
/* Enable the NMI handler and raise NMI */
|
|
|
|
|
this_cpu_write(ucode_ctrl.nmi_enabled, true);
|
|
|
|
|
apic->send_IPI(smp_processor_id(), NMI_VECTOR);
|
|
|
|
|
} else {
|
|
|
|
|
/* Just invoke the handler directly */
|
|
|
|
|
microcode_update_handler();
|
|
|
|
|
}
|
2023-10-17 23:24:05 +02:00
|
|
|
return 0;
|
2018-02-28 11:28:46 +01:00
|
|
|
}
|
|
|
|
|
|
2023-10-17 23:24:16 +02:00
|
|
|
static int load_late_stop_cpus(bool is_safe)
|
2018-02-28 11:28:46 +01:00
|
|
|
{
|
2023-10-17 23:24:05 +02:00
|
|
|
unsigned int cpu, updated = 0, failed = 0, timedout = 0, siblings = 0;
|
2023-10-02 14:00:08 +02:00
|
|
|
unsigned int nr_offl, offline = 0;
|
2023-10-17 23:24:05 +02:00
|
|
|
int old_rev = boot_cpu_data.microcode;
|
2023-01-09 07:35:50 -08:00
|
|
|
struct cpuinfo_x86 prev_info;
|
2018-02-28 11:28:46 +01:00
|
|
|
|
2023-10-17 23:24:16 +02:00
|
|
|
if (!is_safe) {
|
|
|
|
|
pr_err("Late microcode loading without minimal revision check.\n");
|
|
|
|
|
pr_err("You should switch to early loading, if possible.\n");
|
|
|
|
|
}
|
2022-05-25 18:12:31 +02:00
|
|
|
|
2023-10-02 13:59:59 +02:00
|
|
|
atomic_set(&late_cpus_in, num_online_cpus());
|
2023-10-02 14:00:08 +02:00
|
|
|
atomic_set(&offline_in_nmi, 0);
|
2023-10-02 14:00:06 +02:00
|
|
|
loops_per_usec = loops_per_jiffy / (TICK_NSEC / 1000);
|
2018-02-28 11:28:46 +01:00
|
|
|
|
2023-01-09 07:35:51 -08:00
|
|
|
/*
|
|
|
|
|
* Take a snapshot before the microcode update in order to compare and
|
|
|
|
|
* check whether any bits changed after an update.
|
|
|
|
|
*/
|
|
|
|
|
store_cpu_caps(&prev_info);
|
|
|
|
|
|
2023-10-02 14:00:05 +02:00
|
|
|
if (microcode_ops->use_nmi)
|
|
|
|
|
static_branch_enable_cpuslocked(µcode_nmi_handler_enable);
|
|
|
|
|
|
2023-10-17 23:24:05 +02:00
|
|
|
stop_machine_cpuslocked(load_cpus_stopped, NULL, cpu_online_mask);
|
|
|
|
|
|
2023-10-02 14:00:05 +02:00
|
|
|
if (microcode_ops->use_nmi)
|
|
|
|
|
static_branch_disable_cpuslocked(µcode_nmi_handler_enable);
|
|
|
|
|
|
2023-10-17 23:24:05 +02:00
|
|
|
/* Analyze the results */
|
|
|
|
|
for_each_cpu_and(cpu, cpu_present_mask, &cpus_booted_once_mask) {
|
|
|
|
|
switch (per_cpu(ucode_ctrl.result, cpu)) {
|
|
|
|
|
case UCODE_UPDATED: updated++; break;
|
|
|
|
|
case UCODE_TIMEOUT: timedout++; break;
|
|
|
|
|
case UCODE_OK: siblings++; break;
|
2023-10-02 14:00:08 +02:00
|
|
|
case UCODE_OFFLINE: offline++; break;
|
2023-10-17 23:24:05 +02:00
|
|
|
default: failed++; break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2023-10-02 13:59:44 +02:00
|
|
|
|
|
|
|
|
if (microcode_ops->finalize_late_load)
|
2023-10-17 23:24:05 +02:00
|
|
|
microcode_ops->finalize_late_load(!updated);
|
2023-10-02 13:59:44 +02:00
|
|
|
|
2023-10-17 23:24:05 +02:00
|
|
|
if (!updated) {
|
|
|
|
|
/* Nothing changed. */
|
|
|
|
|
if (!failed && !timedout)
|
|
|
|
|
return 0;
|
2023-10-02 14:00:08 +02:00
|
|
|
|
|
|
|
|
nr_offl = cpumask_weight(&cpu_offline_mask);
|
|
|
|
|
if (offline < nr_offl) {
|
|
|
|
|
pr_warn("%u offline siblings did not respond.\n",
|
|
|
|
|
nr_offl - atomic_read(&offline_in_nmi));
|
|
|
|
|
return -EIO;
|
|
|
|
|
}
|
2023-10-17 23:24:05 +02:00
|
|
|
pr_err("update failed: %u CPUs failed %u CPUs timed out\n",
|
|
|
|
|
failed, timedout);
|
|
|
|
|
return -EIO;
|
2023-01-09 07:35:52 -08:00
|
|
|
}
|
2023-10-17 23:24:05 +02:00
|
|
|
|
2023-10-17 23:24:16 +02:00
|
|
|
if (!is_safe || failed || timedout)
|
|
|
|
|
add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
|
|
|
|
|
|
2023-10-17 23:24:05 +02:00
|
|
|
pr_info("load: updated on %u primary CPUs with %u siblings\n", updated, siblings);
|
|
|
|
|
if (failed || timedout) {
|
|
|
|
|
pr_err("load incomplete. %u CPUs timed out or failed\n",
|
|
|
|
|
num_online_cpus() - (updated + siblings));
|
|
|
|
|
}
|
|
|
|
|
pr_info("revision: 0x%x -> 0x%x\n", old_rev, boot_cpu_data.microcode);
|
|
|
|
|
microcode_check(&prev_info);
|
|
|
|
|
|
|
|
|
|
return updated + siblings == num_online_cpus() ? 0 : -EIO;
|
2009-03-11 16:32:36 +10:30
|
|
|
}
|
|
|
|
|
|
2023-10-02 13:59:56 +02:00
|
|
|
/*
|
2023-10-17 23:24:05 +02:00
|
|
|
* This function does two things:
|
|
|
|
|
*
|
|
|
|
|
* 1) Ensure that all required CPUs which are present and have been booted
|
|
|
|
|
* once are online.
|
2023-10-02 13:59:56 +02:00
|
|
|
*
|
|
|
|
|
* To pass this check, all primary threads must be online.
|
|
|
|
|
*
|
|
|
|
|
* If the microcode load is not safe against NMI then all SMT threads
|
|
|
|
|
* must be online as well because they still react to NMIs when they are
|
|
|
|
|
* soft-offlined and parked in one of the play_dead() variants. So if a
|
|
|
|
|
* NMI hits while the primary thread updates the microcode the resulting
|
|
|
|
|
* behaviour is undefined. The default play_dead() implementation on
|
|
|
|
|
* modern CPUs uses MWAIT, which is also not guaranteed to be safe
|
|
|
|
|
* against a microcode update which affects MWAIT.
|
2023-10-17 23:24:05 +02:00
|
|
|
*
|
2023-10-02 14:00:08 +02:00
|
|
|
* As soft-offlined CPUs still react on NMIs, the SMT sibling
|
|
|
|
|
* restriction can be lifted when the vendor driver signals to use NMI
|
|
|
|
|
* for rendezvous and the APIC provides a mechanism to send an NMI to a
|
|
|
|
|
* soft-offlined CPU. The soft-offlined CPUs are then able to
|
|
|
|
|
* participate in the rendezvous in a trivial stub handler.
|
|
|
|
|
*
|
|
|
|
|
* 2) Initialize the per CPU control structure and create a cpumask
|
|
|
|
|
* which contains "offline"; secondary threads, so they can be handled
|
|
|
|
|
* correctly by a control CPU.
|
2023-10-02 13:59:56 +02:00
|
|
|
*/
|
2023-10-17 23:24:05 +02:00
|
|
|
static bool setup_cpus(void)
|
2023-10-02 13:59:56 +02:00
|
|
|
{
|
2023-10-02 14:00:01 +02:00
|
|
|
struct microcode_ctrl ctrl = { .ctrl = SCTRL_WAIT, .result = -1, };
|
2023-10-02 14:00:08 +02:00
|
|
|
bool allow_smt_offline;
|
2023-10-02 13:59:56 +02:00
|
|
|
unsigned int cpu;
|
|
|
|
|
|
2023-10-02 14:00:08 +02:00
|
|
|
allow_smt_offline = microcode_ops->nmi_safe ||
|
|
|
|
|
(microcode_ops->use_nmi && apic->nmi_to_offline_cpu);
|
|
|
|
|
|
|
|
|
|
cpumask_clear(&cpu_offline_mask);
|
|
|
|
|
|
2023-10-02 13:59:56 +02:00
|
|
|
for_each_cpu_and(cpu, cpu_present_mask, &cpus_booted_once_mask) {
|
2023-10-02 14:00:08 +02:00
|
|
|
/*
|
|
|
|
|
* Offline CPUs sit in one of the play_dead() functions
|
|
|
|
|
* with interrupts disabled, but they still react on NMIs
|
|
|
|
|
* and execute arbitrary code. Also MWAIT being updated
|
|
|
|
|
* while the offline CPU sits there is not necessarily safe
|
|
|
|
|
* on all CPU variants.
|
|
|
|
|
*
|
|
|
|
|
* Mark them in the offline_cpus mask which will be handled
|
|
|
|
|
* by CPU0 later in the update process.
|
|
|
|
|
*
|
|
|
|
|
* Ensure that the primary thread is online so that it is
|
|
|
|
|
* guaranteed that all cores are updated.
|
|
|
|
|
*/
|
2023-10-02 13:59:56 +02:00
|
|
|
if (!cpu_online(cpu)) {
|
2023-10-02 14:00:08 +02:00
|
|
|
if (topology_is_primary_thread(cpu) || !allow_smt_offline) {
|
|
|
|
|
pr_err("CPU %u not online, loading aborted\n", cpu);
|
2023-10-02 13:59:56 +02:00
|
|
|
return false;
|
|
|
|
|
}
|
2023-10-02 14:00:08 +02:00
|
|
|
cpumask_set_cpu(cpu, &cpu_offline_mask);
|
|
|
|
|
per_cpu(ucode_ctrl, cpu) = ctrl;
|
|
|
|
|
continue;
|
2023-10-02 13:59:56 +02:00
|
|
|
}
|
2023-10-02 14:00:01 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Initialize the per CPU state. This is core scope for now,
|
|
|
|
|
* but prepared to take package or system scope into account.
|
|
|
|
|
*/
|
|
|
|
|
ctrl.ctrl_cpu = cpumask_first(topology_sibling_cpumask(cpu));
|
2023-10-17 23:24:05 +02:00
|
|
|
per_cpu(ucode_ctrl, cpu) = ctrl;
|
2023-10-02 13:59:56 +02:00
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-17 23:24:05 +02:00
|
|
|
static int load_late_locked(void)
|
2023-10-02 13:59:57 +02:00
|
|
|
{
|
2023-10-17 23:24:05 +02:00
|
|
|
if (!setup_cpus())
|
2023-10-02 13:59:57 +02:00
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
|
|
switch (microcode_ops->request_microcode_fw(0, µcode_pdev->dev)) {
|
|
|
|
|
case UCODE_NEW:
|
2023-10-17 23:24:16 +02:00
|
|
|
return load_late_stop_cpus(false);
|
|
|
|
|
case UCODE_NEW_SAFE:
|
|
|
|
|
return load_late_stop_cpus(true);
|
2023-10-02 13:59:57 +02:00
|
|
|
case UCODE_NFOUND:
|
|
|
|
|
return -ENOENT;
|
|
|
|
|
default:
|
|
|
|
|
return -EBADFD;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-12-21 14:29:42 -08:00
|
|
|
static ssize_t reload_store(struct device *dev,
|
|
|
|
|
struct device_attribute *attr,
|
2009-05-11 23:48:27 +02:00
|
|
|
const char *buf, size_t size)
|
2008-07-28 18:44:17 +02:00
|
|
|
{
|
2009-05-11 23:48:27 +02:00
|
|
|
unsigned long val;
|
2023-10-02 13:59:57 +02:00
|
|
|
ssize_t ret;
|
2012-06-21 14:07:16 +02:00
|
|
|
|
2012-05-06 11:11:04 -06:00
|
|
|
ret = kstrtoul(buf, 0, &val);
|
2023-01-30 13:39:48 -08:00
|
|
|
if (ret || val != 1)
|
|
|
|
|
return -EINVAL;
|
2012-06-21 14:07:16 +02:00
|
|
|
|
2021-08-03 16:15:51 +02:00
|
|
|
cpus_read_lock();
|
2023-10-17 23:24:05 +02:00
|
|
|
ret = load_late_locked();
|
2021-08-03 16:15:51 +02:00
|
|
|
cpus_read_unlock();
|
2009-05-11 23:48:27 +02:00
|
|
|
|
2023-10-02 13:59:57 +02:00
|
|
|
return ret ? : size;
|
2008-07-28 18:44:17 +02:00
|
|
|
}
|
|
|
|
|
|
2022-05-25 18:12:30 +02:00
|
|
|
static DEVICE_ATTR_WO(reload);
|
|
|
|
|
#endif
|
|
|
|
|
|
2011-12-21 14:29:42 -08:00
|
|
|
static ssize_t version_show(struct device *dev,
|
|
|
|
|
struct device_attribute *attr, char *buf)
|
2008-07-28 18:44:17 +02:00
|
|
|
{
|
|
|
|
|
struct ucode_cpu_info *uci = ucode_cpu_info + dev->id;
|
|
|
|
|
|
2008-08-20 00:22:26 +02:00
|
|
|
return sprintf(buf, "0x%x\n", uci->cpu_sig.rev);
|
2008-07-28 18:44:17 +02:00
|
|
|
}
|
|
|
|
|
|
2023-01-18 10:35:54 +08:00
|
|
|
static ssize_t processor_flags_show(struct device *dev,
|
2011-12-21 14:29:42 -08:00
|
|
|
struct device_attribute *attr, char *buf)
|
2008-07-28 18:44:17 +02:00
|
|
|
{
|
|
|
|
|
struct ucode_cpu_info *uci = ucode_cpu_info + dev->id;
|
|
|
|
|
|
2008-08-20 00:22:26 +02:00
|
|
|
return sprintf(buf, "0x%x\n", uci->cpu_sig.pf);
|
2008-07-28 18:44:17 +02:00
|
|
|
}
|
|
|
|
|
|
2023-01-18 10:35:54 +08:00
|
|
|
static DEVICE_ATTR_RO(version);
|
|
|
|
|
static DEVICE_ATTR_RO(processor_flags);
|
2008-07-28 18:44:17 +02:00
|
|
|
|
|
|
|
|
static struct attribute *mc_default_attrs[] = {
|
2011-12-21 14:29:42 -08:00
|
|
|
&dev_attr_version.attr,
|
|
|
|
|
&dev_attr_processor_flags.attr,
|
2008-07-28 18:44:17 +02:00
|
|
|
NULL
|
|
|
|
|
};
|
|
|
|
|
|
2017-07-20 17:00:32 +05:30
|
|
|
static const struct attribute_group mc_attr_group = {
|
2009-05-11 23:48:27 +02:00
|
|
|
.attrs = mc_default_attrs,
|
|
|
|
|
.name = "microcode",
|
2008-07-28 18:44:17 +02:00
|
|
|
};
|
|
|
|
|
|
2009-05-11 23:48:27 +02:00
|
|
|
static void microcode_fini_cpu(int cpu)
|
2008-08-20 00:22:26 +02:00
|
|
|
{
|
2016-10-25 11:55:21 +02:00
|
|
|
if (microcode_ops->microcode_fini_cpu)
|
|
|
|
|
microcode_ops->microcode_fini_cpu(cpu);
|
2008-12-20 00:15:24 +01:00
|
|
|
}
|
|
|
|
|
|
2011-03-23 22:15:54 +01:00
|
|
|
/**
|
2022-04-19 09:52:41 -07:00
|
|
|
* microcode_bsp_resume - Update boot CPU microcode during resume.
|
2011-03-23 22:15:54 +01:00
|
|
|
*/
|
2022-04-19 09:52:41 -07:00
|
|
|
void microcode_bsp_resume(void)
|
2011-03-23 22:15:54 +01:00
|
|
|
{
|
|
|
|
|
int cpu = smp_processor_id();
|
|
|
|
|
struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
|
|
|
|
|
|
2022-10-19 19:25:27 +02:00
|
|
|
if (uci->mc)
|
2011-03-23 22:15:54 +01:00
|
|
|
microcode_ops->apply_microcode(cpu);
|
2022-10-19 19:25:27 +02:00
|
|
|
else
|
2023-01-26 00:08:03 +01:00
|
|
|
reload_early_microcode(cpu);
|
2011-03-23 22:15:54 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct syscore_ops mc_syscore_ops = {
|
2022-10-19 19:07:30 +02:00
|
|
|
.resume = microcode_bsp_resume,
|
2008-07-28 18:44:17 +02:00
|
|
|
};
|
|
|
|
|
|
2019-06-18 22:31:40 +02:00
|
|
|
static int mc_cpu_online(unsigned int cpu)
|
|
|
|
|
{
|
2023-10-17 23:23:58 +02:00
|
|
|
struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
|
2019-06-18 22:31:40 +02:00
|
|
|
struct device *dev = get_cpu_device(cpu);
|
2012-07-23 20:15:10 +02:00
|
|
|
|
2023-10-17 23:23:58 +02:00
|
|
|
memset(uci, 0, sizeof(*uci));
|
|
|
|
|
|
|
|
|
|
microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);
|
|
|
|
|
cpu_data(cpu).microcode = uci->cpu_sig.rev;
|
|
|
|
|
if (!cpu)
|
|
|
|
|
boot_cpu_data.microcode = uci->cpu_sig.rev;
|
|
|
|
|
|
2016-09-07 18:45:23 +02:00
|
|
|
if (sysfs_create_group(&dev->kobj, &mc_attr_group))
|
|
|
|
|
pr_err("Failed to create group for CPU%d\n", cpu);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2012-07-23 20:15:10 +02:00
|
|
|
|
2016-09-07 18:45:23 +02:00
|
|
|
static int mc_cpu_down_prep(unsigned int cpu)
|
|
|
|
|
{
|
2023-10-02 13:59:55 +02:00
|
|
|
struct device *dev = get_cpu_device(cpu);
|
2022-10-19 18:13:06 +02:00
|
|
|
|
|
|
|
|
microcode_fini_cpu(cpu);
|
2016-09-07 18:45:23 +02:00
|
|
|
sysfs_remove_group(&dev->kobj, &mc_attr_group);
|
|
|
|
|
return 0;
|
2008-07-28 18:44:17 +02:00
|
|
|
}
|
|
|
|
|
|
2012-06-21 14:07:17 +02:00
|
|
|
static struct attribute *cpu_root_microcode_attrs[] = {
|
2022-05-25 18:12:30 +02:00
|
|
|
#ifdef CONFIG_MICROCODE_LATE_LOADING
|
2012-06-21 14:07:17 +02:00
|
|
|
&dev_attr_reload.attr,
|
2022-05-25 18:12:30 +02:00
|
|
|
#endif
|
2012-06-21 14:07:17 +02:00
|
|
|
NULL
|
|
|
|
|
};
|
|
|
|
|
|
2017-07-20 17:00:32 +05:30
|
|
|
static const struct attribute_group cpu_root_microcode_group = {
|
2012-06-21 14:07:17 +02:00
|
|
|
.name = "microcode",
|
|
|
|
|
.attrs = cpu_root_microcode_attrs,
|
|
|
|
|
};
|
|
|
|
|
|
2020-12-30 11:20:25 +01:00
|
|
|
static int __init microcode_init(void)
|
2008-07-28 18:44:17 +02:00
|
|
|
{
|
2023-03-13 19:28:51 +01:00
|
|
|
struct device *dev_root;
|
2015-10-20 11:54:44 +02:00
|
|
|
struct cpuinfo_x86 *c = &boot_cpu_data;
|
2008-07-28 18:44:17 +02:00
|
|
|
int error;
|
|
|
|
|
|
2016-02-16 09:43:19 +01:00
|
|
|
if (dis_ucode_ldr)
|
2015-01-27 21:21:09 -05:00
|
|
|
return -EINVAL;
|
2014-05-19 20:59:17 +02:00
|
|
|
|
2008-09-23 12:08:44 +02:00
|
|
|
if (c->x86_vendor == X86_VENDOR_INTEL)
|
|
|
|
|
microcode_ops = init_intel_microcode();
|
2008-09-24 11:50:35 +02:00
|
|
|
else if (c->x86_vendor == X86_VENDOR_AMD)
|
2008-09-23 12:08:44 +02:00
|
|
|
microcode_ops = init_amd_microcode();
|
2012-04-12 16:51:57 +02:00
|
|
|
else
|
2009-12-08 22:30:50 -08:00
|
|
|
pr_err("no support for this CPU vendor\n");
|
2012-04-12 16:51:57 +02:00
|
|
|
|
|
|
|
|
if (!microcode_ops)
|
2008-09-23 12:08:44 +02:00
|
|
|
return -ENODEV;
|
2008-07-28 18:44:17 +02:00
|
|
|
|
2023-11-15 22:02:12 +01:00
|
|
|
pr_info_once("Current revision: 0x%08x\n", (early_data.new_rev ?: early_data.old_rev));
|
|
|
|
|
|
|
|
|
|
if (early_data.new_rev)
|
|
|
|
|
pr_info_once("Updated early from: 0x%08x\n", early_data.old_rev);
|
|
|
|
|
|
2022-10-19 19:20:47 +02:00
|
|
|
microcode_pdev = platform_device_register_simple("microcode", -1, NULL, 0);
|
2011-11-07 18:05:32 +05:30
|
|
|
if (IS_ERR(microcode_pdev))
|
2008-07-28 18:44:17 +02:00
|
|
|
return PTR_ERR(microcode_pdev);
|
|
|
|
|
|
2023-03-13 19:28:51 +01:00
|
|
|
dev_root = bus_get_dev_root(&cpu_subsys);
|
|
|
|
|
if (dev_root) {
|
|
|
|
|
error = sysfs_create_group(&dev_root->kobj, &cpu_root_microcode_group);
|
|
|
|
|
put_device(dev_root);
|
|
|
|
|
if (error) {
|
|
|
|
|
pr_err("Error creating microcode group!\n");
|
|
|
|
|
goto out_pdev;
|
|
|
|
|
}
|
2012-06-21 14:07:17 +02:00
|
|
|
}
|
|
|
|
|
|
2011-03-23 22:15:54 +01:00
|
|
|
register_syscore_ops(&mc_syscore_ops);
|
2023-10-17 23:23:58 +02:00
|
|
|
cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/microcode:online",
|
|
|
|
|
mc_cpu_online, mc_cpu_down_prep);
|
2008-07-28 18:44:21 +02:00
|
|
|
|
2008-07-28 18:44:17 +02:00
|
|
|
return 0;
|
2011-11-07 18:05:32 +05:30
|
|
|
|
2012-06-21 14:07:17 +02:00
|
|
|
out_pdev:
|
2011-11-07 18:05:32 +05:30
|
|
|
platform_device_unregister(microcode_pdev);
|
|
|
|
|
return error;
|
|
|
|
|
|
2008-07-28 18:44:17 +02:00
|
|
|
}
|
2015-11-20 12:24:00 +01:00
|
|
|
late_initcall(microcode_init);
|