x86 Microcode Framework and Example Programs
This repository contains the framework used during our work on reverse engineering the microcode of AMD K8 and K10 CPUs. It includes an assembler and disassembler as well as example programs implemented using these tools. We also provide our custom written minimal operating system that can rapidly apply and test microcode updates on AMD CPUs.[…]
In case technical issues weren’t enough, the lawyers at Intel have apparently made it more difficult for some open source operating systems to use the latest Intel microcode.
PS: AMD is apparently still blocked at technical issues:
Patroklos (argp) Argyroudis has a new document on microcode reversing:
“Paper notes: Reverse engineering x86 processor microcode
14 Sep 2017”
“This repository contains a collection of x86 CPU microcode samples in binary and rtl form. The samples are compiled from scratch and specifically work with AMD’s K10 processor family.”
Finbarr P. Murphy has a new blog post which includes some new Linux-centric Python-based code that parses Intel microcode, to detect updates.
[…] It happens only with 0x6000832 ucode, and Piledriver-based CPUs: i.e. newer AMD FX, and Opteron 300 series (4300, 6300 etc.). The visible effects are in ~80% of cases incorrect RSP leading to bad ‘rets’ into kernel data/bss or stack-protector faults. But there are also more elusive ones, like registers being cleared before use in indirect memory fetches or so. I can trigger it from within qemu guest (non-root), causing bad RIP in the host kernel. When testing, a couple of times (maybe 2) out of maybe 30 seen oopses, I was able to set it to user-space addresses mapped in the guest. It greatly depends on timing, but I think with some more effort and populating kernel stack with guest addresses it’d be possible to create a more reliable qemu-guest to host ring0 escape. I CC’d some AMD engineers from this list, and on of them replied with “We are working on the final testing of a new microcode patch to replace 0x06000832.” but without specifying any errata no, or ETA for the new ucode. […]
There’s a new firmware-related github-hosted project out there, as of the last hour: bdw-ucode-update-tool by Benjamin Woodruff:
Broadwell μcode Update Installer: Intel i5-5675C, i7-5775C, and i7-5700HQ microcode updates extracted from MSI’s UEFI updates, along with a tiny zero-dependency install script for Linux users. Intel’s late Broadwell chips shipped with a whole slew of stability issues, causing Machine Check Exception kernel panics on Linux and BSODs on Windows. While Intel hasn’t directly distributed any new microcode updates since January, they’ve apparently distributed updates to some motherboard vendors. Until Intel updates the downloads on their site, I’ve extracted the updates from MSI’s firmware, using a custom python script. I don’t use Windows however, so I’ve only personally verified the first case. I also don’t have installation instructions for Windows, as I don’t know how to install custom microcode updates on Windows. […]
Interesting solution… IMO, it sounds like Intel should be solving this directly, not forcing end-users obtain it from other IBV’s blobs. 🙂 I wish there was a tool that could tell me if a system had the latest microcode from the vendor, and how I could check if the vendor had updates available.