What does HackerNews think of Intel-Linux-Processor-Microcode-Dat?

They have been partially reversed and ==maybe== definitely cracked, but it doesn't matter. The web or chain of trust of those updates from the vendor to the processor is what matters. They're at least CRC checked to prevent loading corrupt files.

Intel microcode update secret key revealed

https://arstechnica.com/gadgets/2020/10/in-a-first-researche...

https://ieeeaccess.ieee.org/featured-articles/reverseenginee...

https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

https://github.com/platomav/CPUMicrocodes

It would take state actor-level effort to install APTs as firmware or microcode updates. Microcode updates are the smallest target because they don't survive power outages. Attacking the TPM, BIOS, SSD, accessory ICs, or supply chain would be more useful.

> How bad is this exactly?

7.1 out of 10

https://www.intel.com/content/www/us/en/security-center/advi...

This was part of IPU 2021.2 in November and other bugs in other CPUs were fixed as well, one rated 8.2 affecting many, but not all, intel cpus (intel-sa-00562). If you haven't updated your UEFI/BIOS since last November and you love to run untrusted code by untrusted third parties on your CPU, the larger story about microcode bugs and privilege escalation into the management engine is bad and best fixed keeping up to date with microcode updates.

Please note that the IPU 2021.2 fixes are not runtime loadable: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... and require an UEFI/BIOS update.

The concrete story is mostly about a problem with the Atom line, which allowed code execution in the IME and a full dump of it. Very interesting for nerds that want to hack into that for reasons of taking ownership of what they bought, less interesting for malware, but not irrelevant. The link is about the Chip Red Pill Team giving a talk about how they broke the Atom and what intel hides inside.

It is a good talk by people who have years of experience cracking open Intels chips. I can recommend it to anyone who cares about that.

From a news perspective however it is three month old, if we ignore the zero nights russia talk in September ;-)

Is it any more of a "magic incantation" than the linux-image-XYZ package which controls which OS kernel is installed? Or the linux-firmware package which controls what firmware gets loaded on various devices?

If you want to see when Intel issues new microcode updates, it is all available on their GitHub: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

Yes, some former releases at least via https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... is what I use during some of my past/present Linux testing

Thankfully I do save all of the microcodes, so I can just use an early version by simply rebuilding the initramfs. I also hold that package back on Arch, so it does not get upgraded.

Might want to look for them here: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

As to how to actually use those files to get your "intel-ucode.img", just take a look at: https://archlinux.org/packages/extra/any/intel-ucode/

For the "iucode_tool": https://gitlab.com/iucode-tool/iucode-tool/-/wikis/home

The actual PKGBUILD for it on Arch Linux: https://github.com/archlinux/svntogit-packages/blob/packages...

---

  cd Intel-Linux-Processor-Microcode-Data-Files-microcode-${pkgver/./}
  rm -f intel-ucode{,-with-caveats}/list
  mkdir -p kernel/x86/microcode
  iucode_tool --write-earlyfw=intel-ucode.img intel-ucode{,-with-caveats}/

The above gives you "intel-ucode.img". Copy it to "/boot/". Run "mkinitcpio -p linux" or the like.

It isn't clear if Haswell has this optimization. As an easy test you could run the zero-fill-bench linked in the post and check the fill0 vs fill1 numbers. If they are the same, Haswell probably never had this optimization in the first place.

Based on the Intel microcode release note [1] it doesn't seem like client HSW got any update this time, only HSX (Haswell Xeon).

---

[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

> > according to Intel, it happened only when the microcode was loaded by the kernel; they probably had tested only loading it from the firmware

> I followed the Spectre situation quite closely, and never heard anything along those lines. Do you have a source?

Sure, it was this one: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

"Intel identified an issue when OS loading microcode update revision 0xDC for cpuid 406E3 and 506E3. The microcode update has been reverted to revision 0xD6. This issue does not affect the microcode update when loaded from BIOS."

> When there's a bug in the CPU microcode, you're at the mercy of your motherboard vendor to release a new system BIOS that will update it for you—you can't just go to some download link at AMD and apply a fix yourself.

At least on Linux, that's not true. Intel publishes microcode updates on Github [1] (and distros package it) and AMD has it upstreamed in linux-firmware [2], so you don't have to rely on motherboard vendors at all.

[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

[2] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...