Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#13656 closed enhancement (fixed)


Reported by: ken@… Owned by: ken@…
Priority: high Milestone: 10.0
Component: BOOK Version: SVN
Severity: normal Keywords:


New release for (according to phoronix) haswell up to coffee lake, cascade lake might not be vulnerable).

Addresses CVE-2020-0543 (SRBDS or Special Register Buffer Data Sampling).

I say "addresses" because the webpage for this vulnerability says

"Intel has implemented its mitigation for the SRBDS vulnerability in a microcode update distributed to software vendors on Tuesday June 9, 2020 or earlier. The mitigation locks the entire memory bus before updating the staging buffer and only unlocks it after clearing its content. This strategy ensures no information is exposed to offcore requests issued from other CPU cores.

Due to the considerable performance overhead of locking the entire system’s memory bus, Intel only applied the mitigation to harden a small number of security-critical instructions, specifically RDRAND, RDSEED, and EGETKEY (a leaf of the ENCLU instruction). This means that output from any other instruction (e.g., RDMSR) that issues offcore requests can be still leaked across CPU cores."

I see that today's -rc releases of supported kernels (5.7.2, 5.6.18, 5.4.46 and the LTS 4.4 releases) will mention this in the vulnerabilities.

Change History (10)

comment:1 by ken@…, 2 years ago

Owner: changed from blfs-book to ken@…
Status: newassigned

comment:2 by Pierre Labastie, 2 years ago

Heads-up: seems that some microcode blobs can freeze some processor types:

Note that the new Haswell blob seems to run ok up to now on my machine.

comment:3 by Pierre Labastie, 2 years ago

For now, the workaround is to downgrade one blob (06-4e-03) to the previous version. Should we make a tarball, or just warn on "errata"?

comment:4 by ken@…, 2 years ago

I thought I'd already closed this (done in r23272), but it seems I hadn't updated the ticket.

For 06-4e-03 I see no point in making our own tarball. A quick look at my notes for my own skylake i3 (which is normally powered off) suggest mine is 06-5e-03 so irrelevant to this. Looking at the Release notes for 20200609 mine is SKL-H/S, affected machines are SKL-U/Y or SKL-U23e. No idea what those suffixes mean, but oddly both 4e and 5e are using the same microcode versions in the update.

(Edit: I became mistaken about which verion I had, and miscorrected it, should now be correct again)

One of the Arch links from that issue says that the problem on an i7-6600 was caused by using their -1 version of the microcode, and they already had a -2 which fixed it. According to their PKGBUILD they are applying a git commit for 06-4e-03 over the shipped blob.

AHH, the '4e' d6 microcode was shipped in the 20191115 release. I guess that means that anyone with one of those machines which does not boot with the 20200609 microcode should use the 20191115 version and accept that the mitigations are not present.

Last edited 2 years ago by ken@… (previous) (diff)

comment:5 by ken@…, 2 years ago

I've added a Caution in r23286. Just waiting to boot 5.7.2 on this haswell to confirm that (like on my Skylake) it shows 'microcode' as the mitigation for SRB DS.

comment:6 by ken@…, 2 years ago

I added a Caution in r23286.

I've now updated the kernel on this haswell to 5.7.2, and like on my skylake it does show Mitigation: Microcode against the srbds vulnerability.

comment:7 by ken@…, 2 years ago

Resolution: fixed
Status: assignedclosed

comment:8 by ken@…, 2 years ago

I will note in this ticket that they made a fresh release on 20200616, reverting both sets of Skylake microcode so that the srbds mitigations are no-longer present.

Since my machine semeed to be working ok with the 20200609 version, this seems to be a regression (less mitigation) so I've raised

For the moment, I see no reason to change what is in the book (try 20200609, if early loading fails to boot then replace it with the previous version).

If there is more data (e.g. people reporting success, or failure, with 20200609) that may change.

comment:9 by Bruce Dubbs, 2 years ago

Milestone: 9.210,0

Milestone renamed

comment:10 by Bruce Dubbs, 2 years ago

Milestone: 10,010.0

Milestone renamed

Note: See TracTickets for help on using tickets.