Intel bios processor microcode update. A completely alternative way to update microcodes

Modern processors are complex devices that can have bugs. Furthermore, instead of executing x86 instructions directly, modern x86 processors contain internal code that implements support for the x86 instruction set. The internal code is called microcode. Microcode can be updated to fix or mitigate CPU bugs.

Some CPU bugs can make Firefox crash. For example, Firefox 57 and later is known to occasionally crash on Broadwell-U CPUs with old microcode in a manner not seen with newer Broadwell-U microcode versions.

Microcode updates can be loaded onto the CPU by firmware (usually called BIOS even on computers that technically have UEFI firmware instead of old-style BIOS) or by the operating system. Microcode updates do not persist across reboot, so in the case of a dual-boot system, if the microcode update isn't delivered via BIOS, both operating systems have to provide the update.

On Mac, to have an up-to-date system, apply all OS X system updates and Apple firmware updates offered in the Updates pane of the App Store app.

To allow Windows to load updated microcode onto the CPU, make sure Windows Update is enabled and set to install updates.

To see the processor microarchitecture and which microcode revision is in use, run the command reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0 in the Windows command prompt. (You can open the command prompt by pressing Windows + R , typing cmd and pressing Return .) The line labeled "VendorIdentifier" shows the CPU vendor (GenuineIntel for Intel or AuthenticAMD for AMD). The line labeled "Identifier" gives the microarchitecture as three numbers: "Family", "Model" and "Stepping". These are relevant in identifying if a particular CPU bug may be relevant to the CPU in your computer. The line labeled "Update Revision" shows the current microcode revision (for the particular microarchitecture) with zeros on both sides. For example, Update Revision REG_BINARY 000000001E000000 means that the revision is 1E (hexadecimal). The line labeled "Previous Update Revision" shows the microcode revision loaded from BIOS.

If the vendor is GenuineIntel, family is 6, model is 61 and stepping is 4, to avoid crashes with Firefox 57 or later, the microcode revision needs to be 1A or higher.

Whether microcode updates are in use by default depends on the Linux distribution and can differ for Intel and AMD CPUs.

• On Debian-based distributions, including Ubuntu, microcode updates for Intel processors are provided by the intel-microcode package and microcode updates for AMD processors are provided by the amd64-microcode package.
• On Arch, AMD microcode updates are installed by default, but Intel microcode updates require special steps.
• On Fedora, microcode updates are installed by default.

To see the processor microarchitecture and which microcode revision is in use, run the command less /proc/cpuinfo in terminal. The line labeled "vendor_id" shows the CPU vendor (GenuineIntel for Intel or AuthenticAMD for AMD). The microarchitecture is given as three numbers on lines labeled "cpu family", "model" and "stepping". These are relevant in identifying if a particular CPU bug may be relevant to the CPU in your computer. The line labeled "microcode" shows the microcode revision number (for the particular microarchitecture) in hexadecimal.

Since the beginning of January, it has been difficult to miss the news regarding the Specter and Meltdown hardware vulnerabilities - the topic turned out to be so serious and comprehensive. Although manufacturers have been aware of these problems since last summer, most seem to have begun to respond only after the details were made public by specialists Google Teams Project Zero.

For example, back in January, among other patches, Intel released microcode updates against Specter for its Broadwell, Haswell, Skylake, Kaby Lake and Coffee Lake processors. But almost immediately it became clear that they lead to failures and. Initially, Intel said that the problem only affected Broadwell and Haswell chips, but later acknowledged the existence of glitches on computers with Skylake, Kaby Lake and Coffee Lake processors and that partners and users would refrain from installing patches for now. Finally, in early February, a corrected version of the microcode, but only for mobile and desktop consumer chips of the Skylake family.

Now, after a month of intensive testing and testing of patches by Intel and its partners, the time has come for other more or less current processors: microcode updates were released for chips based on the Kaby Lake and Coffee Lake architectures, as well as Skylake-based platforms that were not affected by the previous update. We are talking about processors of the 6th, 7th and 8th generations of Intel Core i, as well as the latest Core X, Xeon Scalable and Xeon D families.

