
Intel has released new CPU microcode for download - mrmondo
https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File
======
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.)

~~~
1000units
And slow down my computer? No thanks.

~~~
djsumdog
A microcode update is applied directly to the processor, typically during the
boot process, and is a common practice to fix CPU bugs. It changes the
microcode running on the hardware itself.

This is totally different from the kernel PTI fixes, which attempt to deal
with Meltdown by changing the way the operating systems for
Linux/Mac/Windows/DragonFly (and hopefully soon *BSD) interacts with the
hardware and page tables.

Also you're making a statement without the above comment even stating if this
update is designed to address Spectre or Meltdown.

~~~
kev009
What he said isn't wrong, this new ucode changes fencing and branching
prediction semantics regardless of using the instructions added for spectre.

The problem is varied. While most people should run the new ucode and pending
kernel and toolchain fixes, not all must. Most businesses buy computers on
rated performance, and they are about to take an unexpected performance
haircut. Intel ucode isn't really optional, as there is no public change log
and it is unknowable what critical stability fixes are within. so even in a
closed system you can't selectively ignore it without some amount of
negligence. This presents a big problem for HPC and other closed systems.

IBM, a more professional and customer focused HPC vendor, is offering a
firmware flag to preserve pre-spectre behaviors. Most closed monolithic HPC
clusters can ignore these vulns and the associated nvidia one.

~~~
djsumdog
I wonder if this will end with Intel selling a lot of new chips, or Intel
having to issue massive recalls. I doubt Intel will be able to be able to get
away with discount/trade-ins without some serious legal complications.

I doubt we'll see entire data centers move to AMD as that would get stupid
expensive. For the short term, we might see data centers order extra AMD
blades and changing their provisioning systems to pin high IO tasks to those
machines. And that's for people who co-locate or host their own stuff.

I'm interested to see how this affects Infrastructure providers who abstract a
lot of that away, like AWS, DigitalOcean, Rackspace and others.

They might even be working on analysis and auto-migration to move high IO
nodes to higher performance machines transparently. It will be interesting to
see what hosting providers start blogging about in the next few weeks.

~~~
kev009
The first would set a strange precedent without some kind of good faith amends
by intel, and so far they have signaled apathetic callousness. I think the
legal implications haven't even begun to arise yet because large users are
still scrambling to understand the impact and deal with what they have on
hand. I speculate some kind of recall or prorate program will come out of it
in time.

Dieselgate is the closest thing I can think of recently where a product was
marketed primarily on performance that was later rescinded through mechanical
and/or software clamping. I wonder if there will be any FTC action for
consumers.

Separate from the above thoughts, intel was already testing customer patience
with Skylake. It wasn't a substantial performance increase, but it was a
substantial pricing increase. A lot of that, because, in merging the 4S
(E5-4xxx) and 8S (E7) into one marketing line, a majority of users are paying
big premiums for unwanted UPI scalability to get clock speed, cores, and
caches they do want. They also gambled poorly on clamping I/O lanes to fight
GPU, and with omnipath which is a niche at best. History will most likely
judge Krzanich poorly. I expect AMD and IBM will have a good couple years
coming up.

------
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...](https://www.win-raid.com/t3355f47-Intel-AMD-amp-VIA-CPU-Microcode-
Repositories.html)

 _" 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?

~~~
monocasa
This recent talk shows that AMD ucode wasn't signed _or_ encrypted up until
2013, and they reverse engineered large portions of the structure.

[https://www.youtube.com/watch?v=lY5kucyhKFc](https://www.youtube.com/watch?v=lY5kucyhKFc)

------
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...](https://downloadcenter.intel.com/download/27337/Linux-Processor-
Microcode-Data-File)

(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...](https://downloadcenter.intel.com/download/27431/Linux-Processor-
Microcode-Data-File?product=873)

------
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

~~~
mrmondo
Thanks, and on RHEL/CentOS/Fedora:

    
    
      dracut -f

------
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...](https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html)

~~~
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?

~~~
kijiki
The problem (requiring the cold reboot of the VM) is that they masked the PCID
bit off in the CPUID, so the VM thinks it is running on a CPU that doesn't
support PCID. Obviously they've stopped doing this with the new update, but
you have to cold reboot (not warm) for the newly enabled feature to be
visible.

Presumably they did this to make it possible to hot migrate VMs between old
hosts that don't support PCID, and new ones that do. Which, with hindsight,
was not a good tradeoff.

