After a recent full world update, I ran needrestart, which told me:
Diagnostics:
The currently running processor microcode revision is 0x0a500011 which is not the expected microcode revision 0x0a500012.

dmesg included multiple messages "microcode: No sha256 digest for patch ID: 0xa500012 found" one near the very top, and one for each cpu core.

Same messages with kernels 6.15.4, 6.14.11, and 6.13.10.

Booting 6.12.11, dmesg starts
[    0.696586] microcode: Current revision: 0x0a500012
[    0.696596] microcode: Updated early from: 0x0a500011

sys-kernel/linux-firmware is 20250708, and I assume it does have the correct microcde since it is loaded by 6.12.10, just not more recent kernels.

Apparently, use of sha256 for validating microcode is relatively recent (April?) and I also found https://www.cve.org/CVERecord?id=CVE-2025-22047 which seems at least distantly related, but I don't think that is my issue, as the cve says it's unaffected from 6.15.

My CPU is AMD Ryzen 7 5700G with Radeon Graphics which is family 0x19 model 0x50, and /lib/firmware/amd-ucode/README says Patch=0x0a500012.

I finally found suggestions that the real source of the microcode is the UEFI, so for my ASRock X570 Phantom Gaming 4 WiFi ax mptherboard, I upgraded the UEFI from 5.63 from last August to 5.65 from February. On rebooting, dmesg shows "microcode: Current revision: 0x0a500014."

I can find only one mention of 0x0a500014, at https://winraid.level1techs.com/t/amd-mcodes-zen-tool/106761 which is from last March, which just confuses me further. It also says the 0014 microcode is from 11/24. How long does it actually take for these microcode updates to actually get out into the real world?

So, can anyone clarify some things for me? Is the actual microcode taken from the UEFI or from the firmware file? Why did the 6.15.4 (I'm getting ready to try 6.15.6) fail to load 0x0a500012 but successfully load 0x0a500014 from the newer UEFI?

Final question - is that original error message perhaps misleading? The code is in /usr/src/linux/arch/x86/kernel/cpu/microcode/amd.c but it's going to take me much more time to follow what it's actually doing, but it appears the issue is not that the digest is missing (at least not from wherever the microcode itself is being read) but that the kernel doesn't have it.

Thanks for any relevant information, and pointers to explanations I can read are perhaps even better than direct answers.

Jack

Reply via email to