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.)
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."
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...
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
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...
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.
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.
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?
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.
Downloads for Intel® Xeon® Processor E5-2630 (15M Cache, 2.30 GHz, 7.20 GT/s Intel® QPI)
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?
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.
Wish Intel would say if this does anything useful without also updating the Kernel, or do you have to have both.
I opened a request on Intel's Community Site requesting microcode changelog documentation. Hopefully I'll get an answer.
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.
Does AMD also need some microcode update for this?
Odd, this doesn't appear to apply on my 2500K even though it's listed as "valid for this product":
Works fine on my 7200U though.
[ 0.000000] microcode: microcode updated early to revision 0x29, date = 2013-06-12
Is there any meaningful way to know what the differences are between previous microcodes?
If they can fix it in microcode, why did they have to patch the kernel?
CPU: Intel(R) Xeon(R) CPU L5639 @ 2.13GHz
Not listed :/
no debian 9?
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?
Viva la Mechita...23788986589
Viva la Mechita!!!! 356324789 6 3255 56834 @BT
Does this release has anything to do with Linux P page table isolation patches (http://pythonsweetness.tumblr.com/post/169166980422/the-myst...)?