Incoming details.
The CPU microcode for Intel Haswell-X, Skylake-X and Broadwell-X chipsets was updated to report both branch prediction control via CPUID flag and ability to control branch prediction via an MSR register. Required for kernel mitigation against CVE-2017-5715 (bug 643342).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e6ea9dcb23142a268cef722793a408071677d6b1 commit e6ea9dcb23142a268cef722793a408071677d6b1 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-01-04 16:24:38 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-01-04 16:24:55 +0000 sys-firmware/intel-microcode: Rev bump for CVE-2017-5715 mitigation The CPU microcode for Intel Haswell-X, Skylake-X and Broadwell-X chipsets was updated to report both branch prediction control via CPUID flag and ability to control branch prediction via an MSR register. Required for kernel mitigation against CVE-2017-5715. Bug: https://bugs.gentoo.org/643430 Package-Manager: Portage-2.3.19, Repoman-2.3.6 sys-firmware/intel-microcode/Manifest | 1 + .../intel-microcode-20171117_p20171215.ebuild | 39 ++++++++++++++++++++++ 2 files changed, 40 insertions(+)}
@ Arches, please test and mark stable: =sys-firmware/intel-microcode-20171117_p20171215
The updated ebuild removes the option to have a microcode.dat file which can be loaded with microcode-ctl. I was unable to figure out how I'm supposed to load that. Can we have some einfo what people should do instead? Also I wonder if it's wise to do such a change combined with a security update.
(In reply to Hanno Boeck from comment #4) > The updated ebuild removes the option to have a microcode.dat file which can > be loaded with microcode-ctl. > > I was unable to figure out how I'm supposed to load that. Can we have some > einfo what people should do instead? > > Also I wonder if it's wise to do such a change combined with a security > update. See the relevant section of: https://wiki.gentoo.org/wiki/Intel_microcode Use Section 5, to embed the firmware into the kernel and note the introductory NOTE
(In reply to Hanno Boeck from comment #4) > The updated ebuild removes the option to have a microcode.dat file which can > be loaded with microcode-ctl. > > I was unable to figure out how I'm supposed to load that. Can we have some > einfo what people should do instead? > > Also I wonder if it's wise to do such a change combined with a security > update. microcode-ctl is deprecated and doesn't work for recent processors (that's why we already removed the runscript). We will p.mask soon. Using kernel's CPU microcode loading support is the recommended way (some systems with outdated firmware may even require loading before initramfs/kernel). Because Intel didn't provide us with an updated *.dat file we were forced to remove this option with this update to make sure ucodes are getting used. Otherwise you would keep using *.dat file and won't see the updated ucodes.
x86 stable
amd64 stable. Maintainer(s), please cleanup. Security, please vote.
Sorry for commenting here, but this package does not seem to actually contain all microcode updates (see 643794 ). In short, after installing =sys-firmware/intel-microcode-20171117_p20171215 $ iucode_tool -l /lib/firmware/intel-ucode/* | grep 306c3 049/001: sig 0x000306c3, pf_mask 0x32, 2017-01-27, rev 0x0022, size 22528 Running the same on the extracted intel-microcode package from Debian: 024/001: sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552 According to https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre 0x0023 is needed on 0x000306c3 . I've opened 643794 on this, but likely it affects other CPUs, too.
Yes, this was only the microcode update for -X series because when we published no other microcode was available and we didn't want to hold back the one we received. Expect multiple rev bumps in the next days/weeks.
The official files are now up on the Intel website at https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?v=t
GLSA Vote: No! There's no point in issuing a GLSA here as it heavily depends on the processor your are using. I.e. there are still a lot of processors which don't have received a microcode update yet and we are already talking about Spectre NG :> All done, closing.
