On Monday, 14 July 2025 00:11:58 British Summer Time Jack wrote: > 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.
>From what I read here, the kernel has been patched to fix this AMD microcode vulnerability: https://github.com/google/security-research/security/advisories/ GHSA-4xq7-4mgh-gp6w Hence it will complain if it can't find a sha256 digest to verify the microcode signature. > 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. The blobs listed in /lib/firmware/amd-ucode/README are generally behind on what AMD provide to OEMs to include in their MoBo UEFI firmware, or what AMD releases for server EPYC CPUs. > 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? I've read somewhere AMD only provide microcode releases for servers, not for consumer PCs. The latter are meant to be catered for by the OEM issued UEFI firmware, while the OEM still supports the hardware. The blobs are extracted from OEM firmware and are published at some point later on in the linux- firmware package. The submission of new microcode blobs and approval for inclusion in the linux-firmware releases can be protracted: https://gitlab.com/kernel-firmware/linux-firmware/-/blob/main/README.md > 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? This is what I have observed - the microcode contained in the BIOS/UEFI firmware loads and runs by the MoBo MEC upfront, before the kernel comes into play. If the microcode in the kernel is of a more recent version, then that will be loaded by the kernel at the start of the OS boot process. When the CPU vulnerabilities of the late 2010's started being announced, the OEMs had long abandoned their older products. Intel and AMD released newer microcode which never made it into the OEMs MoBo firmware, but it was loaded by the kernel and shown in dmesg output as being "Updated early". > 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. I think it is reasonable to assume a digest is not available on your system for the 0xa500012 ucode patch, or it is not a SHA256 hash. Otherwise a recent/backported kernel wouldn't complain when it loaded it. The hashes on my current kernel are stored in: /usr/src/linux-6.12.31-gentoo/arch/x86/kernel/cpu/microcode/amd_shas.c ~ $ grep 0xa50001 /usr/src/linux-6.12.31-gentoo/arch/x86/kernel/cpu/microcode/ amd_shas.c { 0xa500011, { > Thanks for any relevant information, and pointers to explanations I can > read are perhaps even better than direct answers. > > Jack I don't know if the above is of any help, a my ucode knowledge is quite limited.
signature.asc
Description: This is a digitally signed message part.
