06-3c-03 not updated as part of 20200609 Release

[ryao]

The git history claims that the file has changed, but my local sha256 is 2af41bcbe3412aec07c720e2be6ebdd092adaf8a7635efef6c5480a0b53a185d, which is identical to the version from the 20200508 release.

iucode_tool reports it as sig 0x000306c3, pf_mask 0x32, 2019-11-12, rev 0x0028, size 23552. An Intel Xeon E5-1650 v3 running Linux 5.7.2 was found to fail to report "SRBDS: Mitigation: Microcode" in dmesg.

[esyr-rh]

$ sha256sum microcode-20200508/intel-ucode/06-3c-03 
dfbd0666cb9216c4f6024b87f757314d45668f24d9c2a0775a81e8dbf4066869  microcode-20200508/intel-ucode/06-3c-03
$ iucode_tool -L microcode-20200508/intel-ucode/06-3c-03 
microcode bundle 1: microcode-20200508/intel-ucode/06-3c-03
  001/001: sig 0x000306c3, pf_mask 0x32, 2019-02-26, rev 0x0027, size 23552
$ sha256sum microcode-20200609/intel-ucode/06-3c-03 
2af41bcbe3412aec07c720e2be6ebdd092adaf8a7635efef6c5480a0b53a185d  microcode-20200609/intel-ucode/06-3c-03
$ iucode_tool -L microcode-20200609/intel-ucode/06-3c-03
microcode bundle 1: microcode-20200609/intel-ucode/06-3c-03
  001/001: sig 0x000306c3, pf_mask 0x32, 2019-11-12, rev 0x0028, size 23552

[ryao]

I maintain a ZFS snapshot of my rootfs named "install" that I update once in a while:

desktop ~ # echo /.zfs/snapshot/install/var/db/pkg/sys-firmware/intel*
/.zfs/snapshot/install/var/db/pkg/sys-firmware/intel-microcode-20200508_p20200508
desktop ~ # iucode_tool -S -l /.zfs/snapshot/install/lib/firmware/intel-ucode/*
iucode_tool: system has processor(s) with signature 0x000306c3
microcode bundle 1: /.zfs/snapshot/install/lib/firmware/intel-ucode/06-3c-03
selected microcodes:
  001/001: sig 0x000306c3, pf_mask 0x32, 2019-11-12, rev 0x0028, size 23552
desktop ~ # sha256sum /.zfs/snapshot/install/lib/firmware/intel-ucode/*
2af41bcbe3412aec07c720e2be6ebdd092adaf8a7635efef6c5480a0b53a185d  /.zfs/snapshot/install/lib/firmware/intel-ucode/06-3c-03
desktop ~ # echo /var/db/pkg/sys-firmware/intel*
/var/db/pkg/sys-firmware/intel-microcode-20200520_p20200601
desktop ~ # iucode_tool -S -l /lib/firmware/intel-ucode/*
iucode_tool: system has processor(s) with signature 0x000306c3
microcode bundle 1: /lib/firmware/intel-ucode/06-3c-03
selected microcodes:
  001/001: sig 0x000306c3, pf_mask 0x32, 2019-11-12, rev 0x0028, size 23552
desktop ~ # sha256sum /lib/firmware/intel-ucode/*
2af41bcbe3412aec07c720e2be6ebdd092adaf8a7635efef6c5480a0b53a185d  /lib/firmware/intel-ucode/06-3c-03

The previous version installed was 20200508 according to my local package database. The microcode has not changed since then according to my tests. I am not sure why your 20200508 has a ucode version older than mine, but if the time stamps are to be believed, this hasn't been updated, which is a bigger problem.

The idea that it hasn't been updated with the mitigation is corroborated by a report that I had from another Gentoo developer (toralf) that Linux 5.7.2 is not reporting the mitigation being active. If the mitigation were included in this firmware, then Linux should report it. Note that he has an Intel Xeon E5-1650 v3 while I have an Intel Xeon E3-1276v3. They both appear to use the same microcode. I have not tried it on my local machine yet, but I checked the ucode versions to see if anything had changed after hearing from toralf. I also downloaded the latest ucode version from github and compared the checksum to ensure that we really do have the latest from Intel. Upon seeing that nothing had changed, I thought it would be wise to file an issue.

Is anyone able to get Linux to report that the mitigation is enabled on Haswell with the most recent microcode for it?

[ryao]

I see the problem. I thought I got the latest microcode, but I hadn't. The version codes were so similar that my eyes got mixed up. It is not clear to me why toralf did not see the mitigation enabled on his machine, but I am going to close this until I know for certain there is something that needs to be done by Intel.

[ryao]

Actually, wait... I just realized that even though my local copy is really the 20200601 version, the 20200609 release had the same checksum as the 20200601 version, so there is no point in closing this. There is something actionable here. Namely, we need new microcode.

[andyhhp]

I concur with @esyr-rh . There was a microcode update in this drop, as compared to May 20th, and the versions/shasums match.

2020-06-01 isn't a drop from here. However, it is likely that whomever packaged that drop did get the up-to-date Haswell E3 microcode, seeing how long its been available to OEMs for.

Xeon E3's and E5's don't use the same microcode. E5's use 06-3f-02 or 06-3f-04, E3's use this one.

Xeon E5's are not affected by SRBDS. There is no change the RDRAND/RDSEED instructions in microcode, and the sysfs file ought to read "not vulnerable".

If you want to test your E3 without installing a new kernel, install the msr-tools package, and modprobe msr; rdmsr 0x123. If you've got updated microcode, you should see 0 or 1 returned. If you've on older microcode, you should see an error trying to read that.

[ryao]

@andyhhp Thanks for helping to clear up the confusion.