Intel has released new CPU microcode for download

[bcantrill]

Despite the name, this is not Linux-specific microcode. If you're running SmartOS or another illumos derivative, run ucodeadm(1) on the microcode.dat file (which will need to be renamed to have an "intel" prefix per the man page -- e.g., "intel-code.txt"). You can then run "ucodeadm -v" to validate that the new microcode has been loaded. (Note that this does not persist across a reboot, but we at Joyent are currently in the process of upstreaming the microcode into illumos, at which point it will.)

[foxhop]

Awesome! Thanks for this!

[1000units]

And slow down my computer? No thanks.

[transpute]

Intel, AMD and Via microcode is being archived by CPUID, by the user community: https://www.win-raid.com/t3355f47-Intel-AMD-amp-VIA-CPU-Micr...

"Collecting all available Production CPU microcodes is important for upgrading/downgrading purposes, for creating universal tools that can help people understand what microcode they use, for research on how the general technology works, for developers with no vendor representative who want to experiment on a given platform etc.

Disclaimer: All the microcodes below come only from official BIOS/UEFI updates, Intel Linux Microcode Updates, Linux Distributions, Windows Updates etc which were provided and made public by various manufacturers! It is always advised to request and/or wait for your OEM/OS to release newer fixes. The microcodes are gathered and provided with the sole purpose of helping people who are out of other viable solutions. Thus, they can be extremely helpful to those who have major problems with their systems for which their manufacturer refuses to assist due to indifference and/or system age."

[steve19]

I always assumed they were not just signed but encrypted, and padded to avoid meta analysis. Is that not the case?

[chrisper]

For Windows there is also this:

https://labs.vmware.com/flings/vmware-cpu-microcode-update-d...

I have never tried it though.

[efoto]

The linked Intel page is a mess.

It is titled "Linux* Processor Microcode Data File Version: 20180108 (Previously Released) Date: 1/8/2018"

Below, however, you can see highlighted "A newer version of this software is available. Click here to get the latest version of this software." This, though, points to an earlier ("Version: 20171117 (Latest) Date: 11/17/2017") version: https://downloadcenter.intel.com/download/27337/Linux-Proces...

(one hour later) UPDATE: appears to be fixed. Well, not really, only if the link specifies the product, i.e. https://downloadcenter.intel.com/download/27431/Linux-Proces...

[mrmondo]

To update the intel-ucode package to the system:

- 1. Ensure the existence of /sys/devices/system/cpu/microcode/reload

- 2. Copy intel-ucode directory to /lib/firmware, overwrite the files in /lib/firmware/intel-ucode/

- 3. Write the reload interface to 1 to reload the microcode files, e.g. echo 1 > /sys/devices/system/cpu/microcode/reload

[blibble]

don't forget to update your initramfs, else on reboot it won't be applied

on debian: update-initramfs -u

check with dmesg | grep microcode

[snvzz]

You forgot to say "on Linux".

For Dragonfly instructions see: https://www.dragonflydigest.com/2018/01/09/20710.html

[newman314]

FWIW, microcode is now included the patch that VMware released today.

Gonna go test it out now...

PSA: VMs have to be cold booted after patching and set to HW v11+ for PCID support

EDIT: Just fired up my first Windows VM after patching ESXI and I'm now showing all green using the PowerShell script.

Here's the link that I'm referring to: https://www.vmware.com/us/security/advisories/VMSA-2018-0004...

[rconti]

Yikes. So they refuse to vMotion to a host that's on the new microcode? I'm not even clear on how that would be supported -- it should Just Work if the host is in the cluster. Are hosts unable to rejoin a cluster after rebootign with this new microcode because they're effectively part of a different processor compatibility now? Does EVC affect how this impacts the ability to vMotion?

[kyledrake]

Literally tells us nothing about what's in it. Not even a changelog. Not even a sentence hinting as to what might be in it. Incredible.

[mehrdadn]

> Literally tells us nothing about what's in it. Not even a changelog. Not even a sentence hinting as to what might be in it. Incredible.

They do have ./releasenote:

  Intel Processor Microcode Package for Linux 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
  <snip>

But I'm not sure how to interpret it... BDW is probably Broadwell and HSW is probably Haswell etc., IVT is... interrupt vector table? and I'm not sure what the other characters are.

[phire]

Looks like they updated the microcode for every single processor they ever released, going all the way back to the Pentium.

The list includes: The Pentium 4, Pentium III, Pentium II, Pentium Pro and the original Pentium.

I didn't even know the Pentium had upgradable microcode.

[vbernat]

Not all listed processors got an update. If you look at SandyBridge E, the associated microcode is still from 2013.

[kiwijamo]

I thought you were joking and had a close look at the list. Turns out you're absolutely right!

