Intel has released new CPU microcode for download | Hacker News Reader

Intel has released new CPU microcode for download

downloadcenter.intel.com

214 pointssmcleod106 comments

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

Awesome! Thanks for this!

And slow down my computer? No thanks.

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.

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.

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.

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.

Doesn't the microcode expose new MSRs to control branch prediction? If you don't want to, don't clear the cache.

It's hard to make sense of what Intel are doing in the ucode since communication has been so poor, but "LFENCE terminates all previous instructions" has been variously reported, and there are rumblings that RET or conditional jumps have been changed too. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886367#17

Intel deserves an extra pwnie award just for the way they handle ucode without changelogs.

No disagreement that reverse engineering Linux patches is not the optimal disclosure policy.

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

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

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

For Windows there is also this:

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

I have never tried it though.

Wouldn't a live CD/USB also work?

I believe the one from my link is lost between reboots.

Windows does not seem to deliver microcode fixes except for the Surface.

The microcode update is always lost between reboots. This is e.g. why the Linux kernel can update the microcode during early boot.

The only way to make microcode updates stick between reboots is with a BIOS/EFI firmware update (some vendors provide firmware updates with microcode updates.). Then the microcode update gets applied during every boot automatically.

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

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

Thanks, and on RHEL/CentOS/Fedora:

  dracut -f

You forgot to say "on Linux".

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

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

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?

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.

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?

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.

In a cluster, all hosts must be updated for the flags to be exposed to the guests. That is why you must update vCenter first, which prevents the patched hosts from being rejected.

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.

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

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

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.

Skylake-X?

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.

From the command 'cpuid'

I believe the [XX]-[XX]-[XX] is:

<extended family><family>-<extended model><model>->stepping id>

Those values are all in the first few lines of output from 'cpuid'.

The [XX]->[XX] is probably [old microcode version]->[new microcode version]

If the cpuid for a processor is not listed in those release notes, I don't think there's a reason to believe the processor has received a microcode update. It might be worth comparing the microcode blob to Intel's last release in 2017-11 to confirm.

It looks to me like the microcode version can be read out from

hexdump <XX-XX-XX from .tgz> | head -n1 | cut -f4,5 -d' '

where the first field is the lower 16 bits and the second field is the upper 16 bits. I don't have any documentation to prove this assumption, it is just based on comparing the listed microcode versions to those fields in the binary blobs. But doing a straight 'diff' would probably be good enough to tell if the microcode file has changed.

Some Linux vendors like CentOS, Debian and Ubuntu may have microcode updates for processors that weren't part of this release, I'm not sure.

I hate to say it, but I'm also finding myself scratching my head at this one. I've randomly chosen 3 separate Xeon E5 family processors that are in production, and _each time_ I look at the intel-ucode files, _absolutely none_ of the family-model-stepping outputs from lscpu/dmidecode match.

I'd guess that the format above (using HSW-ULT Cx/Dx as an example), that 01:72 means stepping 1 through 72?

Just an update in case that someone is experiencing something similar.

1.) If using RHEL, most likely the latest microcode updated offered via RHEL entitlements will contain the requisite updates.

2.) Slapping myself over this one(!), but the family, model, and stepping ID's need to be changed to hex. I confirmed this via inspecting a node which was patched using the latest updates (kernel & microcode) from RHEL; I am now able to verify that the majority of the microcode offered by Intel appears to be ready to go.

These are the updates, sorted by microcode update date, with a cursory look at the generation:

sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=263907 Skylake Core

sig 0x000506e3, pf_mask 0x36, 2017-11-16, rev 0x00c2, size 99328 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=329443 Skylake Core & Xeon

sig 0x000306f4, pf_mask 0x80, 2017-11-17, rev 0x0010, size 17408 Haswell-EX

sig 0x00040671, pf_mask 0x22, 2017-11-17, rev 0x001b, size 13312 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=263793 Broadwell Core

sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=198356 Broadwell Core

sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=198386 Haswell Core & Xeon

sig 0x00040661, pf_mask 0x32, 2017-11-20, rev 0x0018, size 25600 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=263777 Crystal Well Core

sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=263761 Haswell Core

sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=198339 Haswell Core & Xeon

sig 0x000306e4, pf_mask 0xed, 2017-12-01, rev 0x042a, size 15360 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=198372 Ivy Bridge Core & Xeon

sig 0x00050654, pf_mask 0xb7, 2017-12-08, rev 0x200003c, size 27648 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=329300 Skylake Core

sig 0x00050662, pf_mask 0x10, 2017-12-16, rev 0x0014, size 31744 Broadwell

sig 0x00050663, pf_mask 0x10, 2017-12-16, rev 0x7000011, size 22528 Broadwell

sig 0x000706a1, pf_mask 0x01, 2017-12-26, rev 0x0022, size 73728 Gemini Lake

sig 0x000906ea, pf_mask 0x22, 2018-01-04, rev 0x0080, size 97280 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=591594 Coffee Lake Core

sig 0x000806e9, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=526057 Kaby Lake Core

sig 0x000806ea, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=526058 Kaby Lake Core

sig 0x000906e9, pf_mask 0x2a, 2018-01-04, rev 0x0080, size 98304 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=591593 Kaby Lake Core & Xeon

sig 0x000906eb, pf_mask 0x02, 2018-01-04, rev 0x0080, size 98304 http://www.cpu-world.com/cgi-bin/CPUID.pl?&SIGNATURE=591595 Coffee Lake

I believe the oldest processors in the list are the Ivy Bridge sig=0x306e4. That includes E5-xxxx v2 Xeons, circa 2013.

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.

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

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.

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-... and to get my family/model/stepping I used https://www.intel.com/content/www/us/en/support/articles/000...

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

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?

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.

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.

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.

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

> Or something as grave as the famous empty password root backdoor.

You mean the issue that was fixed quite a while ago now ?

I really don't understand the logic behind your position. OSX really is as buggy as it's always been. At least it's buggy with the latest security fixes applied.

While alot has happened recently, I wouldn't consider 4-5 weeks a "while ago". It was an egregiously stupid bug that should have never happened.

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 the Security Update 2017-005 contains fixes for Meltdown.

Update 2: According to 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.

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)

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.

Some of the hypervisor fixes were dependent on the new microcode

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

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

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

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

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

Does AMD also need some microcode update for this?

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.

So I guess just kernel updates for Spectre are needed.

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

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.

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

Only what Intel provides, the updates are AFAIK encrypted.

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.

It's being reverse engineered as we speak. Great CCC talk from a couple of weeks ago: https://www.youtube.com/watch?v=lY5kucyhKFc

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.

This might be interesting reading for you: http://inertiawar.com/microcode/

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

Thanks that was an absolutely fascinating read!

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

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

You need both.

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

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

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

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

Not listed :/

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?

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.

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

Supermoto bios updates: https://www.supermicro.com/support/security_Intel-SA-00088.c...

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

Nah, they list all the models around it, like the L5640. This is basically the same CPU with 100MHz shaved off it.

They're system-pulls off eBay, and appear to be some specialist OEM part - note they don't appear on ark, they go L5630 straight to L5640.

no debian 9?

    apt-get install intel-microcode

https://wiki.debian.org/Microcode

then follow the "releasenote".

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

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.

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?

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.

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.

This is an excellent explanation. Thank you.

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.

Is intel-microcode not part of the linux-firmware package on Debian based distros?

It does say "Debian Linux*", which I take to include Debian 9.

says debian 8.* and 7.* which i take to mean 8.1 and 7.1, expressly excluding 9

The star is Intel's weird house style for trademarks. They add a star to any third-party trademark, and in the footer there's "* Trademarks", which links to https://www.intel.com/content/www/us/en/legal/trademarks.htm...

Wait for the package to be ready there: http://ftp.us.debian.org/debian/pool/non-free/i/intel-microc...

( the version of your OS doesn't matter, it's working for any Ubuntu / Debian release )

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?

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

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

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

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.

On debian at least microcode updates arent included by default you have to install the appropriate package (intel vs amd)

# Download new release of microcode from 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/SpectreAn...

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.

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

Reply on news.ycombinator.com