10 ms·

Intel has released new CPU microcode for download

214 points by mrmondo 9y ago

phantom_oracle 9y ago
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?
- djsumdog 9y ago
  I say it'd always best practice to update things via the standard package manager. I'm sure debain/RHEL/cent repos already have updated kernels for the PTI fix. Unless you are seriously hitting hard performance issues with the new kernels (there's nothing in the firmware page that says if this is for Meltdown or Spectre, or did I miss it?), wait for your distribution to update its linux-firmware package. People on the unstable branches will get to test it first and give appropriate feedback before it gets marked stable, and there will also most likely be a delay before a kernel is released that re-enabled PTI (once again, if this is a PTI/Meltdown fix).
- pasbesoin 9y ago
  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 9y ago
    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
- noobermin 9y ago
  While I understand your sentiment, probably the best action is to do the default, which is to wait for an update from your package manager/OS. The news on HN is, well news, so it's often fresh and breaking news. Acting on said news entails its own risks unless you know what you're doing, and there aren't ambiguities which may bork your computer.
  - stephenr 9y ago
    On debian at least microcode updates arent included by default you have to install the appropriate package (intel vs amd)
- navinsylvester 9y ago
  # Download new release of microcode from https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File https://downloadcenter.intel.com/download/27431/Linux-Proces... # Copy intel-ucode directory to /lib/firmware # echo 1 > /sys/devices/system/cpu/microcode/reload # update-initramfs -u # Reboot Also check - https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
- pvg 9y ago
  No it doesn't, since that kind of thing is not what HN is for and there are many places that are. It does need fewer people typing breathlessly in all caps a lot.
Freaky 9y ago
CPU: Intel(R) Xeon(R) CPU L5639 @ 2.13GHz Not listed :/
- milofeynman 9y ago
  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 9y ago
    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 9y ago
      You don't need to wait for BIOS updates to install microcode - install sysutils/devcpu-data and sysrc microcode_update_enable=YES
    - NathanOsullivan 9y ago
      Supermoto bios updates: https://www.supermicro.com/support/security_Intel-SA-00088.cfm https://www.supermicro.com/support/security_Intel-SA-00088.c...
- Twirrim 9y ago
  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
  - 9y ago
mrmondo 9y ago
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 9y ago
  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 9y ago
    Thanks, and on RHEL/CentOS/Fedora: dracut -f
- snvzz 9y ago
  You forgot to say "on Linux". For Dragonfly instructions see: https://www.dragonflydigest.com/2018/01/09/20710.html https://www.dragonflydigest.com/2018/01/09/20710.html
newman314 9y ago
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.html https://www.vmware.com/us/security/advisories/VMSA-2018-0004...
- rconti 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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.
krisives 9y ago
Is there any meaningful way to know what the differences are between previous microcodes?
- TheChaplain 9y ago
  Only what Intel provides, the updates are AFAIK encrypted.
  - kzrdude 9y ago
    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.
    - morio 9y ago
      It's being reverse engineered as we speak. Great CCC talk from a couple of weeks ago: https://www.youtube.com/watch?v=lY5kucyhKFc https://www.youtube.com/watch?v=lY5kucyhKFc
      - jcranmer 9y ago
        AFAIK, that's referring to AMD microcode, not Intel. The problem with reverse engineering modern AMD and Intel microcode is that the updates are signed and encrypted, so you can't do the necessary probing to see what's going on under the hood.
    - userbinator 9y ago
      This might be interesting reading for you: http://inertiawar.com/microcode/ http://inertiawar.com/microcode/ Signed with 2048-bit RSA, and probably encrypted too.
      - rkagerer 9y ago
        Thanks that was an absolutely fascinating read!
noncoml 9y ago
If they can fix it in microcode, why did they have to patch the kernel?
- ajdlinux 9y ago
  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.
- kelnos 9y ago
  Meltdown/Spectre is actually 3 different, but related, vulnerabilities, each with different mitigations/workarounds.
dreamcompiler 9y ago
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 9y ago
  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 9y ago
    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.
    - username223 9y ago
      You (and colleagues) must have a strange workload. Despite my misgivings about an in-place file system change, the switch to 10.13 was pretty much painless. I use software from the latest Apple stuff, to aging programs from Adobe and other third parties, to GNU Emacs, to scripts written decades ago, so it doesn't seem like general breakage.
      - mschuster91 9y ago
        > You (and colleagues) must have a strange workload. Sometimes it's something as easy as installing the printer driver for a C1028i printer. On 10.13, it's stuck on "Configuring printer" forever. The printer driver is the currentmost available from the vendor, and the OS fully patched. Or something as grave as the famous empty password root backdoor. This alone is sufficient for me to not upgrade as long as possible - when something like this manages it into production, what else got missed?
        9y ago
pero 9y ago
no debian 9?
- itomato 9y ago
  apt-get install intel-microcode https://wiki.debian.org/Microcode https://wiki.debian.org/Microcode then follow the "releasenote".
  - orblivion 9y ago
    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).
    - chungy 9y ago
      Debian removes binary blobs from the kernel, putting them into separate microcode and firmware packages in non-free instead. Intel places restrictions against reverse engineering the microcode, as well as it not being in the prefered original source. Both of these violate the Debian Free Software Guidelines, and thus it can only be in non-free at best.
      - orblivion 9y ago
        I thought you need the microcode to boot. How can you function in a non-free OS? And I guess non-free people will have these bugs now? Also, I have basic Ubuntu. I'm running `apt list --installed` and I don't have the microcode package in the list. Does that command not list dependencies, or am I just missing it?
        chungy 9y ago
        The CPU has a built-in baseline microcode that it uses on every boot (runtime microcode updates are not persistent), OSes don't need to necessarily update it, but they can.
