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

[Dave Hansen <dave.hansen@intel.com>]

On 7/27/26 19:58, Chang S. Bae wrote:
> In this new state, the processor may either continue operating or end up
> running with a combination of sub-components that has never been tested.
> Given that, I think one question to ask in the end is whether we trust
> the microcode's own error handling (completely), or not.

We *have* to trust it completely.

Think of it like this: CPUs are fundamentally analog, physical things.
They malfunction. They break. They include human-induced design errors.
But we don't have all kinds of code in the kernel to make sure that
gates in the ALU don't go bonkers and do 1+1=3.

It's not because kernel developers don't think that CPUs can break. It's
because if we went trying to detect things like that ^, the kernel
wouldn't be able to do anything else useful.

It's the same for the microcode update. The kernel first trusts that the
CPU does what the spec says. If that turns out not to be enough in the
real world, the kernel adds some paranoia later. But it's done
defensively against real, actual screwups. Not preemptively against
every imaginable screwup.

WARN(), please. Not panic().