Talk:Intel microcode

Outdated information in the article[edit]

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. — Preceding unsigned comment added by 200.160.13.171 (talk • contribs) 11:42, 4 October 2018 (UTC)[reply]

Go ahead and update it. Guy Harris (talk) 20:10, 4 October 2018 (UTC)[reply]

I know I'm not supposed to add primary sources, but the old Pentium Pro/II format and encryption is now publicly documented in my work at https://github.com/peterbjornx/patchtools_pub . This might be useful to anyone editing this in the future and this is also relevant to the 'only a small number of people knows the encryption' bit of the article Peterbjornx (talk) 00:41, 3 November 2020 (UTC)[reply]

LDAT[edit]

"unpublished container format" It is now decoded! https://github.com/chip-red-pill/glm-ucode 94.29.3.116 (talk) 15:32, 26 May 2020 (UTC)[reply]

94.29.3.116: have added a couple of lines/paper citations—these five arrays are being dumped directly out of the live running CPU (using the low-level hardware Direct Access Testing (DAT) facility normally used at the factory). It would be interesting to see both a known firmware update and the corresponding pre-/post- update RAM contents. The precise format/crypto for access via the front door is not *yet* known (though with that level of access, then there is not requirement to use the front door!). —Sladen (talk) 19:06, 26 May 2020 (UTC)[reply]

LOL, no we do not use DAT! We just use JTAG with USB-A (-C) -- USB-A (-C) with debugging capabilities and then use an exploit to get the Red unlock and then get the access to CRBUS ;) But yeah, DAT is also cool)) 2A00:1370:812C:1186:90EB:FA1:455C:CCD8 (talk) 23:08, 26 May 2020 (UTC)[reply]

The functions in https://github.com/chip-red-pill/crbus_scripts/blob/master/ldat.py functions are named ldat_array_read() and ldat_array_write(). Is that incorrect?
When (hopefully soon?) there is a proper paper out, we can cite that directly. —Sladen (talk) 11:56, 27 May 2020 (UTC)[reply]

We did not use Direct Access Testing (DAT) facility. 2A00:1370:812C:1186:A099:D654:40E7:4C1F (talk) 16:42, 27 May 2020 (UTC)[reply]

Notes[edit]

From reading [1]:

Functionality available in Skylake (microarchitecture)
Direct Connect Interface (DCI) must be enabled on the target machine "taken as user consent to enable the DCI which allows debug over the USB3 interface"
Setting stored in Platform Controller Hub (PCH) 0x4 `ECTRL` register ("DCI Host Control register") depending on bit 4 `HDCIEN` ("Host DCI Enable")
Requires Intel Extensible Host Controller Interface (XHCI)
Reuses USB 3.0 pins
…vastly more steps/abstraction layers

—Sladen (talk) 19:07, 27 May 2020 (UTC)[reply]

Better quote this: https://github.com/ptresearch/IntelTXE-PoC#preparing-the-usb-debug-cable But there is no info on LDAT port yet. 2A00:1370:812C:1186:15E2:FAB5:7B92:CA9C (talk) 21:24, 27 May 2020 (UTC)[reply]