Arch Linux User Repository

For those interested, I noticed the same behavior in the Arch LTS kernel.

That makes sense, thank you either way

I can update the package but it will break loading microcode for some of newer updates. There was a CVE: https://github.com/google/security-research/security/advisories/GHSA-4xq7-4mgh-gp6w, https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking. Because of this AMD implemented microcode checksum verification in kernel: https://github.com/gregkh/linux/commit/c162ba4f45ab6ef3b7114af6fb419f1833f050c0. It's in the kernel since 6.13.6. If microcode from BIOS/UEFI is older than hardcoded version it will verify the checksum.

In my case, it fails to load the newest one: microcode: No sha256 digest for patch ID: 0xa500014 found. Latest BIOS by my manufacturer ships 0x0a500011 but kernel requires at least 0xa500013 (to skip the sha verification).

Edit: I've updated it anyway. If you really trust platomav's repository you can add microcode.amd_sha_check=off to the kernel parameters.

I think so...

Monthly updates dead?

@dobo Thanks! I appreciate the detailed response. In the last instance (hopefully) the kernel would report the CPU vulnerabilities in lscpu. That seems difficult for a third-party to trick the kernel into reporting everything is fine while still passing hardware validation on the microcode.

@0x9fff00: I wasn't aware of this, thanks for reporting. I've updated PKGBUILD.

@phonemic: I haven't found any specific resources regarding 19h family. But, microcode for 15h family is encrypted. Relevant quotes: "Note that Intel started to cryptographically sign microcode updates in 1995 [15] and AMD started to deploy strong cryptographic protection in 2011 [15]. We assume that the underlying microcode update mechanism is similar, but cannot analyze the microcode updates since we cannot decrypt them" 1

"On the 15h microarchitecture, binary comparison of multiple microcode revisions for a single processor produces no useful similarities, indicating that a chained block or stream cipher is likely being used for encryption. Since changes to offsets 672 through 2719, measuring exactly 2048 bits in size, result in early termination, it is possible that this segment contains a hash that is used to verify the integrity of the encrypted update data, in an encrypt-then-MAC approach. Although it is possible to use the reverse, MAC-then-encrypt, this is rather unlikely, as not only is it less secure, but 2048 bits is also rather long for the block size of a block cipher." 2

Generally MAC algorithms provide integrity and authenticity. My understanding is following (but I might be wrong): I suppose that the key and the algorithm is hardwired inside CPU. Unless someone knows the original key and the MAC algorithm, you're pretty safe (CPU won't accept "signed" microcode with wrong key). I haven't checked if microcode version is part of the MAC message. If it isn't third-party can theoretically force to load some old (possibly vulnerable) microcode.

I hope that this answers your question.

Are there known methods to validate the platomav repo? Specifically AMD 19h.

I am hesitant to use the binaries without a way to verify authenticity.

Thanks for maintaining this package.

Unlike the amd-ucode package, this package doesn't automatically rebuild initcpios when it's upgraded since it only installs /boot/amd-ucode.img but not /usr/lib/firmware/amd-ucode/microcode_amd*.bin, and /usr/share/libalpm/hooks/90-mkinitcpio-install.hook only checks for the latter