The new microcode will be available in most cases through the release of new firmware by OEMs motherboards and laptops. Intel still encouraged people to continually update their systems to current versions, and also published a document in which it described the status of similar microcode fixes for its other products, including earlier chips, starting with the 45 nm Core 2. For some of these chips, patches are just being planned, for others they are in progress early testing, for others - they already exist in the form of a beta version. Typically, the older the architecture, the later it will receive anti-Spectre firmware. However, microcode updates for more or less current Sandy Bridge, Ivy Bridge, Haswell and Broadwell architectures are already in beta testing. Also, a number of Atom chips and even Xeon Phi accelerators have already received patches.

Intel recalled that there are other methods of combating discovered vulnerabilities in the branch prediction unit in modern processors. For example, Retpoline, developed by Google against Specter CVE-2017-5715 (branch target injection or targeted injection into a branch). For those interested additional information The company has published a special technical report about Retpoline and how it works.

Microcode updates released by Intel against Specter will begin to appear as fresh ones in the coming days and weeks BIOS firmware for various motherboards. I wonder if they will have an additional effect on the performance degradation of end systems?

Purchased on Aliexpress for an Intel DG965SS motherboard (with LGA775 connector). You can, of course, convert the LGA771 to LGA775 yourself, but at a price of $6.5 dollars per processor it is much easier to buy it from the Chinese.

When using Intel Xeon 5320 operating system Windows 10 started working only when the "Core multiplexing" mode was turned off in the BIOS (unlike the perfectly working Ubuntu 17.10). At the same time, the processor worked only in single-threaded mode, so, according to the CPU-Z test, performance in multi-threaded mode was 2 times lower than that of the Intel Core 2 duo E6300, which the Xeon was purchased to replace.

It turned out that the processor microcodes needed to be updated. You can do this in software mode, and in Ubuntu the operation is much simpler than in Windows 10. And in the latter you need to make sure that the microcodes are updated every time you boot. It is also possible to update the microcodes in the BIOS, at least in some BIOS from AWARD, AMI, Phoenix, especially in versions before UEFI.

There are much fewer instructions for Intel motherboards. And no wonder. I had to tinker a lot with the Intel DG965SS.

Before updating the microcode, you need to install the processor that we want to support. If you need to install another processor, the procedure will have to be repeated.

Some instructions suggest creating boot diskette, because Not all computers allow you to boot into flash drives. I did bootable USB flash drive with FreeDOS using free application open source Rufus (to do this, check the box "Create a bootable disk using" and select "FreeDOS" from the list).

I present the donor BioStar A740G M2L+ (AMD 740G / SB710) and the recipient BioStar A740G M2+ (AMD 740G / SB700). The motherboard with the letter “L” is more recent and officially supports AM3 processors, unlike the other one, which is limited to only supporting AM2+ processors. Their BIOSes beg for a comparative analysis.
From the office we only load the site latest update BIOS firmware for each of these motherboards:
- for A740G M2+ latest beta A74GM916.BSS for September 2009
- for A740G M2L+ - file 74GCU511.BSS- for May 2010

Next, arm yourself with the MMTOOL utility (I used versions 3.22, 3.23 and 3.26 - I did not find any differences in operation). To work with MMTOOL, BIOS firmware file extensions must be renamed to *.rom.

Now we launch two MMTOOLs and load the firmware files from two mats into them. plat. We pay attention to the different sizes in the “Source size” column (and in “Size in Rom” too, of course) of module 11 “P6 Micro Code” in each of the firmwares.

Let's go to the CPU PATCH section for a detailed comparison:

The donor file 74GCU511.rom - cpu_list contains 14 lines with support for CPURev.ID + 1 empty (Fig. 1).

The beta version of the recipient A74GM916.rom - cpu_list contains 13 lines with support for CPURev.ID + 1 empty (Fig. 2).

