Re: [PATCH v3] x86/microcode/intel: Reject problematic loading on Granite Rapids systems

["Chang S. Bae" <chang.seok.bae@intel.com>]

On 9/17/2026 10:52 AM, Sohil Mehta wrote:
> 
> TL;dr: Should there be a revision_is_safe() check during
> __apply_microcode()?
> 
> The patch only adds the revision check during blob selection. Have we
> evaluated the corner cases hinted by sashiko when this check might be
> bypassed? It talks about suspend/resume and the CPU hotplug cases.
> 
> v1:
> https://sashiko.dev/#/patchset/20260901231634.714144-1-chang.seok.bae%40intel.com?part=1
> 
> v3:
> https://sashiko.dev/#/patchset/20260916225939.1144524-1-chang.seok.bae%40intel.com?part=1
> 
> The suspend/resume path probably doesn't matter for GNR servers and most
> of the CPU hotplug flows also seem to be covered. But, what about ucode
> update on cores that are not enabled at boot? If there are brought
> online later, would the ucode update skip the above check?
> 
> For example, maxcpus=N prevents certain CPUs from showing up in
> cpus_booted_once_mask. So the checks in setup_cpus() during late-loading
> would not catch them. IIUC, the BIOS version can be < 0x1000405, early
> load can bump the booted cpus to 0x1000405, and then late-loading can
> load newer versions and only cache the latest ucode revision.

Currently, what setup_cpus() does as its comment says is first ensure 
all CPUs that are present and has been booted up have their primary 
threads online. It just allows its secondary thread offline with nosmt. 
I don't think the current logic is broken there.

Then, those sibling threads assuming late-loading while soft-offlined 
will see an updated revision on its bringup because the loading scope is 
per-core by default, meaning the update performed by the primary thread 
also applies to its sibling.

Also, the NMI stop-machine rendezvous includes those soft-offlined CPUs. 
They are brought into the rendezvous and wait there while the update is 
being performed.

Now, I think it could be misleading if we put the revision check toward 
the end right before the application.

For example, suppose a multi-blob image that is bundled with revision 
0x1000405 and later ones and currently running < 0x1000405. With the 
check during blob selection, the parser can identify 0x1000405 as the 
loadable revision and reject later revisions.

If we move the check to just before application, the parser may instead 
select a revision newer than 0x1000405. The application would then be 
rejected, and the same blob would be selected again on the next attempt, 
resulting in the loading process repeatedly aborting without ever making 
progress.

So the revision check needs to remain part of blob selection, where it 
can affect which revision is considered loadable, rather than being only 
an application-time check.

Thanks,
Chang