security update in Fedora 27 for microcode_ctl

Status: stable 6 months ago

Update to upstream 2.1-15. 20180108. Includes fix for Spectre.

Comments 24

This update has been submitted for testing by aarapov.

Seems to work fine on i5-6600K (Skylake).

karma: +1 microcode update: +1

works on various systems here:

microcode updated early to revision 0x23, date = 2017-11-20 previous was 0x22 from January

karma: +1 microcode update: +1

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

karma: +1 microcode update: +1

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 (using cat 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

karma: +1 microcode update: +1

This update has been pushed to testing.

This update has been submitted for batched by bodhi.

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 fine

which reports

*   Hardware (CPU microcode) support for mitigation:  YES 
karma: +1 microcode update: +1

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.

Add Comment & Feedback
Toggle Preview

Comment fields support Fedora-Flavored Markdown. Comments are governed under this privacy policy.

-1 0 +1 Feedback Guidelines
Test Case microcode update
Is the update generally functional?
Content Type
Test Gating Status
Tests not running
Submitted by
Update Type
stable threshold: 3
unstable threshold: -3
submitted 6 months ago
in testing 6 months ago
in stable 6 months ago

Automated Test Results

Test results and gating status may sometimes conflict as the gating status is retrieved periodically by Bodhi's backend server, while the test results presented here are retrieved upon page load. If your update is marked as gated while all the tests show green/passed, the next check of gating status should open the gate.

Test Cases

0+7 Test Case microcode update