After analyzing the lists of these two BIOSes, it becomes obvious that for the newer motherboard the developers used more recent patches for AMD processors, where the microcode of two lines with CPURev.ID 1043 and 1062 (dated 2009/07/31) was corrected and one line with CPURev.ID 10A0 was added (dated 2010/02/17).

Method No. 1 - modification of distinctive lines.

These three distinctive lines are extracted from the donor 74GCU511.rom - the actions “Extract a Patch Data” + “Apply” + 1 last empty line and saved in separate files.

First, in the CPU PATCH section of the recipient file A74GM916.rom, two lines with CPURev.ID numbers 1043 and 1062 (whose microcode is older than we will insert further) and the last empty line are deleted - the actions “Delete a Patch Data” + “Apply” ( Fig.3).

After this, the newer microcode from the four previously received patch files for CPURev.ID 1043, 1062, 10A0 and an empty line are inserted one by one (Fig. 4).

Please pay attention to the dimensions (“Source size” and “Size in Rom”) of module 11 “P6 Micro Code” before and after applying these changes to the recipient file.
After application, these dimensions for the recipient (Fig. 6) will become identical to the dimensions of the same module in the donor file 74GCU511.rom (Fig. 5).
It is worth noting that it is not difficult to understand how the module size is formed (each line in the CPU PATCH section takes 2048 bytes).

It is better to save changes under a new file name.
Next, this file is checked so that MMTOOL opens again without errors.

Method No. 2 - modification by replacing the entire module.

Actually, it is precisely this that is described on the Internet (for example, partially).

In MMTOOL we load the donor file 74GCU511.rom, go to the “Extract” tab and look for the line “P6 Micro Code”. Then select it, in the “module file” field give it the name ncpucode.bin and execute Extract module “in uncompressed form”.

Now load the recipient file A74GM916.rom into MMTOOL, go to the “Replace” tab and again look for the line “P6 Micro Code”. Select it, wait for Browse and select our donor module ncpucode.bin. Click Replace and then agree to the replacement of this module.

Again, pay attention to the dimensions (“Source size” and “Size in Rom”) of module 11 “P6 Micro Code” before and after replacing this module in the recipient file.
After application, these dimensions for the recipient (Fig. 7) will become identical to the dimensions of the same module in the donor file 74GCU511.rom (Fig. 5).

If we compare the results of both methods (Fig. 6 and Fig. 7), then there is a noticeable difference of 10 bytes in the RomLoc address of the “User Defined or Reserved” module, next to the updated “P6 Micro Code” module - perhaps these are features of the operation of MMTOOL...

Conclusion and afterword.

In this way, from different BIOS firmwares, different mat. boards on socket AM2+ (and even AM3 for comparison), you can find the latest microcodes for each type of CPURev.ID, both in Award and AMI bios, then combine them into a single ncpucode.bin.
Subsequently, it turned out to be 32768 bytes in size from 16 lines (microcodes) with the latest dates from among the studied firmware of various BIOSes: with 15 different types of processor revisions for the AM2+ socket (040A, 0413, 0414, 041B, 0433, 0680, 0C1B, 1000, 1020, 1022, 1040, 1041, 1043, 1062, 10A0) and the 16th line for RevID 0000 (apparently some kind of universal microcode for processor revisions not described in other lines - IMHO, for example, future ones).

By combining your own ncpucode.bin by importing the necessary patches (microcodes) for each required processor revision, you can use absolutely any AMI BIOS firmware with the “P6 Micro Code” module as a laboratory one.

However, when saving the firmware file, an unpleasant feature of MMTOOL was noticed - for some reason the utility added 8 zero bytes to the end of the “P6 Micro Code” module - it turned out to be 32776 bytes in size. When extracting the ncpucode.bin file from the laboratory firmware using the same MMTOOL, the output file also became 32776 bytes in size.
You can edit this with simple editors accessible to everyone. But I also (accidentally) discovered alternative way: when the universal BIOS_EXT.EXE utility extracted all modules from the laboratory firmware, the ncpucode.bin file was already the correct size of 32768 bytes - the BIOS_EXT.EXE utility itself correctly identified the end of the “P6 Micro Code” module when saving it to a file.

