Microcode updates differ between MCExtractor, Platomav repos and major Linux distros?

[meyergru]

I found that with my specific CPU (Haswell Intel(R) Core(TM) i5-4570 with Type 0, Family 6, Model 60, Stepping 3), I get a warning:

• CPU microcode is the latest known available version: NO (latest version is 0x28 dated 2019/11/12 according to local MCExtractor DB v139 - 2020/04/03)

Actually, at this time, MCExtractor (https://github.com/platomav/MCExtractor) is at DB v139, whereas the corresponding micorode repo is only at r138, see https://github.com/platomav/CPUMicrocodes .

Actually, current Debian and Ubuntu packages of Intel-Microcode seem to be at an even earlier version and no update seems to be in the works. I have found no easy way of converting between the files from the repo to versions needed for iucode-tool myself. Furthermore, the distro maintainers say that they deliberately do not include every new update, so I doubt that an end-user could or even should do that.

So: Is it of any use to signal a difference between the "newest" and the installed version based on what MCextractor "thinks" it knows unless there is a real availability of a patch?

[owlshrimp]

The microcode in the Linux kernel's blobs repo (which distributions pull from to build their packages) is disgustingly out of date when it comes to microcode because vendors typically can't be bothered to licence and contribute it.

AMD is particularly bad for this. They gave out microcode updates to motherboard vendors, but it seems few can be bothered to squeeze out an update. Withholding that update from everyone else means that the vast majority of users can't patch their systems when it would otherwise be both trivially easy and overwhelmingly automatic. (via the kernel's early loading mechanism)

The only option I have available (for example) would be to cobble together family 16h microcode from Platomav's repo because the last 16h microcode they contributed is from something like 2012 (obviously useless for mitigating any vulnerabilities). Some people on the Coreboot mailing list had to do the same for 15h for a long time and I'm not sure if that was ever properly resolved.

Platomav provides absolutely no guidance on how to repackage the microcode he archives for loading.

As for your question, I think it's useful to indicate that information. It's informative in the case that a patch is available for your motherboard (though it's impossible for the script to know that's the case). It may not be easy for someone to do something about if not, but at the very least it may put pressure on various people to get updates into the hands of users.

[meyergru]

+1 on that. There should be a disclaimer, though, because semi-knowledgable people like me, who do not know this, might save quite a bit time if a disclaimer was shown, indicating that though there actually IS a microcode update SOMEWHERE, it may not be feasible to actually make it work.

I had to find out the hard way that Platomav does not help a bit to actually make use of the updates.

In the first place, I was stunned to find that there actually are microcode updates available by CPU vendors that never made it into the official distributions. Given the fact that there are microcode updates both from CPU vendors and OS distributions once in a while, I came to the false deduction thinking that there actually was something like a straight pipeline "CPU vendor" -> "microcode package maintainer" -> "(linux) OS distribution". Matter-of-fact, there isn't.

[speed47]

It's a bit overdue, but there is now an FAQ entry about this. Thanks for bringing that up!