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

[David Laight]

On Tue, 28 Jul 2026 07:12:13 -0700
Dave Hansen <dave.hansen@xxxxxxxxx> wrote:

> 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().
> 

PANIC_ON_WARN ....