Actually, the original method, equipment and microcodes can be found (directly the AMI instructions), and in most cases, using this method does not pose any problems and has no pitfalls, but in my practice I regularly encountered the following problem:

Those. there was a banal shortage free space inside the image. When you modify the BIOS for yourself for a specific processor, you can ignore this, because You can always load just one microcode specifically for your processor, or delete some old microcode to free up space, but when you modify with a stream, you need to look for another solution, a compromise.

As a compromise, I chose the following solution - take latest versions microcodes for all processors of the CORE generation in all designs (Celeron E, Pentium E, Core 2 Duo, Core 2 Quad, Xeon *3xxx/*5xxx) and replace everything that came before with them. The set of microcodes turned out to be as follows:

The volume of this set is only 76 kilobytes. This file obtained by combining these files:

cpu00010676_plat00000001_ver0000060f_date20100929.bin
cpu00010676_plat00000004_ver0000060f_date20100929.bin
cpu00010676_plat00000010_ver0000060f_date20100929.bin
cpu00010676_plat00000040_ver0000060f_date20100929.bin
cpu00010677_plat00000010_ver0000070a_date20100929.bin
cpu0001067a_plat00000011_ver00000a0b_date20100928.bin
cpu0001067a_plat00000044_ver00000a0b_date20100928.bin
cpu000006f2_plat00000001_ver0000005d_date20101002.bin
cpu000006f6_plat00000001_ver000000d0_date20100930.bin
cpu000006f6_plat00000004_ver000000d2_date20101001.bin
cpu000006f7_plat00000010_ver0000006a_date20101002.bin
cpu000006f7_plat00000040_ver0000006b_date20101002.bin
cpu000006fb_plat00000001_ver000000ba_date20101003.bin
cpu000006fb_plat00000004_ver000000bc_date20101003.bin
cpu000006fb_plat00000010_ver000000ba_date20101003.bin
cpu000006fb_plat00000040_ver000000bc_date20101003.bin
cpu000006fd_plat00000001_ver000000a4_date20101002.bin

The modification procedure itself has also changed a little and has become, if not simpler, then faster:

Step 1— open the BIOS image in the MMTool program:

Step 2— to check, go to last tab(CPU PATCH) and look at the number of microcodes. Here, for example, there are 31 of them:

Step 3— go to the Replace tab and look for the “P6 Micro Code” item on it:

Step 4— having selected the “P6 Micro Code” item, press the Ikshtsyu button, select the ncpucode.bin file described above and replace it with the Replace button:

Step 5— to check, go to the last tab (CPU PATCH) and look at the number of microcodes. After replacing the microcodes, 17 remained, the latest version:

There is no fundamental difference with the modification procedure described on delidded.com. In most cases, the output is certainly not the same, but the processor receives the necessary microcode. Of the subjective positive aspects, I would only like to draw attention to the fact that the microcodes for all current processors are guaranteed to be updated, be they “civilian” or “server”, and there is practically no risk of receiving a message about lack of space. Although, in my practice, even for such a set of microcodes there was not enough space a couple of times, this was with the BIOS for the ECS P4M900T-M and ECS P4M900T-M2 boards, which are generally compatible with the Xeon E5450.

By tradition, I publish a link to the archive with tools - (zip, 234KB). The archive contains executable file MMTOL.exe(version 3.22 BKMOD), file with microcodes for all 45/65nm processors of the core/xeon generation ncpucode.bin, as well as two files 45nm.bin And 65nm.bin with microcodes only for 45nm processors and only for 65nm. The use of these files can be useful in cases where it is necessary to free up additional space in the BIOS, for example, for new firmware of some controller, network, disk, etc.

!NB: Neither the ncpucode.bin file nor the 45nm.bin/65nm.bin files support Pentium 4, Celeron (without letter suffixes), Pentium D, Celeron D and Xeon W processors (Xeon 5080 for example). These are NetBrust generation processors.