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

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

On 7/18/26 15:54, Maciej W. Rozycki wrote:
> On Tue, 30 Jun 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.

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

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?