I was testing with `rngtest` on arm64 devices and wanted to know the
results on my amd64 AMD (Ryzen) CPU/APU.

System 1:
CPU: AMD Ryzen 7 1800X Eight-Core Processor (family: 0x17, model: 0x1, stepping: 0x1)
CPU family: 23 (in decimal)
microcode revision: 0x08001138 (according to dmesg)

System 2:
CPU/APU: AMD Ryzen 5 5500GT with Radeon Graphics (family: 0x19, model: 0x50, stepping: 0x0)
CPU family: 25 (in decimal)
microcode revision: 0x0a50000f (according to dmesg)

While `rngtest` results looked excellent on System 1, it revealed that
the HWRNG on System 2 is broken.
I'm currently triaging it (with Asus; MB manufacturer) and they asked me
to test with the latest microcode. So hereby a '+1' on bug #1076128.

I am running the latest amd64-microcode package on both and looked
further into all the package files and actually got confused.
I got the *impression* that some heuristic was used to determine whether
the microcode update should be applied.
That impression was based on what I saw in ``/etc/default/amd64-microcode``
and ``/etc/modprobe.d/amd64-microcode-blacklist.conf``.

I also went looking for the microcode revision number reported by
``dmesg`` in the upstream repo, but the relevant data seems to be part
of ``/usr/share/doc/amd64-microcode/README.gz``.
But no where did I find those microcode revision codes.

I'd like to know whether I'm actually running the latest microcode,
but I haven't figured out a way how?
So hereby a request to clarify/document how I (and others) can verify
whether they're (actually) *running* the latest (amd64-)microcode.

Cheers,
  Diederik

- -- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.9.10-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

amd64-microcode depends on no packages.

Versions of packages amd64-microcode recommends:
ii  initramfs-tools  0.142

amd64-microcode suggests no packages.

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZp4r3QAKCRDXblvOeH7b
bq07AP9eCVDDdE8Wvz/NUeibJ+PJCFObGyF93qO/i/I4ZizjNwEAgpSK/CBUAoZX
B+IEmONl1FxVeKNCs2aaWOKMzim5rwQ=
=2pIO
-----END PGP SIGNATURE-----

release myself and then used the .deb file created by Salsa's CI:
https://salsa.debian.org/diederik/amd64-microcode/-/commits/release-3.20240710.1+nmu1

Before:
root@cknowsvr04:~# dmesg | grep microcode
[    0.587262] microcode: Current revision: 0x0a50000f

root@cknowsvr04:~# apt install ./amd64-microcode_3.20240710.1+nmu1+salsaci+20240723+2_amd64.deb
Note, selecting 'amd64-microcode' instead of './amd64-microcode_3.20240710.1+nmu1+salsaci+20240723+2_amd64.deb'

Upgrading:
  amd64-microcode

...
Setting up amd64-microcode (3.20240710.1+nmu1+salsaci+20240723+2) ...
update-initramfs: deferring update (trigger activated)
amd64-microcode: microcode will be updated at next boot
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
root@cknowsvr04:~# reboot

After:
root@cknowsvr04:~# dmesg | grep microcode
[    0.587102] microcode: Current revision: 0x0a50000f


I'm pretty sure I did the 'nmu' correctly, but it seems the microcode
update isn't applied (at all).

and regenerated the initramfs: same result.
With that changed file did an ``apt reinstall ./<deb-file``: same result

But then I checked my own ``debian/changelog``:

```
amd64-microcode (3.20240710.1+nmu1) UNRELEASED; urgency=medium

  * Non-maintainer upload.
  * Update package data from linux-firmware 20240709-2-gbec87811
  * Updated Microcode patches:
    + Family=0x17 Model=0x01 Stepping=0x02: Patch=0x0800126f
    + Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107c
    + Family=0x19 Model=0x01 Stepping=0x00: Patch=0x0a00107a
    + Family=0x19 Model=0x11 Stepping=0x02: Patch=0x0a101248
    + Family=0x19 Model=0xa0 Stepping=0x02: Patch=0x0aa00215
    + Family=0x19 Model=0x01 Stepping=0x02: Patch=0x0a001238
    + Family=0x19 Model=0x11 Stepping=0x01: Patch=0x0a101148
    + Family=0x19 Model=0x01 Stepping=0x01: Patch=0x0a0011d5

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.

/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?

Good to know, thanks :)
And now I could also find that ``debian/initramfs.hook`` has it.

The main thing that had me worried was from ``amd64-microcode-blacklist.conf``:

I had written a couple of paragraphs before I realized the check is for kernels
*older* then 4.4. Since then the module is built-in (and not selectable), so
that file no longer 'actually' does something.

It turns out that the problem is not with the CPU, but Asus BIOS/firmware:

https://lore.kernel.org/linux-crypto/c28836c4-e823-dc36-e753-1a5ee3831629@amd.com/

But it seems Asus isn't interested in fixing it because they consider AM4 an
outdated platform and I should just accept that some things won't work...
Which I ofc will never accept, so that'll be a RMA :-/


That sucks as this was the thing I was looking for. But as written above, it
seems irrelevant to the original problem I tried so solve.

It does and was an interesting read, so thanks for that.

AFAIC you can close this bug. I'll leave it up to you whether it's useful/worth
it to maybe update some comments (like not applicable with kernels > 4.4).

Cheers,
  Diederik