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.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmh3wOoACgkQseqq9sKV Zxl0ghAAyQziM8rFCvf2Z/luUX2UyZSJx0d6ISuMAamKG+L0zgwtCeFZzwBQS3n7 Zh0BFDw73SRCDqRRpW69bqAfJK/OJKLN86JPwFb54+DCID+ODLVmRgIP/KSwpSLR zG8sKXvXYiJGwQQC4glYBVZVYXx1sFl9WegJCRMldwQRBgmMBhQaW58mLXNrvTsh GRR3BVKIQ1AzQJoAGO8mOnfJFH9Vh5W96eIE6GGQJTZs+z9MaQ2JWvZzujNC4DTl on0nfK7zSVdO2ETZ2XhCxZAKWlId3VwWcFFGNOoqoEd0ns03Cm/UmTDWDZJmmrNB zrrJlLGmEYRKxVu0DN5mU3NRUvxDQKRDFVxYmNUgVnCbAmrYVx29tgj4Jd1JvX+d uF1X3kkUnOjXWeemOxasOk2TNX4iurGEkefxByypQ1GlI305iN0A2Bf40MVjiKIz wN/oALSMQxZ86heMZwZ1E/43/Xry4r5rluvAsTj3QEnFyIhRf4WC9h+RKdf4yXsn UOoS1+PZQknwyxBiTB1Eeno2ilj0vnTkslBo6bB5D4HrOaB6wMEIgUETH4+hCDNB 8vnrZFXLQPO9woEL5LDtk8i9IqXHARotMUGYaYkXC4PWjGavi0ht9JeY64yYdzdk Gknecl/wXGAGK/f/bJp8N0/py3pO7fOTCZ8oZr1SgPyZwFTip7I=
=tXFj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)