Intel® Pentium® Processor 100 MHz, 50 MHz FSB Intel® Pentium® Processor 120 MHz, 60 MHz FSB Intel® Pentium® Processor 150 MHz, 60 MHz FSB Intel® Pentium® Processor 75 MHz, 50 MHz FSB Intel® Pentium® Processor 90 MHz, 60 MHz FSB

[dreamcompiler]

Anybody know how to make this work in OSX, for those of us who don't want to "upgrade" to the train wreck that is High Sierra?

[1over137]

Does High Sierra update the microcode of the CPU?

For Sierra, a patch is likely coming; there is "Security Update Developer Beta 2018-001" which you can get using their beta program.

[caffeineninja]

As someone living/fighting through the performance degradation that the kernel patches have done to IO loads at AWS, I'm wondering if their Xen patches have had this or may include it in the future.

Would really really rather that there were no more negative changes.

[blasdel]

Some of the hypervisor fixes were dependent on the new microcode

[omshiriya]

Downloads for Intel® Xeon® Processor E5-2630 (15M Cache, 2.30 GHz, 7.20 GT/s Intel® QPI)

[karakarga]

Tested rev 0x042a on my Xeon E5-2658 v2 on my Asus X79-Deluxe mainboard. Flashed by using UBU v1.69.10 run Ashampoo SpectreMeltdownChecker both vulnerabilities are green with a tick now. It say's "your processor is safe" but release date of the patch is 2017-12-01 and goes up to 2017-11-16 which means, they know about this bug at least the beginning of November 2017 and they hide it about 2 months. What to think about that?

[djmips]

I downloaded this microcode from the link and got the latest BIOS for my Asus motherboard. I found my CPU family/model/stepping using https://www.intel.com/content/www/us/en/support/articles/000...

I used a tool and instructions from https://www.delidded.com/how-to-update-cpu-microcode-in-ami-... to update my AMI BIOS. It recognized the microcode and added it to the list. Unfortunately, the tool showed my microcode as having a date of 2013 even if it was listed and included in the download. So I have to wait for updated microcode I assume. I flashed it anyway. Post boot tests showed I was not protected by microcode... I have a Bloomfield CPU.

This technique will probably work for someone else with a newer CPU.

[ars]

Wish Intel would say if this does anything useful without also updating the Kernel, or do you have to have both.

[em3rgent0rdr]

I presume you would need to do both, since there are multiple attack vectors. Some problems like meltdown can be mitigated via how the kernel handles page table's when switching to kernel mode, while some problems like spectre's branch manipulation need microcode updates.

[chiluk]

I opened a request on Intel's Community Site requesting microcode changelog documentation. Hopefully I'll get an answer.

https://communities.intel.com/message/518872#518872

Please do click the "I have the same question" button on that thread. Hopefully if it gets enough heat Intel will answer our questions.

As best I can tell at the moment these changes are necessary in order to enable the IBRS and IBPB changes that are currently being discussed on LKML. AFAIK, IBRS and IBPB mitigate against Spectre V2 performance regressions that are introduced with the retpoline changes.

[shmerl]

Does AMD also need some microcode update for this?

[kijiki]

https://www.amd.com/en/corporate/speculative-execution

They claim no, due to microarchitectural differences in their branch predictor behavior. This is variant 2 we're talking about here.

[alexbakker]

Odd, this doesn't appear to apply on my 2500K even though it's listed as "valid for this product":

  [    0.000000] microcode: microcode updated early to revision 0x29, date = 2013-06-12

Works fine on my 7200U though.

[krisives]

Is there any meaningful way to know what the differences are between previous microcodes?

[TheChaplain]

Only what Intel provides, the updates are AFAIK encrypted.

[noncoml]

If they can fix it in microcode, why did they have to patch the kernel?

[ajdlinux]

You need both.

According to https://access.redhat.com/articles/3311301:

> CVE-2017-5715 (variant #2/Spectre) is an indirect branching poisoning attack that can lead to data leakage. This attack allows for a virtualized guest to read memory from the host system. This issue is corrected with microcode, along with kernel and virtualization updates to both guest and host virtualization software. This vulnerability requires both updated microcode and kernel patches. Variant #2 behavior is controlled by the ibrs and ibpb tunables (noibrs/ibrs_enabled and noibpb/ibpb_enabled), which work in conjunction with the microcode.

[kelnos]

Meltdown/Spectre is actually 3 different, but related, vulnerabilities, each with different mitigations/workarounds.

[Freaky]

CPU: Intel(R) Xeon(R) CPU L5639 @ 2.13GHz

Not listed :/

[milofeynman]

I'm running freenas on a Xeon. I'm assuming i am going to have to install something from supermicro and wait for a freenas (and freebsd) update. Is there anything else I should update?

[Twirrim]

Note: We don't actually know what this microcode contains. It could be a bug fix for the one that came out a few days ago, a bug maybe not present on your generation of CPU