intel-microcode could use better docs about upstream versions per CPU

The microcode update bundle (or collection, or package) contains a number of microcode updates. That's the date in the package version (20150121 in this case).

The release date of the collection of microcode updates is independent of the date of a particular microcode update.

There are hundreds of microcode updates in the update collection, with a very large variance in their dates. Some are very new (Intel changed them recently), while others are more than a decade old (they have not been changed since).

The kernel logs data about the specific microcode update it installed. It will never match the package date, there will always be at least a few days difference: someone has to approve each new microcode update for public distribution, prepare the updated microcode collection with all of them, and send it to the Intel website, and that takes at least a couple days.

Run this:
/usr/sbin/iucode_tool -l /lib/firmware/intel-ucode

and look at the dates of each microcode.

This is not a bug.

Thanks for explanation
but the journalctl log is confusing and may catch also some more users attention

At least that iucode-tool package changelog might explain that the 'date' and 'rev' shown in the journalctl log is the most recent revision available for that cpu model

note about #3 above

it is not the package's 'changelog' indeed, but its 'description' that needs to be more detailed.

At best, this is a wishlist against intel-microcode for a detailed description, or a file in /usr/share/doc that details the microcode contents, if that info is even all available to the packager.

Suggestions welcome. I do mean it as in "supply the suggested text changes", btw.

Note that:

  1. Information about the contents of a specific microcode update (i.e. "what does this fix") are UNAVAILABLE, and there is nothing that we can do about it. The README file explains this.

  1a. sometimes we can guess something about a specific microcode update (we might be wrong about it) due to outside hints. This gets noted in the debian/changelog when it is useful information to help release management. This is not going to change, either, unless Intel decides to take over this package and they start providing better information (instead of the much more likely result that there will be no information whatsoever).

  2. The changelog has detailed information on the package contents, i.e. what microcode it contains, over time.

  3. A flat list of all microcodes in the current package can be trivially obtained using iucode_tool (package iucode-tool):

/usr/sbin/iucode_tool -L /lib/firmware/intel-ucode

 4. The list of "marketing names" of every chip a microcode update signature is related to, is not available.

~ 2 years later ... :-)

For item 2, Intel now* documents what CPU family and stepping(s) are covered by each "Intel Processor Microcode" data file bundle. However, it would be better just point to the authoritative location, rather than engaging in lots of copy-pasta (yes pun) from the upstream source. See additional comment below.

(*) As of the 20180312 release, which is the first non-emergency release since Spectre/Meltdown et al surfaced.

For item 3, I'd suggest adding that sentence + code example to the README, if not already added.

For item 1, 2, and 4, this again could be a single line in the .deb Description or README that points back to the canonical (lower-case-C) URL for each data file bundle release upstream.

  For example, the 20171117 release was https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File

  ... and the 20180312 release is https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File

Intel also has a far more human consumable form of the information in their "Microcode Update Guidance" document, which (at present -- 2018.03.17) gets revised on a quasi-weekly cadence. Unfortunately it does not have a long-lived URL, as older editions get retired out.

March 2018 URL is https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf

Perhaps Canonical could lobby for some form of longer-lived URL.

~ Two years later... :-)

Intel does not keep their microcode guidance docs up-to-date, a new one is issued when they deem it necessary, and they're related to a specific issue being addressed.

The processor specification updates are still as opaque as always, and are slowly getting even harder to locate. They're also not necessarily synchronized with the availability of public microcode updates addressing public errata.

We include the Intel release notes in the package, as well as our own changelog of the contents.