transpute 9y ago
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-Microcode-Repositories.html 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 9y ago
  I always assumed they were not just signed but encrypted, and padded to avoid meta analysis. Is that not the case?
  - monocasa 9y ago
    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
- chrisper 9y ago
  For Windows there is also this: https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver#summary https://labs.vmware.com/flings/vmware-cpu-microcode-update-d... I have never tried it though.
  - fred_is_fred 9y ago
    Wouldn't a live CD/USB also work?
bcantrill 9y ago
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 9y ago
  Awesome! Thanks for this!
- 1000units 9y ago
  And slow down my computer? No thanks.
  - djsumdog 9y ago
    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 9y ago
      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.
caffeineninja 9y ago
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 9y ago
  Some of the hypervisor fixes were dependent on the new microcode
efoto 9y ago
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-Processor-Microcode-Data-File 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-Processor-Microcode-Data-File?product=873 https://downloadcenter.intel.com/download/27431/Linux-Proces...
sasojaso 9y ago
Does this release has anything to do with Linux P page table isolation patches (http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table http://pythonsweetness.tumblr.com/post/169166980422/the-myst...)?
deleted 9y ago
[deleted]
ars 9y ago
Wish Intel would say if this does anything useful without also updating the Kernel, or do you have to have both.
- em3rgent0rdr 9y ago
  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.
shmerl 9y ago
Does AMD also need some microcode update for this?
- kijiki 9y ago
  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 9y ago
    So I guess just kernel updates for Spectre are needed.
    - kijiki 9y ago
      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...
kyledrake 9y ago
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 9y ago
  > 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.
  - chx 9y ago
    IVT is Ivytown aka. Ivy Bridge EX (past Xeon codenames: Clovertown, Gulftown, Harpertown, Jaketown, Gainestown -- although not all *town codenames covered Xeons, a lot did). All of these are easy to figure abbreviations of Intel code names, perhaps the newest ones a bit harder because we are not as used to them yet (CFL for Coffee Lake, GLK for Gemini Lake -- both of which are probably class action lawsuit targets as they shipped after Intel was told).
  - rincebrain 9y ago
    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.
phire 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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-bios/ https://www.delidded.com/how-to-update-cpu-microcode-in-ami-... and to get my family/model/stepping I used https://www.intel.com/content/www/us/en/support/articles/000005651/processors.html https://www.intel.com/content/www/us/en/support/articles/000...
- vbernat 9y ago
  Not all listed processors got an update. If you look at SandyBridge E, the associated microcode is still from 2013.
deleted 9y ago
[deleted]
alexbakker 9y ago
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.
chiluk 9y ago
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.
djmips 9y ago
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/000005651/processors.html 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-bios/ 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.
perrodelcamimo 9y ago
Viva la Mechita...23788986589
perrodelcamimo 9y ago
Viva la Mechita!!!! 356324789 6 3255 56834 @BT
karakarga 9y ago
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?
omshiriya 9y ago
Downloads for Intel® Xeon® Processor E5-2630 (15M Cache, 2.30 GHz, 7.20 GT/s Intel® QPI)

214 points by mrmondo 9y ago

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?

djsumdog 9y ago
I say it'd always best practice to update things via the standard package manager. I'm sure debain/RHEL/cent repos already have updated kernels for the PTI fix. Unless you are seriously hitting hard performance issues with the new kernels (there's nothing in the firmware page that says if this is for Meltdown or Spectre, or did I miss it?), wait for your distribution to update its linux-firmware package. People on the unstable branches will get to test it first and give appropriate feedback before it gets marked stable, and there will also most likely be a delay before a kernel is released that re-enabled PTI (once again, if this is a PTI/Meltdown fix).
pasbesoin 9y ago
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 9y ago
  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
noobermin 9y ago
While I understand your sentiment, probably the best action is to do the default, which is to wait for an update from your package manager/OS. The news on HN is, well news, so it's often fresh and breaking news. Acting on said news entails its own risks unless you know what you're doing, and there aren't ambiguities which may bork your computer.
- stephenr 9y ago
  On debian at least microcode updates arent included by default you have to install the appropriate package (intel vs amd)
navinsylvester 9y ago
# Download new release of microcode from https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File https://downloadcenter.intel.com/download/27431/Linux-Proces... # Copy intel-ucode directory to /lib/firmware # echo 1 > /sys/devices/system/cpu/microcode/reload # update-initramfs -u # Reboot Also check - https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
pvg 9y ago
No it doesn't, since that kind of thing is not what HN is for and there are many places that are. It does need fewer people typing breathlessly in all caps a lot.

Freaky 9y ago

CPU: Intel(R) Xeon(R) CPU L5639 @ 2.13GHz Not listed :/

milofeynman 9y ago
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 9y ago
  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 9y ago
    You don't need to wait for BIOS updates to install microcode - install sysutils/devcpu-data and sysrc microcode_update_enable=YES
  - NathanOsullivan 9y ago
    Supermoto bios updates: https://www.supermicro.com/support/security_Intel-SA-00088.cfm https://www.supermicro.com/support/security_Intel-SA-00088.c...
Twirrim 9y ago
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
- 9y ago

mrmondo 9y ago

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 9y ago
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 9y ago
  Thanks, and on RHEL/CentOS/Fedora: dracut -f
snvzz 9y ago
You forgot to say "on Linux". For Dragonfly instructions see: https://www.dragonflydigest.com/2018/01/09/20710.html https://www.dragonflydigest.com/2018/01/09/20710.html

newman314 9y ago

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

rconti 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.

krisives 9y ago

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

TheChaplain 9y ago
Only what Intel provides, the updates are AFAIK encrypted.
- kzrdude 9y ago
  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.
  - morio 9y ago
    It's being reverse engineered as we speak. Great CCC talk from a couple of weeks ago: https://www.youtube.com/watch?v=lY5kucyhKFc https://www.youtube.com/watch?v=lY5kucyhKFc
    - jcranmer 9y ago
      AFAIK, that's referring to AMD microcode, not Intel. The problem with reverse engineering modern AMD and Intel microcode is that the updates are signed and encrypted, so you can't do the necessary probing to see what's going on under the hood.
  - userbinator 9y ago
    This might be interesting reading for you: http://inertiawar.com/microcode/ http://inertiawar.com/microcode/ Signed with 2048-bit RSA, and probably encrypted too.
    - rkagerer 9y ago
      Thanks that was an absolutely fascinating read!

noncoml 9y ago

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

ajdlinux 9y ago
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.
kelnos 9y ago
Meltdown/Spectre is actually 3 different, but related, vulnerabilities, each with different mitigations/workarounds.

dreamcompiler 9y ago

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 9y ago
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 9y ago
  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.
  - username223 9y ago
    You (and colleagues) must have a strange workload. Despite my misgivings about an in-place file system change, the switch to 10.13 was pretty much painless. I use software from the latest Apple stuff, to aging programs from Adobe and other third parties, to GNU Emacs, to scripts written decades ago, so it doesn't seem like general breakage.
    - mschuster91 9y ago
      > You (and colleagues) must have a strange workload. Sometimes it's something as easy as installing the printer driver for a C1028i printer. On 10.13, it's stuck on "Configuring printer" forever. The printer driver is the currentmost available from the vendor, and the OS fully patched. Or something as grave as the famous empty password root backdoor. This alone is sufficient for me to not upgrade as long as possible - when something like this manages it into production, what else got missed?
      - 9y ago

pero 9y ago

no debian 9?

itomato 9y ago
apt-get install intel-microcode https://wiki.debian.org/Microcode https://wiki.debian.org/Microcode then follow the "releasenote".
- orblivion 9y ago
  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).
  - chungy 9y ago
    Debian removes binary blobs from the kernel, putting them into separate microcode and firmware packages in non-free instead. Intel places restrictions against reverse engineering the microcode, as well as it not being in the prefered original source. Both of these violate the Debian Free Software Guidelines, and thus it can only be in non-free at best.
    - orblivion 9y ago
      I thought you need the microcode to boot. How can you function in a non-free OS? And I guess non-free people will have these bugs now? Also, I have basic Ubuntu. I'm running `apt list --installed` and I don't have the microcode package in the list. Does that command not list dependencies, or am I just missing it?
      - chungy 9y ago
        The CPU has a built-in baseline microcode that it uses on every boot (runtime microcode updates are not persistent), OSes don't need to necessarily update it, but they can.

transpute 9y ago

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-Microcode-Repositories.html 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 9y ago
I always assumed they were not just signed but encrypted, and padded to avoid meta analysis. Is that not the case?
- monocasa 9y ago
  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
chrisper 9y ago
For Windows there is also this: https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver#summary https://labs.vmware.com/flings/vmware-cpu-microcode-update-d... I have never tried it though.
- fred_is_fred 9y ago
  Wouldn't a live CD/USB also work?

bcantrill 9y ago

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 9y ago
Awesome! Thanks for this!
1000units 9y ago
And slow down my computer? No thanks.
- djsumdog 9y ago
  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 9y ago
    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.

caffeineninja 9y ago

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 9y ago
Some of the hypervisor fixes were dependent on the new microcode

efoto 9y ago

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

sasojaso 9y ago

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

deleted 9y ago

[deleted]

ars 9y ago

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

em3rgent0rdr 9y ago
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.

shmerl 9y ago

Does AMD also need some microcode update for this?

kijiki 9y ago
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 9y ago
  So I guess just kernel updates for Spectre are needed.
  - kijiki 9y ago
    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...

kyledrake 9y ago

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 9y ago
> 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.
- chx 9y ago
  IVT is Ivytown aka. Ivy Bridge EX (past Xeon codenames: Clovertown, Gulftown, Harpertown, Jaketown, Gainestown -- although not all *town codenames covered Xeons, a lot did). All of these are easy to figure abbreviations of Intel code names, perhaps the newest ones a bit harder because we are not as used to them yet (CFL for Coffee Lake, GLK for Gemini Lake -- both of which are probably class action lawsuit targets as they shipped after Intel was told).
- rincebrain 9y ago
  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.

phire 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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-bios/ https://www.delidded.com/how-to-update-cpu-microcode-in-ami-... and to get my family/model/stepping I used https://www.intel.com/content/www/us/en/support/articles/000005651/processors.html https://www.intel.com/content/www/us/en/support/articles/000...
vbernat 9y ago
Not all listed processors got an update. If you look at SandyBridge E, the associated microcode is still from 2013.

deleted 9y ago

[deleted]

alexbakker 9y ago

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.

chiluk 9y ago

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.

djmips 9y ago

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/000005651/processors.html 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-bios/ 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.

perrodelcamimo 9y ago

Viva la Mechita...23788986589

perrodelcamimo 9y ago

Viva la Mechita!!!! 356324789 6 3255 56834 @BT

karakarga 9y ago

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?

omshiriya 9y ago

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