Intel microcode seems to have moved to github.

[ken@…]

As I noted on -dev and -support, the intel site we link to for microcode is not up to date. Although it has a link to a release from earlier this year, the release we link to does not show as out of date. The newer release there does show that, but links back to the earlier version.

The current version can be found on the releases link from ​https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/ and the current tarball for the latest versions is ​https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20190514.tar.gz

These versions, in conjunction with the kernel versions released yesterday, should address the Microarchitectural Data Sampling side-channel attacks publicised yesterday.

Please look at the rst documentation in the kernel patches for more details of the many variants which apply to different intel CPUs, and the status of mitigations.

For a brief summary, see ​https://xenbits.xen.org/xsa/advisory-297.html. This mostly affects VMs.

Because of this, flagging as high priority. At the moment, I do not have time to work on this.

[Xi Ruoyao]

Installed the new microcode from GH with the master branch of linux kernel in its Git repo.

dmesg | grep microcode:

[    0.000000] microcode: microcode updated early to revision 0x21, date = 2019-02-13
[    0.967171] microcode: sig=0x306a9, pf=0x10, revision=0x21
[    0.968583] microcode: Microcode Update Driver: v2.2.

cat /sys/devices/system/cpu/vulnerabilities/mds:

Mitigation: Clear CPU buffers; SMT disabled

[Bruce Dubbs]

Interesting. I actually wonder how much this affects workstations or other internal systems. For instance, my workstation is not directly accessible from outside my local network (none of my systems are). My workstation is a Intel i5-6500 and does not have hyperthreading (AKA SMT).

Of course I do use FF and Thunderbird, but I generally don't browse random sites.

For my development system, I generally only use wget for sources. That system does have hyperthreading, but I don't want that disabled.

[Bruce Dubbs]

What we have now is:

The first step is to get the most recent version of the Intel microcode. This must be done by navigating to ​https://downloadcenter.intel.com/download/28087/Linux-Processor-Microcode-Data-File and following the instructions there. As of this writing the most recent version of the microcode is microcode-20180807.tgz.

I think that all we need to do is change this to read:

The first step is to get the most recent version of the Intel microcode. This must be done by navigating to ​https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/ and downloading the latest file there. As of this writing the most recent version of the microcode is microcode-20190514a.

Ken, is there more that needs to be done?

[ken@…]

I'm now hoping to get to this tomorrow (after I've built firefox on a fresh system). My thoughts are:

Intel do now provide a releasenote, with the latest versions specified (e.g. 0x27 for my haswell), and therefore for intel we can mention that and suggest that people can go straight to late loading unless they wish to not reboot. Expand that - the 2019 releases all seem to be for vulnerabilities which are hard to exploit on a system without other local users (although, given time, and the general ease with which javascript repos can be hacked, probably not impossible).

And point to the online formatted html kernel docs for the thinking, the mitigations, and how to disable or change them, noting that kernels >= this week's are needed for the new intel ucode to be 'useful'. Referring back to your earlier question: hyperthreading is not turned off by default, in the same way that spec_store_bypass needs to be disabled for individual cases by prctl or seccomp.

Either keep the late-loading for older intel microcode and for amd where there seems to be no other way of checking which version is now available, or just go straight to late loading - but that needs more revision, I think we could look at that before the release. Hmm, intel are still ok with early loading to update a running system without reboot.

I was intending to just update the early-loading example and mark the late loading example as historic, from before intel documented the versions.

Oh, and there is a definite overhead when compiling (seems to be about 2% for an SBU after limited testing).

Umm, 20190514a ? (/me looks) - a longer tarball name, and according to the releasenote IVB-E/EP (Xeon E5 v2) reverted from 42f to 42e, BDX-ML looks like a typo in the old release (both versions now start 0b), added Atom x5-E39xx.

Still thinking out-loud as I post this!

[ken@…]

r21608

[Bruce Dubbs]

Milestone renamed