~~~
derefr
Given that Linux (and most other VM guest OSes of note) support CPU hotplug,
shouldn't vMotion have just given the VM a new, second CPU with PCID, and then
removed the first one?

~~~
kijiki
Given the history of CPU hot plug, it has always been generally assumed that
all the CPUs in an SMP are identical (hence the S in SMP). I'm not aware of
any OS that supports differing feature sets, and if one exists, it almost
certainly goes with the least common denominator feature set.

------
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.

~~~
rincebrain
The characters after the shorthand are probably chip revision.

{HSW,BDW,SKL,KBL,CFL} are probably Haswell, Broadwell, Skylake, Kaby Lake,
Coffee Lake.

{HSX,BDX,SKX} appear to be the codenames for some variants of
Haswell/Broadwell/Skylake - I find mixes of references to those being the
Xeons, associated chipsets, and otherwise.

GLK appears to be Gemini Lake, a codename for some of Intel's really low power
SoCs.

~~~
TazeTSchnitzel
Skylake-X?

~~~
onan_barbarian
SKX = Skylake-X = Skylake Xeon, as distinct from SKL, which is the "client"
die. The most important distinction is that SKX has AVX 512 and SKL does not.

------
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.

~~~
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

~~~
ce4
I wouldn't be so quick to say that.

it's the cumulatively package including all microcodes. Thus it applies to the
listed CPUs.

Without having a look, you cannot say which one got an update and which CPU
didn't.

~~~
djmips
Practically though, I downloaded the microcode from the link for my 2009 era
i7 920 Family 6 Model 1A stepping 5 CPU (Bloomfield) and applied it to my AMI
BIOS and the tool gave the date as 2013 AND after rebooting the Powershell
Get-SpeculationControlSettings command shows I do not have the hardware
microcode support.

