> I got the *impression* that some heuristic was used to determine whether > the microcode update should be applied.
No. It has a simple heuristic to not increase the initramfs size by adding AMD microcode updates unless either it is running on an AMD processor when the amd64-microcode package is installed, OR you configure amd64-microcode to always add the updates to the initramfs. It is an "all or nothing" thing, and currently it has absolutely no "processor-model-aware" logic. For *Intel*, we have more heuristics, but that's because the full Intel microcode package is *very large*. The one for AMD is nowhere near large enough to justify the added complexity, yet. *Uploading* the microcode update to the processor is handled by the kernel during early boot, and it is done only if the processor signature matches one in a microcode update, and the new microcode revision in the update is strictly higher than whatever is already running in the processor. *Accepting* and *activating* the microcode update is on the processor. There are microcode updates that absolutely must be loaded very early during the reset (and sometimes even the power-up) sequence, and those can only be applied by the firmware itself, so they must be installed as a firmware update. These updates are *not* distributed by AMD to the general public (at least not on purpose), and Debian does not include them (at least not on purpose...). On some AMD processor models, there are microcode revisions from which you must NOT update the processor to some other microcode revision at all. I have no idea why, although i can come up with a few possible scenarios for this. The kernel driver for AMD microcode updates has logic that detects this situation, and does not send any microcode updates to the processor. Note that if the processor is not yet on any of those specific microcode revisions, it should apply the microcode update, that's why such updates are distributed even if some systems will have to detect that they must not apply them. > I'd like to know whether I'm actually running the latest microcode, > but I haven't figured out a way how? /proc/cpuinfo should report the running microcode version on a recent enough kernel. It will also log the microcode revision when it does a microcode update. There is no facility to check whether what is in your system's /lib/firmware/amd-ucode is the latest available microcode update that has been issued by AMD to the linux-firmware project, nor is there any facility to know whether there is a newer revision that is restricted to firmware vendors. I believe the needrestart package will actually warn if you need to reboot to update the microcode on your system processor, based on not-foolproof heuristics that look at /proc/cpuinfo and what has been installed by amd64-microcode (and intel-microcode). Oh, and the date-based versioning of the amd64-microcode package has no relationship to the dates on any of the microcode updates inside it. It is the date of the latest commit in linux-firmware that changed any of the several firmware files (AMD ucode, AMD SEV, AMD TEE) inside it. I hope this information solves any lingering doubts about how it works? -- Henrique de Moraes Holschuh <[email protected]>
