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

[Sohil Mehta]

On 7/27/2026 1:36 PM, Chang S. Bae wrote:
> I think the first two points have played in this thread already. There 
> seems to be some caution, specifically around the authentication-failure 
> as per spec. 

What does an authentication failure mean in this context?

Does that mean unauthenticated microcode components somehow got loaded?

	or that

Someone attempted to load bogus microcode which was rejected by the
processor?

If it was rejected, then there is no need to panic, right? Just warning
about the attempt should be enough.


> 
> In summary, I think options are:
> 
>   1. Panic on any partial update is the most conservative and secure
>      option, but it may unnecessarily disrupt systems and users

My understanding of a panic is the OS saying "something catastrophic has
happened and I don't know how to make forward progress". So, it's better
to crash at this point than spew out incoherent information.

>   2. Warn admins that the system has entered a taint state, assuming the
>      processor handles truly unrecoverable cases itself.

If the processor chooses not to terminate itself after a partial update
maybe the kernel shouldn't either and give the admin the opportunity to
reconcile at their convenience. I think a strong warning makes the most
sense here.

In addition to a taint, should there also be a WARN()? That gives any
paranoid admin the option to automatically convert WARN => PANIC via
panic_on_warn. They can set panic_on_warn at runtime just before the
microcode update and then clear it once the update is done.

There seems to be a kernel command line option called panic_on_taint
which can be configured to panic only for TAINT_CPU_OUT_OF_SPEC. But
that may not be very useful because there isn't any runtime sysctl option.