[PATCH] x86/microcode/intel: Panic on partial microcode update

[PATCH] x86/microcode/intel: Panic on partial microcode update

[Chang S. Bae]

The MSR IA32_MCU_STATUS, if available, may report a partial update status
on a microcode update. This indicates that only a subset of microcode
components was updated successfully while other parts of updates failed,
which in turn leaves the system in an undefined and (potentially)
unreliable state.

Panic when such a fatal condition is reported, since the system can no
longer be trusted to make forward progress safely.

Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
---
This patch was once considered bundled with another feature enabling
(uniform). But it can stand on its own as a reliability improvement.

The status is possible on newer CPUs. While validation is expected to
prevent these error conditions in normal deployments, handling them
explicitly protects systems against an otherwise undefined state.

Considered refactoring the enumeration code was obvious enough to fold
into a signle patch here. Otherwise, next revision may separate it out.
---
 arch/x86/include/asm/msr-index.h      |  4 +++
 arch/x86/kernel/cpu/microcode/intel.c | 35 +++++++++++++++++++++++++--
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 18c4be75e927..7273d340470d 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -977,6 +977,10 @@
 #define MSR_IA32_MCU_ENUMERATION	0x0000007b
 #define MCU_STAGING			BIT(4)
 
+#define MSR_IA32_MCU_STATUS		0x0000007c
+#define MCU_PARTIAL_UPDATE		BIT(0)
+#define AUTH_FAIL_ON_MCU_COMPONENT	BIT(1)
+
 #define MSR_IA32_UCODE_REV		0x0000008b
 
 /* Intel SGX Launch Enclave Public Key Hash MSRs */
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index f4a444e6114d..0b474a7c6986 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -76,6 +76,9 @@ static struct microcode_intel *ucode_patch_late __read_mostly;
 /* last level cache size per core */
 static unsigned int llc_size_per_core __ro_after_init;
 
