Intel-Linux-Processor-Microcode-Data-Files

https://github.com/intel/intel-linux-processor-microcode-dat... $ echo 1 > /sys/devices/system/cpu/microcode/reload Hot-swappable, even. TIL!

Researchers say this is CVE-2024-45332. INTEL-SA-01247 covers that CVE. Microcode release 20250512 has that INTEL-SA mitigated. https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... https://www.intel.com/content/www/us/en/security-center/advi...

Intel distributes microcode updates for Linux here: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... , and the distro are all set up to pull from there and distribute automatically. Not expert enough to know what to look for to see if these particular mitigations are present yet.

So where is the microcode update? I don't see anything for Linux yet. https://github.com/intel/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 in

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

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