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

[Maciej W. Rozycki]

On Sun, 19 Jul 2026, 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.
> > 
> >  Is there no risk for silent data corruption such as in storage after a 
> > broken ucode update?
> Is there no risk for silent data corruption such as in storage after a
> kernel panic?
> 
> Is there no risk for silent data corruption such as in storage after a
> use after free or a stray write? Or any other bog standard kernel bug?
> 
> We don't aim for "zero risk", IMNHO. We can't.

 We aim not to set a policy either, but at this point we have become aware 
the CPU is in a bad state, so I think at the very least there needs to be 
a way for the site manager to configure handling according to their needs, 
and I think it should be killing the system by default.

> >> 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?
> > 
> >  Umm, what the reasonable alternative would be for the RTL designer, a CPU 
> > shutdown?  Then you'd have no good way to figure out what really happened.
> 
> There are actually a huge number of things that can happen to a CPU that
> result in a reset or other conditions that are really hard to debug.
> Thankfully, most of them get debugged out of the system before end users
> ever get them. But folks who work with early silicon frequently get to
> experience the joy of having no good way to figure out what really happened.
> 
> Those "early" folks have lots of other tools at their disposal. But,
> believe me, the RTL designers and ucode writers are not shy about
> killing the system if data corruption is at all likely.

 That is true, however I think there is essential difference between CPU 
bringup and faults triggered in the field.  And you do actually have extra 
tools for bringup, such as hardware emulation, bond-outs, JTAG debug, etc.

> Chang, have you seen anything at all in the specs or from our Intel
> colleagues that makes you think that it's _dangerous_ to keep running
> rather than killing the system as soon as possible?

 From the implications already quoted:

On Wed, 1 Jul 2026, Chang S. Bae wrote:

> 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      |
> +----------------+----------------+--------------------------+

I infer the action you recommend to be taken is suitable for the second 
case, and in the third case the system is supposed to stop operating -- a 
fatal error in my interpretation means termination and for hardware it 
implies killing the system once the error has been reported.

 This would match my recommendation, and with a BMC in the picture I think 
it's even easier, because it's external to the main CPU(s) and therefore 
all that is required is sending the error message across right before 
termination.  The message can then be processed by the BMC accordingly as 
there's no need for the BMC to become disrupted in any way with a main 
CPU's fault.

  Maciej