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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)