Microupdates for microcodes

Here comes a post that is half an announcement and half a request for help to improve a situation, so please read on.

Yesterday I was finally putting the almost-finishing touches onto the new frontend system for my office (after the Italian Post screwup I was able to get the system from Alternate in a single week); one of these touches was setting up the microcode update support, which for Intel processors involves installing the sys-apps/microcode-ctl and sys-apps/microcode-data packages and adding a service to the boot runlevel.

At that point my thought went to Yamato and the fact that it sounded impossible that AMD had no way to update the microcode of their CPus on Linux, especially since I know for a fact that Microsoft users get,via Windows Update, an AMD-provided CPU support update for their systems — I still do a lot of support on Windows and a number of friends and customers run AMD boxes.

Lo and behold, AMD publishes microcode updates for some of their CPUs (Family 10h and later, so starting from Barcelona, which is just what Yamato has), so I went to look into that; the results are now in sys-kernel/amd-ucode (I wanted to use sys-apps like the Intel microcode, but I found, late, that there was already an ebuild for it in Sunrise, and I didn’t want to have to deal with pkgmoves or blockers for out-of-tree packages). This package only installs the microcode though, so the question was to find how to load the microcode.

The documentation provided by AMD suggests to build the microcode driver as a module in the Linux kernel; when the module is loaded into the kernel, it fetches the microcode via the standard firmware loading interface of the kernel, like it’s done to wireless cards and Radeon video cards. This is pretty nifty for many reasons. Interestingly enough, it also works fine if you build the driver statically, and built the firmware blob into the kernel. Unfortunately I wasn’t able to trigger a firmware reload from the filesystem via the /sys interface that is supposed to allow that.

And again this comes back to Intel; if the Linux kernel nowadays has a way to request the ucode file itself, why do the Intel CPUs still require us to install a binary (and a script) to load it? A quick check shows that while we do install it in /lib/firmware the microcode.dat file is not used by the kernel at all; the reason is also easy to find if you call less on that file: it is a text file! The microcode-ctl parses it and converts it to binary form each time the machine boots up — why at all? wouldn’t it be easier if the tool compiled it into binary form and then the init script, shipped with the data, would just output it on the device?

More interesting, the kernel does have support for requesting the microcode via the usual firmware-loading interface; but instead of looking for the generic microcode, like the AMD variant does, it looks for the specific firmware of a given CPU signature (combined family, model and stepping); the driver also has the ability to parse the generic microcode compiled from microcode.dat, and then find the right version for the right processor.

But this means that you have to pass through a number of hoops right now at each boot, rather than doing it once at install time. Am I missing some obvious application to do the Intel microcode processing? Ideally, microcode-data would then just install the already-cut firmware, and the kernel would request the single file it needs. No need for userspace programs to process firmware further.