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

[dino99]

Journalctl have logged:

****** kernel: CPU0 microcode updated early to revision 0x70a, date = 2010-09-29

which is quite different from the latest intel-microcode upgrade:

*******
intel-microcode (3.20150121.1) unstable; urgency=critical

  * New upstream microcode data file 20150121
    * Downgraded microcodes (to a previously shipped revision):
      sig 0x000306f2, pf mask 0x6f, 2014-09-03, rev 0x0029, size 28672
    * The microcode downgrade fixes a very nasty regression on Xeon E5v3
      processors (closes: #776431)
  * critical urgency: the broken sig 0x306f2, rev 0x2b microcode shipped
    in release 20150107 caused CPU core hangs and Linux boot failures.
    The upstream fix was to downgrade it to the same microcode revision
    that was shipped in release 20140913
  * source: remove superseded upstream data file: 20150107.
  * initramfs.hook: do not mix arrays and lists.
    Avoid echo "foo $@", use echo "foo $*" instead. This is unlikely
    to be expĺoitable, but it makes ShellCheck happier.

 -- Henrique de Moraes Holschuh <email address hidden> Wed, 28 Jan 2015 20:03:20 -0200
*******

both 'date' and 'rev' are not the same, which let me think that the 'builtin microcode'is loaded instead of the intel-microcode file.

So i also wonder if iucode-tool is able to deal with systemd, as its latest upgrade is quite older than the ubuntu's systemd use.

*****
iucode-tool (1.1.1-1) unstable; urgency=medium

  * New upstream release
    + Fix issues found by the Coverity static checker:
    + CID 72165: An off-by-one error caused an out-of-bounds write to a
      buffer while loading large microcode data files in ascii format
    + CID 72163: The code could attempt to close an already closed file
      descriptor in certain conditions when processing directories
    + CID 72161: Stop memory leak in error path when loading microcode
      data files
    + CID 72159, 72164, 72166, 72167, 72168, 72169: Cosmetic issues
      that could not cause problems at runtime
  * debian/control: bump standards version to 3.9.6

 -- Henrique de Moraes Holschuh <email address hidden> Tue, 28 Oct 2014 17:02:42 -0200
******

intel cpu q9550 : http://ark.intel.com/products/33924/Intel-Core2-Quad-Processor-Q9550-12M-Cache-2_83-GHz-1333-MHz-FSB

oem@u32:~$ ubuntu-drivers devices
== cpu-microcode.py ==
driver : intel-microcode - distro non-free
....

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: ubuntu-drivers-common 1:0.4.1
ProcVersionSignature: Ubuntu 3.19.0-10.10-generic 3.19.2
Uname: Linux 3.19.0-10-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.16.2-0ubuntu4
Architecture: i386
CurrentDesktop: GNOME
Date: Tue Mar 24 08:12:05 2015
SourcePackage: ubuntu-drivers-common
UpgradeStatus: No upgrade log present (probably fresh install)

[Henrique de Moraes Holschuh (hmh)]

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.

[dino99 (9d9)]

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

[dino99 (9d9)]

note about #3 above

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

[Adam Conrad (adconrad)]

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.

[Henrique de Moraes Holschuh (hmh)]

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.

[Jason Mills (virtualjmills)]

~ 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.

[Henrique de Moraes Holschuh (hmh)]

~ 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.