For those interested I used the instructions here ->
[https://www.delidded.com/how-to-update-cpu-microcode-in-
ami-...](https://www.delidded.com/how-to-update-cpu-microcode-in-ami-bios/)
and to get my family/model/stepping I used
[https://www.intel.com/content/www/us/en/support/articles/000...](https://www.intel.com/content/www/us/en/support/articles/000005651/processors.html)

------
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.

~~~
mschuster91
What about those of us still on 10.11? That one is horrible already but the
horror stories I see on a daily base from colleagues with 10.12/10.13, thanks
but no thanks... I'm not a free QA engineer for Apple.

~~~
wadkar
I was under the impression that the recent security update for El Capitan
10.11.6 contains required fixes. I am doing a clean install and upgrading all
the way and check the PoC for any red flags. I will update here my findings.
+1 for not upgrading to High/Sierra.

Update: According to [https://support.apple.com/en-
us/HT208331](https://support.apple.com/en-us/HT208331) the Security Update
2017-005 contains fixes for Meltdown.

Update 2: According to [https://support.apple.com/en-
us/HT208403](https://support.apple.com/en-us/HT208403) the Safari Update
11.0.2 contains fixes for Spectre.

So folks on 10.11.6 El Capitan should be good.

~~~
kenrose
From the first link, the Meltdown fix is only for High Sierra:

Available for: macOS High Sierra 10.13.1 Impact: An application may be able to
read kernel memory (Meltdown)

------
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...](https://www.intel.com/content/www/us/en/support/articles/000005651/processors.html)

I used a tool and instructions from [https://www.delidded.com/how-to-update-
cpu-microcode-in-ami-...](https://www.delidded.com/how-to-update-cpu-
microcode-in-ami-bios/) 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](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](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.

~~~
shmerl
So I guess just kernel updates for Spectre are needed.

~~~
kijiki
Supposedly just for 1 of the 2 main variants of Spectre.

Though there are many likely more timing channels that could be reasonably
called Spectre variants that have not yet been fully explored...

------
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.

~~~
kzrdude
And no reverse engineering possible?

I'm a bit surprised there is no enthusiast blog that tries to document intel
microcode changes, but maybe I just haven't found it yet.

~~~
userbinator
This might be interesting reading for you:
[http://inertiawar.com/microcode/](http://inertiawar.com/microcode/)

Signed with 2048-bit RSA, and probably encrypted too.

~~~
kzrdude
Yes! I love it, even if there were meager returns; basically identifying the
algorithms for encrypting/signing the blob and that's all.

------
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](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.

------
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?

~~~
jlgaddis
Similarly, my primary (personal) server is an X10SL7-F with an E3-1231v3
(running FreeBSD). I'm waiting around for Supermicro but I would suggest not
holding your breath.

On second thought, I suppose the same goes for Asus with regard to my main
workstation (Z10PE-D16/WS with a pair of E5-2620v4's).

My ThinkPads are much older (T420/W530) and I'm not really expecting anything
for them from Lenovo -- especially any time soon, although they do put out the
occasional BIOS update for 'em.

~~~
Freaky
You don't need to wait for BIOS updates to install microcode - install
sysutils/devcpu-data and sysrc microcode_update_enable=YES

------
pero
no debian 9?

~~~
itomato

        apt-get install intel-microcode
    

[https://wiki.debian.org/Microcode](https://wiki.debian.org/Microcode)

then follow the "releasenote".

~~~
orblivion
I was just explained the other day on Hacker News how CPU microcode gets
delivered with the Kernel. That it gets installed automatically on every boot.
Why is it a separate package (which it turns out I don't have).

~~~
em3rgent0rdr
Well it is a separate package because it is fundamentally independent of the
kernel. For example, your Debian system might want to use a different kernel
like GNU's Hurd, kFreeBSD, or NetBSD, so by keeping those packages separate,
they can easily be used interchangeably. Also if you are on an AMD system, you
wouldn't want Intel microcode, but you might still want the same Linux kernel.

Also another big issue issue is the Intel microcode is proprietary, so
separating it from the kernel means that user could selectively pick and
choose if wants to have a totally free system, which would mean not loading
microcode updates with a libre kernel. This is done for instance with Parabola
and Trisquel distros, which is needed to obtain FSF's totally free
certification.

~~~
orblivion
Does this mean that my Ubuntu installation runs stock Intel microcode? It
means I actually have to know about this, and then go out of my way and know
how to install it? Or should it be installed by default on Ubuntu? Because the
package called `intel-microcode` isn't installed for me now.

------
phantom_oracle
HN really needs a _sticky_ feature for comments concerning security patches
and other updates that can bork your machine.

In this case, someone who dreams in hardware, breathes ASM and talks in bytes,
needs to clearly inform the community here concerning these questions:

\- SHOULD THIS MICROCODE UPDATE BE PERFORMED SEPARATELY FROM RUNNING: apt-get
update && apt-get upgrade ?

\- WHAT IS THE IDEAL/BEST WAY TO PERFORM THIS MICROCODE UPDATE?

~~~
pasbesoin
I like how HN's adherence to a certain simplicity has, I think, helped keep
the community integrated, and relatively egalitarian and respectful (with a
lot of other work going into that, as well, I'm sure).

But there have been a few times, this year and recently, where very pertinent
security issues have had threads of both immediate and enduring value, with
information -- mostly in the comments -- both useful and not available
elsewhere that I've seen, online.

Maybe another one of HN's select, few categories. E.g. "essential". Probably
populated solely at the moderators' discretion. In that, I'm in favor of the
benevolent dictators model: Maybe some polite and well-argued comments about
what might belong, but no voting or manipulable -- technically nor socially --
as to what gets in there.

When a processor, platform, OS is significantly borked, and the knowledge is
essential to a broad portion of this community. That would be what goes in
there. Starts as regular threads. If the need to know and value of them are
high enough, they get tagged with that category. So that, e.g. I can more
readily find that Intel Management Engine thread a couple of months later,
when I'm deciding whether I want to patch (or patch further) and what
mitigations to keep in place.

I don't know, and maybe I'm wrong. Just an idea.

P.S. I don't know whether the front page would link "essential" somewhere, or
whether it would be like some other qualifiers, that don't have a front page
presence. Again, the simplicity of the front page, versus the value of the
information and the need to know.

P.P.S. I really am afraid, though, of the arguments its presence might
engender, as to what belongs in it, and the disharmony this might introduce
and foster. There's a LOT of value to the existing simplicity (of the
interface, if not always the elephant behind it).

~~~
snowwindwaves
You can make this page! Start curating HN posts and comments and the other
resources relative to your essential needs and see what magic falls out

------
sasojaso
Does this release has anything to do with Linux P page table isolation patches
([http://pythonsweetness.tumblr.com/post/169166980422/the-
myst...](http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-
case-of-the-linux-page-table))?

