On January 8th Intel released new Linux Processor microcode data files that can be used to mitigate the Spectre and and Meltdown vulnerabilities in Intel CPUs. Using microcode files, an operating system can fix known bugs in Intel CPU without having to perform a BIOS update on the computer.
According to the Intel microcode download page, this release is available for 40 different versions of Linux and valid for 2,371 Intel processors all the way down to the 150 mhz Pentium Processor from 1995.
Update 1/11/18 10:45PM EST:
As pointed out in a comment to this article, this microcode release only fixes issues in certain processors. Below are the list of processors from the release notes that received updates.
Based on information found here and on Intel's site, the first column is processor model, the second column is the abbreviation from the release notes, and the third is the new revision numbers from the release notes.
Another reader pointed out that the numbers in parenthesis coincide with the CPUs family, model, and stepping. The format is (family-model-stepping:unknown) with the values being in hexadecimal. You can find the values associated with a particular processor by looking it up on cpu-world.com. We are still unsure what the value after the colon stands for.
For example, if you look up the Haswell processor that has an identifier of (06-3c-03:32) at cpu-world.com, you will see that the information on the site matches the identifier listed in the release notes.
Processor Model | Abbreviated Model | Revision |
IvyTown | IVT C0 | (06-3e-04:ed) 428->42a |
Skylake | SKL-U/Y D0 | (06-4e-03:c0) ba->c2 |
Broadwell | BDW-U/Y E/F | (06-3d-04:c0) 25->28 |
Haswell | HSW-ULT Cx/Dx | (06-45-01:72) 20->21 |
Crystal Well | Crystalwell Cx | (06-46-01:32) 17->18 |
Broadwell | BDW-H E/G | (06-47-01:22) 17->1b |
Haswell Xeon | HSX-EX E0 | (06-3f-04:80) 0f->10 |
Skylake | SKL-H/S R0 | (06-5e-03:36) ba->c2 |
Haswell | HSW Cx/Dx | (06-3c-03:32) 22->23 |
Haswell Xeon | HSX C0 | (06-3f-02:6f) 3a->3b |
Broadwell-DE Xeon | BDX-DE V0/V1 | (06-56-02:10) 0f->14 |
Broadwell-DE Xeon | BDX-DE V2 | (06-56-03:10) 700000d->7000011 |
Kaby Lake | KBL-U/Y H0 | (06-8e-09:c0) 62->80 |
Kaby Lake | KBL Y0 / CFL D0 | (06-8e-0a:c0) 70->80 |
Kaby Lake | KBL-H/S B0 | (06-9e-09:2a) 5e->80 |
Coffee Lake | CFL U0 | (06-9e-0a:22) 70->80 |
Coffee Lake | CFL B0 | (06-9e-0b:02) 72->80 |
Skylake Xeon | SKX H0 | (06-55-04:b7) 2000035->200003c |
Gemini Lake | GLK B0 | (06-7a-01:01) 1e->22 |
Windows users can also benefit from updated microcodes, but these need to be first tested by Microsoft and then released as an update. The last microcode update, other than hotfixes, was released in 2015. It is not currently known if Microsoft will be releasing the new microcodes in a future update.
Applying the new microcode data files to Linux
For Linux users, applying a new microcode data file is fairly easy as Linux distributions typically release them as an update when they become available. To install a new microcode update, the best method is to use the package manager that is included with your Linux distribution.
For Debian and Ubuntu distributions, you should use apt to install the intel-microcode packages. The package manager will also install any other dependencies needed such as iucode-tool. Redhat and Centos users can use yum and should search for microcode_ctl.
If you are unable to install an update through a package manager you can also install the microcodes manually. In modern Linux distributions this is typically done by copying the downloaded intel-ucode folder into the /lib/firmware folder and then running the echo 1 > /sys/devices/system/cpu/microcode/reload command.
You can see an example of how NickAu, one of the BleepingComputer moderators, installed the updates manually in Ubuntu here.
The full instructions from the Intel microcode release can be found here:
-- Microcode update instructions --
This package contains Intel microcode files in two formats:
* microcode.dat
* intel-ucode directory
microcode.dat is in a traditional text format. It is still used in some
Linux distributions. It can be updated to the system through the old microcode
update interface which is avaialble in the kernel with
CONFIG_MICROCODE_OLD_INTERFACE=y.
To update the microcode.dat to the system, one need:
1. Ensure the existence of /dev/cpu/microcode
2. Write microcode.dat to the file, e.g.
dd if=microcode.dat of=/dev/cpu/microcode bs=1M
intel-ucode dirctory contains binary microcode files named in
family-model-stepping pattern. The file is supported in most modern Linux
distributions. It's generally located in the /lib/firmware directory,
and can be updated throught the microcode reload interface.
To update the intel-ucode package to the system, one need:
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
Comments
Sole78855 - 6 years ago
The package contains microcode for all listed processors, but the updated microcode pertaining to Meltdown /Spectre mitigigation is limited to only certain processors.
Valid only for the following processors, see the "relesenotes" file contained in the package:
-- 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
Fake news ! Do your research better !
Lawrence Abrams - 6 years ago
Thanks..I have updated the article.
As for fake news, I do not think fake news means what you think it means. Nothing deliberately meant to mislead here.
LConstantin - 6 years ago
The number after the colon is likely an identifier for the platform type. I have the Haswell-ULT Core i7-4510U in my laptop, which is probably 06-45-01:72 in that list. When I load my laptop's AMI UEFI image in MMTool and look at the microcode patches within it says CPUID 0651, Platform Type 72. Also, if I unpack the microcode.dat, the microcode update file for my CPU is: cpu00040651_plat00000072_ver00000021_date20171120.bin. I have tested the file and indeed the updated microcode revision is 21 and contains the Spectre patch.
HWiNFO64 lists my CPUID as 00040651
weareanomalous - 6 years ago
I have a 6-core i7 Ivy Bridge-E(Not Ivy Town which means E7 only) and with HWinfo64, I found my microcode is updated from 428 to 42A. According to Hackernews, the Ivy Town processors mentioned in the list comprises of Xeon E7, E5 and i7 4800/4900 series which have a signature of 0x000306e4. I have no clue what the PF_MASK means(maybe restrict to E7 only?) though. I have used the VMWare microcode update tool to update the microcode on Windows, and the operation completed successfully. Without the option to reboot the computer(lots of stuff unsaved), I ran get-speculationcontrolsettings again but there were no differences(Everything is false except the requirement for VA shadowing). I did not install the Windows Update yet for meltdown. Does this mean the microcode is updated but no 'fix' is applied? Any input is appreciated.
LConstantin - 6 years ago
The VMware Driver option doesn't work because it starts too late in the kernel initialization process (it's a kernel driver). Microcode updates need to be reapplied at every boot, because the CPU doesn't have non-volatile memory. It's normally the BIOS that applies it during boot so by the time the OS starts, the OS will see the new microcode. In this case, the WIndows kernel sees the old microcode before the VMware Driver kicks in and applies it. Because of this it disables its own software-based Spectre mitigation. The VMware driver can be used to test if the microcode update for your CPU contains the Spectre patch, but that's about it. It won't actually be used. The result from Microsoft's Speculation Control Validation PowerShell Script will look like this:
Hardware support for branch target injection mitigation is present: True <-- microcode contains the patch
Windows OS support for branch target injection mitigation is present: True <-- Software patch present. Windows update installed.
Windows OS support for branch target injection mitigation is enabled: False <-- Support disabled because the microcode update got applied too late
and lower:
BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
weareanomalous - 6 years ago
Yep, I realized it after reading comments in the VMWare tool's page itself. I still have a few doubts though:
1) Back in 2015, Windows also had a microcode update. How is that mechanism different from the tool? Or is it also loaded afterwards just like this tool? If the former is relevant, could we modify the tool to behave like such instead?
2) Can't we install a bootloader to load the microcode first before letting Windows kick in? I remember a similar technique used to spoof licensing certificates for Windows 7. Anyway secure boot can be disabled for this operation.
3) Is the sole purpose of the microcode update just to allow OS mitigation to load? Does it have any mitigation functions by itself?
If Microsoft does not send out the microcode update, I guess I will have to switch to Linux on that machine in order to benefit from the enhanced security provided by the microcode update.
LConstantin - 6 years ago
1) Microsoft's mechanism is likely different. They have full control over the boot process and can choose how early to push the microcode.There are some options to modify the VMware Driver to load earlier, but some other people tried and didn't succeed. I'm not an expert in this, but this might be because it was designed as a kernel driver, not a bootloader driver. This means it is dependent on the kernel being initialized and it's too late at that point because Microsoft runs their Spectre check earlier.
2) Not sure about the bootloader option. You might need a driver developer to answer that. Might be possible, but yeah, Secure Boot likely needs to be disabled. I know there are some disk encryption applications that have bootloader drivers.
3) No, the microcode update makes changes to the CPU's features, but Windows also needs changes to know how to use those features. The latest Windows update adds this capability, but it doesn't get turned on if Windows doesn't detect the hardware support in the CPU. As for other benefits, VMware's Tim Mann said in those comments "I think the Fling does work if all you need is for guest OSes running in VMware VMs on the machine (with the latest VMware Workstation updates we just released) to see the new hardware support." So it could help if you have guest OSes in VMware. If you had a very old microcode, this latest version might have other fixes that Windows will benefit from, just not the Spectre patch.
I don't think Microsoft will deliver the microcode updates through Windows Update. Maybe they don't want to be blamed if something goes wrong and so far things are going wrong. Intel just admitted the microcode updates for some of the CPUs are causing reboots. Lenovo has also started withdrawing BIOS/UEFI updates with those microcodes that it had already released. Some users who installed them will have to do UEFI downgrades. It's quite a mess. Probably best to wait and see for now, but yeah, Linux does sound like a good option and run Windows in a VM if you need it.
weareanomalous - 6 years ago
Interesting. Wonder if I can disable signing and enter test mode to shoehorn this latest firmware in by modifying the 2015 microcode installer a bit(my theory is that the update also uses a microcode.dat file, and I might be able to do a swap in one way or another). Not very confident it would work though. Meanwhile, I updated VMWare workstation and is in progress of updating the virtual machines as well. The Linux/Windows VMs certainly seems to be hardend with the Spectre patch, which is good news. Any recommendations for Linux Hypervisors in case I need to jump ship and axe Windows on that machine? I would prefer something as robust as VMWare Workstation, and I would also appreciate if the old VMs can be ported to the new hypervisor.
Edit: I have found out a tool that can modify the UEFI to incorporate the new microcode in the UEFI. Trying that now, will post updates later.
Edit #2: Uninstalled the Software patch. I used the tool found on win-raid forums that helps to update the microcode for the .cap BIOS files automatically(leveraging MMTool 5.0.0.7), and promptly ran Asus USB flashback(for certain motherboards with the designated button only, otherwise you need to use the DOS way because this BIOS is modded and updating through UEFI itself will not work) with success. Now on get-speculationcontrolsettings, it reads:
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: False [not required for security]
BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : True
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : False
Which is great news. It turns out that X79(Ivy Bridge-E/EP only, but heck if you are running SB-E just get IB-EP Xeons on eBay for cheap) users can still be fully protected. If I experience restart problems just like Haswell/Broadwell users later down the road, I will update here(probably as a new post) as well.
LConstantin - 6 years ago
If you have an AMI BIOS, you can use MMTool (use version 4 for Aptio 4 UEFI and 5 for later) to add the microcode for your CPU after you extract it from the microcode.dat. However, as you probably know this is not without risk and you could brick your motherboard. Also, most BIOS modification tools are for desktop boards and carry a greater risk when used on laptops with mobile CPUs/chipsets, though it depends on the modification. Be careful and good luck.
weareanomalous - 6 years ago
Don't worry bud, I have already patched it with success. In fact, I am typing this comment on the updated machine right now. As for bricking the motherboard, it is less likely going to happen if your motherboard have the BIOS flashback button (you can try again and again). Never knew it came in so handy. The only thing to worry about is the potential restart problem, if it secretly affects Ivy Bridge-E too.
weareanomalous - 6 years ago
Update: Hibernated the system last night and when I power it on today there was an unexpected shutdown/reboot. Will monitor the situation further. Seems like Ivy Bridge-E might also be affected by the reboot problem.
Event viewer came out with: Windows failed to resume from hibernate with error status 0xC0000411
Probably the final update: Turns out it is not the reboot problem which will result in CPU errors. It ended up being the Hiberfile.dll being corrupt instead, and using powercfg to switch it off and back on again solved the problem. Now the system is 100% stable, albeit with a ~20% hit in synthetic CPU benchmarks such as Cinebench. I would now still recommend Ivy Bridge-E users to perform the mod.
Exnor - 6 years ago
At best poor researched but not fake news.... get a grip please.
softeyes - 6 years ago
Grinler, great information! Your expertise and your commitment in keeping the technology community abreast with breaking news is to be applauded. Thank you.
Nick, kudos for your expertise with all things Linux, and also helping all of us out in every forum in BleepingComputer! (Especially sorting out this Meltdown & Spectre vulnerability in the Linux forum and also Windows.) Thank you.
Sole78855 - 6 years ago
Grinler, I admit I went too far with calling the article "fake news". I thought the article was misleading in its original state by giving the false sense of security for all Intel processor owners back to Pentium III.
In reality I was frustrated (and I still am) with Intel not providing updated microcode for processors ranging from Core 2 Duo/Quad to Sandy/Ivy Bridge which are the base of many capable machines providing very good performance for light to medium workloads - thus forcing their owners to either abandon them and upgrade or live with wide open security holes. I hope Intel change their stance very soon.
I realize Meltdown/Spectre microcode mitigation for those older processors may have much larger impact on performance due to hardware supported instructions in those older processors (or the lack thereof) and the way the mitigations are implemented but I prefer to have a choice at least.
NickAu - 6 years ago
Quote
.."You can see an example of how NickAu, one of the BleepingComputer moderators, installed the updates manually in Ubuntu "
Some call it manually, I call it the Linux way, Terminal is a Linux users best friend.
OMG am I turning into a crusty old " you must use terminal in Linux, if you want to point and click use Windows " types?
Mehmet_Kececi - 6 years ago
There was only a 22% improvement. The others are still standing.