Update to upstream 2.1-15. 20180108. Includes fix for Spectre.
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2018-7e17849364
Please login to add feedback.
0 | 7 | Test Case microcode update |
This update has been submitted for testing by aarapov.
Seems to work fine on i5-6600K (Skylake).
works on various systems here:
microcode updated early to revision 0x23, date = 2017-11-20 previous was 0x22 from January
Worked here, grabbed RPM, ran dracut -f; rebooted
Kernel being used is: 4.15.0-0.rc7.git0.1.fc28.x86_64
previous microcode was 0x22: Now: microcode : 0x23
I believe this microcode update is missing one microcode: 06-4f-01
The one present in this package seems to be
sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
(usingcat 06-4f-01 | iucode_tool -tb -L -
) (sha1sum: d6f745decce9a16316becf6368abac15142ed0cd) RedHat/Centos (see http://mirror.centos.org/centos/7/updates/x86_64/Packages/microcode_ctl-2.1-22.2.el7.x86_64.rpm) is currently using a more recent one:sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
(sha1sum: 40270ff77e3065a617f60d5b1661a702588fdb3f)@vbrillau, The content is exact to what is inside official package available at https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?v=t
I will check it with Intel. Though I don't believe they've overlooked it.
@aarpov I'm also surprised, but that's what I'm seeing, see https://gist.github.com/Feandil/2bdf194c00cb7f9413afaacec27fb3a4 (iucode_tool is compiled from https://gitlab.com/iucode-tool)
@vbrillau, it seems that for whatever reason 06-4f-01 did get to the Intel's official tarball. We can only guess why. However there will be another updated tarball from Intel where 06-4f-01 should be present, either the same one or slightly modified.
Once I have it - I will issue new build. Stay tuned.
$ dmesg | grep micro [ 0.000000] microcode: microcode updated early to revision 0x80, date = 2018-01-04 [ 0.713758] microcode: sig=0x806e9, pf=0x80, revision=0x80 [ 0.713896] microcode: Microcode Update Driver: v2.2. $ rpm -q microcode_ctl microcode_ctl-2.1-20.fc27.x86_64
This update has been pushed to testing.
This update has been submitted for batched by bodhi.
LGTM.
This update has been submitted for stable by puiterwijk.
tested with spectre-meltdown-checker.sh
it did not work but after
dracut -f
it worked finewhich reports
This update has been pushed to stable.
microcode updated early to revision 0x23, date = 2017-11-20
I think it's a bad version of the microcode. How a microcode from november can patch spectre ?
The last version is this one : https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=52214 Date: 1/8/2018
Why would you negative karma on something you don't actually know about? The update contains the files in the tarball you just linked. If you would open those, you would see that the included microcode for your processor is revision 0x23. Yes, it was actually built on 11-20-2017, but Intel did not release it until 1/8/2018. As for how a microcode from November can help with Spectre, if you read any articles on it, you would know that Intel was notified last summer, this was under embargo, but several companies were aware and working on getting fixes ready so exposure was as limited as possible when it went public.
@fixide, you must got something wrong, I've tested mine after
dracut -f
using the script linked above and it works find, and the change log says it's dated 2018-1-8@alsadi jforbes have the one from november like me. But that should be what he explained. Intel worked on the patch before.
But don't know why some have :
microcode updated early to revision 0x23, date = 2017-11-20 and others : microcode: microcode updated early to revision 0x80, date = 2018-01-04
Perhaps CPU model ?
Script output... (it's good i think) * Mitigation 1 * Hardware (CPU microcode) support for mitigation: YES
Ok my answer is in the releasenote : 20180108 Release
-- Updates upon 20171117 release -- IVT C0 (06-3e-04:ed) 428->42a SKL-U/Y D0 (06-4e-03:c0) ba->c2 BDW-U/Y E/F (06-3d-04:c0) 25->28 HSW-ULT Cx/Dx (06-45-01:72) 20->21 Crystalwell Cx (06-46-01:32) 17->18 BDW-H E/G (06-47-01:22) 17->1b HSX-EX E0 (06-3f-04:80) 0f->10 SKL-H/S R0 (06-5e-03:36) ba->c2 HSW Cx/Dx (06-3c-03:32) 22->23 HSX C0 (06-3f-02:6f) 3a->3b BDX-DE V0/V1 (06-56-02:10) 0f->14 BDX-DE V2 (06-56-03:10) 700000d->7000011 KBL-U/Y H0 (06-8e-09:c0) 62->80 KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80 KBL-H/S B0 (06-9e-09:2a) 5e->80 CFL U0 (06-9e-0a:22) 70->80 CFL B0 (06-9e-0b:02) 72->80 SKX H0 (06-55-04:b7) 2000035->200003c GLK B0 (06-7a-01:01) 1e->22
Intel has now announced that Broadwell and Haswell CPUs may experience rebooting with these microcode updates. I have not been using the update for long enough to confirm if this is the case, but people should be aware of this new issue.
works