Talk:Intel microcode

Lots of extremely outdated info on this article.

Canonical reference of the update format *and* update process (no, it is not 2048 bytes anymore, it can go to megabytes, although Intel has not broken the 128KiB barrier *yet*): The Intel 64 and IA‐32 Architectures Software Developer's Manual, Volume 3A: System Programming Guide, Part 1 (order number 253668), section 9.11.

The "BIOS update interface" that used to allow one to update the microcode tables inside the BIOS using DOS real-mode INT calls, is long gone though.

The 16-byte alignment is not required on any non-ancient Intel processor. The initramfs-based microcode update done by Linux would instantly fail[1] if this requirement was still true. non-ancient processors seem to need a 4-byte alignment, only. [1] on Linux-based disitrutions that use the iucode_tool tool to generate the initramfs image for microcode updates, padding is added that will ensure the 16-byte alignment. But lots of Linux distros don't use it, so they are guinea pigs that will tell us if the 16-byte alignment requirement comes back from the grave :)

Source: iucode_tool 2.3.1 manpage.

Format details: Intel unified microcode update packages (MCUs) are a public container format (fully described in the intel manual cited above) that wraps around a high-level, internal, unpublished container format. Intel has changed that internal format numerous times as their processors evolved, from the original 2048-byte MCROM-update-only package of the original P6, to the current format that is an archive of several separate update units (header and crypto info, MCROM update, PMU firmware update, etc), each with its own compression and format. A modern Intel MCU can update any of the [updateable] subsystems inside the processor package, so it is not just about patching the MCROM anymore.

Source: MC extractor documentation.