+/* CPU capability for update status and staging support */
+static bool cpu_has_mcu __ro_after_init;
+
 /* microcode format is extended from prescott processors */
 struct extended_signature {
 	unsigned int	sig;
@@ -702,6 +705,16 @@ static enum ucode_state __apply_microcode(struct ucode_cpu_info *uci,
 	/* write microcode via MSR 0x79 */
 	native_wrmsrq(MSR_IA32_UCODE_WRITE, (unsigned long)mc->bits);
 
+	/* Check if the update put the system in an unreliable state */
+	if (cpu_has_mcu) {
+		u64 status = native_rdmsrq(MSR_IA32_MCU_STATUS);
+
+		if (status & (MCU_PARTIAL_UPDATE | AUTH_FAIL_ON_MCU_COMPONENT)) {
+			pr_emerg("Partial update: MSR_IA32_MCU_STATUS=0x%llx\n", status);
+			nmi_panic(NULL, "Microcode load: fatal status from partial update");
+		}
+	}
+
 	rev = intel_get_microcode_revision();
 	if (rev != mc->hdr.rev)
 		return UCODE_ERROR;
@@ -779,11 +792,30 @@ static int __init save_builtin_microcode(void)
 }
 early_initcall(save_builtin_microcode);
 
+#define CPUID_EDX_ARCH_CAP	BIT(29)
+
+static __init bool mcu_capable(void)
+{
+	if (native_cpuid_eax(0) < 7)
+		return false;
+
+	if (!(native_cpuid_edx(7) & CPUID_EDX_ARCH_CAP))
+		return false;
+
+	if (!(native_rdmsrq(MSR_IA32_ARCH_CAPABILITIES) & ARCH_CAP_MCU_ENUM))
+		return false;
+
+	return true;
+}
+
 /* Load microcode on BSP from initrd or builtin blobs */
 void __init load_ucode_intel_bsp(struct early_load_data *ed)
 {
 	struct ucode_cpu_info uci;
 
+	/* Indicate early enough to cover the early-loading path */
+	cpu_has_mcu = mcu_capable();
+
 	uci.mc = get_microcode_blob(&uci, false);
 	ed->old_rev = uci.cpu_sig.rev;
 
@@ -1023,8 +1055,7 @@ static __init bool staging_available(void)
 {
 	u64 val;
 
-	val = x86_read_arch_cap_msr();
-	if (!(val & ARCH_CAP_MCU_ENUM))
+	if (!cpu_has_mcu)
 		return false;
 
 	rdmsrq(MSR_IA32_MCU_ENUMERATION, val);
-- 
2.51.0

Re: [PATCH] x86/microcode/intel: Panic on partial microcode update

[Dave Hansen]

On 6/30/26 12:13, Chang S. Bae wrote:
> The MSR IA32_MCU_STATUS, if available, may report a partial update status
> on a microcode update. This indicates that only a subset of microcode
> components was updated successfully while other parts of updates failed,
> which in turn leaves the system in an undefined and (potentially)
> unreliable state.

A modern individual microcode update update contains firmware for many
pieces of silicon inside the CPU. Sometimes, a single update operation
successfully updates some components and not others leaving a
partially-applied update.

This leaves the system in an undefined and unreliable state.


> The status is possible on newer CPUs. While validation is expected to
> prevent these error conditions in normal deployments, handling them
> explicitly protects systems against an otherwise undefined state.

I think that this is saying that CPUs try hard not to throw up their
hands and give up mid-update. But, the world is hard and things don't
always go to plan.

> +#define MSR_IA32_MCU_STATUS		0x0000007c
> +#define MCU_PARTIAL_UPDATE		BIT(0)
> +#define AUTH_FAIL_ON_MCU_COMPONENT	BIT(1)

Let's just make a :

#define MCU_STATUS_FAILURE_MASK		(MCU_PARTIAL_UPDATE 	     \
					 AUTH_FAIL_ON_MCU_COMPONENT)

> diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
> index f4a444e6114d..0b474a7c6986 100644
> --- a/arch/x86/kernel/cpu/microcode/intel.c
> +++ b/arch/x86/kernel/cpu/microcode/intel.c
> @@ -76,6 +76,9 @@ static struct microcode_intel *ucode_patch_late __read_mostly;
>  /* last level cache size per core */
>  static unsigned int llc_size_per_core __ro_after_init;
>  
> +/* CPU capability for update status and staging support */
> +static bool cpu_has_mcu __ro_after_init;

These are *SUCH* slow, rare paths that I'm not even sure we need to
cache this.

>  /* microcode format is extended from prescott processors */
>  struct extended_signature {
>  	unsigned int	sig;
> @@ -702,6 +705,16 @@ static enum ucode_state __apply_microcode(struct ucode_cpu_info *uci,
>  	/* write microcode via MSR 0x79 */
>  	native_wrmsrq(MSR_IA32_UCODE_WRITE, (unsigned long)mc->bits);
>  
> +	/* Check if the update put the system in an unreliable state */
> +	if (cpu_has_mcu) {
> +		u64 status = native_rdmsrq(MSR_IA32_MCU_STATUS);
> +
> +		if (status & (MCU_PARTIAL_UPDATE | AUTH_FAIL_ON_MCU_COMPONENT)) {
> +			pr_emerg("Partial update: MSR_IA32_MCU_STATUS=0x%llx\n", status);
> +			nmi_panic(NULL, "Microcode load: fatal status from partial update");
> +		}
> +	}

Are both messages needed? Is this because nmi_panic() doesn't do
printk() formatting?

Also, let's just say:

	nmi_panic(NULL, "Fatal microcode update failure");

>  	rev = intel_get_microcode_revision();
>  	if (rev != mc->hdr.rev)
>  		return UCODE_ERROR;
> @@ -779,11 +792,30 @@ static int __init save_builtin_microcode(void)
>  }
>  early_initcall(save_builtin_microcode);
>  
> +#define CPUID_EDX_ARCH_CAP	BIT(29)
> +
> +static __init bool mcu_capable(void)
> +{
> +	if (native_cpuid_eax(0) < 7)
> +		return false;
> +
> +	if (!(native_cpuid_edx(7) & CPUID_EDX_ARCH_CAP))
> +		return false;
> +
> +	if (!(native_rdmsrq(MSR_IA32_ARCH_CAPABILITIES) & ARCH_CAP_MCU_ENUM))
> +		return false;
> +
> +	return true;
> +}

Comments, please.

"mcu_capable" sounds like "Is this CPU capable of microcode updates",
which doesn't seem quite right or logically sensible.

Second, this needs to say why it's using raw CPUID functions and not
X86_FEATURE* bits or cpuid().

>  /* Load microcode on BSP from initrd or builtin blobs */
>  void __init load_ucode_intel_bsp(struct early_load_data *ed)
>  {
>  	struct ucode_cpu_info uci;
>  
> +	/* Indicate early enough to cover the early-loading path */
> +	cpu_has_mcu = mcu_capable();
> +
>  	uci.mc = get_microcode_blob(&uci, false);
>  	ed->old_rev = uci.cpu_sig.rev;
>  
> @@ -1023,8 +1055,7 @@ static __init bool staging_available(void)
>  {
>  	u64 val;
>  
> -	val = x86_read_arch_cap_msr();
> -	if (!(val & ARCH_CAP_MCU_ENUM))
> +	if (!cpu_has_mcu)
>  		return false;
>  
>  	rdmsrq(MSR_IA32_MCU_ENUMERATION, val);

Yeah, I'm not sure we need to cache mcu_capable(). Just call it twice.

Re: [PATCH] x86/microcode/intel: Panic on partial microcode update

[Dave Hansen]

Thinking about this a bit more: I don't think we should panic. It's
perfectly fine to spew a nice scary warning. But we really should
continue unless we really *know* that something has gone so horribly
wrong that it's dangerous to continue.

Think about things like folks who are ssh'd in. Say they have a bad,
partial ucode update. With this approach, they get a dead ssh session.

If you WARN() and keep going, they at least have a chance of seeing the
spew and getting it off the system.

I mean, the ucode update guys themselves could definitely have reset the
system if it needed to. They also know when it is dangerous to keep the
CPU running. They obviously don't think that this partial update thing
is *THAT* dangerous or they wouldn't have even let the CPU keep
churning. Right?

Re: [PATCH] x86/microcode/intel: Panic on partial microcode update

[Borislav Petkov]

On Tue, Jun 30, 2026 at 02:47:46PM -0700, Dave Hansen wrote:
> Thinking about this a bit more: I don't think we should panic. It's
> perfectly fine to spew a nice scary warning. But we really should
> continue unless we really *know* that something has gone so horribly
> wrong that it's dangerous to continue.
> 
> Think about things like folks who are ssh'd in. Say they have a bad,
> partial ucode update. With this approach, they get a dead ssh session.
> 
> If you WARN() and keep going, they at least have a chance of seeing the
> spew and getting it off the system.
> 
> I mean, the ucode update guys themselves could definitely have reset the
> system if it needed to. They also know when it is dangerous to keep the
> CPU running. They obviously don't think that this partial update thing
> is *THAT* dangerous or they wouldn't have even let the CPU keep
> churning. Right?

You want to taint because panic_on_warn will kill the system.

But lemme look at v2 first in detail, once it appears...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/microcode/intel: Panic on partial microcode update

[Chang S. Bae]

On 6/30/2026 2:47 PM, Dave Hansen wrote:
> 
> I mean, the ucode update guys themselves could definitely have reset the
> system if it needed to. They also know when it is dangerous to keep the
> CPU running. They obviously don't think that this partial update thing
> is *THAT* dangerous or they wouldn't have even let the CPU keep
> churning. Right?


A revision of the spec doc adds some description of the severity, which 
looks worth referencing here for the review / decision.

Spec - https://cdrdv2.intel.com/v1/dl/getContent/782715

There are two bits in MSR_IA32_MCU_STATUS:

  * Bit 0 indicates a partial update occured
  * Bit 1 indicates authentication failed _after_ the update was
    committed and the revision ID was updated.

Section 2.7 summarizes the implications:

+----------------+----------------+--------------------------+
| partial update | authentication | note / recommendation    |
+----------------+----------------+--------------------------+
| no             | fail           | impossible               |
|----------------+----------------+--------------------------|
| yes            | success        | log the error            |
|----------------+----------------+--------------------------|
| yes            | fail           | raise a fatal error      |
+----------------+----------------+--------------------------+

It could be an option to handle those cases separately. But yes, a sane 
ucode can escalate an unrecoverable condition via #MC. I'll revise V2 to 
simply taint the kernel (TAINT_WARN) on any of those.

Thanks,
Chang

[PATCH v2] x86/microcode/intel: Taint kernel on partial update

[Chang S. Bae]

A modern individual microcode update contains firmware for many pieces of
silicon inside the CPU. Sometimes, a single update operation successfully
updates some components and not others leaving a partially-applied
update.

This may leave the system in an undefined and unreliable state. Fatal
failures are expected to be handled by the CPU itself, by raising #MC for
example. If the CPU instead reports a partial update, warn and taint the
kernel at least.

A partial update may still update the revision. Continue checking the
revision rather than an immediate error return so the update result
remains consistent with the revision changes.

Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
---
V1 -> V2: Do not raise panic, inline cpuid check and massage the changelog (Dave)
---
 arch/x86/include/asm/msr-index.h      |  4 +++
 arch/x86/kernel/cpu/microcode/intel.c | 37 +++++++++++++++++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 18c4be75e927..7273d340470d 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -977,6 +977,10 @@
 #define MSR_IA32_MCU_ENUMERATION	0x0000007b
 #define MCU_STAGING			BIT(4)
 
+#define MSR_IA32_MCU_STATUS		0x0000007c
+#define MCU_PARTIAL_UPDATE		BIT(0)
+#define AUTH_FAIL_ON_MCU_COMPONENT	BIT(1)
+
 #define MSR_IA32_UCODE_REV		0x0000008b
 
 /* Intel SGX Launch Enclave Public Key Hash MSRs */
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index f4a444e6114d..913b0b32e39b 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -69,6 +69,9 @@ static const char ucode_path[] = "kernel/x86/microcode/GenuineIntel.bin";
 
 #define MBOX_XACTION_TIMEOUT_MS	(10 * MSEC_PER_SEC)
 
+#define CPUID_EDX_ARCH_CAP	BIT(29)
+#define MCU_STATUS_FAILURE_MASK	(MCU_PARTIAL_UPDATE | AUTH_FAIL_ON_MCU_COMPONENT)
+
 /* Current microcode patch used in early patching on the APs. */
 static struct microcode_intel *ucode_patch_va __read_mostly;
 static struct microcode_intel *ucode_patch_late __read_mostly;
@@ -679,6 +682,24 @@ static void stage_microcode(void)
 	pr_info("Staging of patch revision 0x%x succeeded.\n", ucode_patch_late->hdr.rev);
 }
 
+/*
+ * __apply_microcode() is the only caller which may be invoked in the early
+ * loading path. Use raw CPUID/RDMSR functions.
+ */
+static bool update_status_available(void)
+{
+	if (native_cpuid_eax(0) < 7)
+		return false;
+
+	if (!(native_cpuid_edx(7) & CPUID_EDX_ARCH_CAP))
+		return false;
+
+	if (!(native_rdmsrq(MSR_IA32_ARCH_CAPABILITIES) & ARCH_CAP_MCU_ENUM))
+		return false;
+
+	return true;
+}
+
 static enum ucode_state __apply_microcode(struct ucode_cpu_info *uci,
 					  struct microcode_intel *mc,
 					  u32 *cur_rev)
@@ -702,6 +723,22 @@ static enum ucode_state __apply_microcode(struct ucode_cpu_info *uci,
 	/* write microcode via MSR 0x79 */
 	native_wrmsrq(MSR_IA32_UCODE_WRITE, (unsigned long)mc->bits);
 
+	/*
+	 * Warn and taint the kernel on a partial update. Fatal conditions are
+	 * expected to be handled by the CPU itself.
+	 *
+	 * Then, continue checking the revision since a partial update may still
+	 * advance the microcode revision.
+	 */
+	if (update_status_available()) {
+		u64 status = native_rdmsrq(MSR_IA32_MCU_STATUS);
+
+		if (status & MCU_STATUS_FAILURE_MASK) {
+			pr_warn_once("update incomplete (MSR_IA32_MCU_STATUS=0x%llx).\n", status);
+			add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
+		}
+	}
+
 	rev = intel_get_microcode_revision();
 	if (rev != mc->hdr.rev)
 		return UCODE_ERROR;
-- 
2.51.0