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

💖 Do you like it? Share the link with your friends

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 lack of 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 easier, then faster:

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



Step 2— to check, go to the 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 an 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.

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 replace 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 the number of studied firmware of various BIOSes: with 15 various types processor revisions for socket AM2+ (040A, 0413, 0414, 041B, 0433, 0680, 0C1B, 1000, 1020, 1022, 1040, 1041, 1043, 1062, 10A0) and the 16th line for RevID 0000 (apparently some universal microcode for revisions of processors 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.

You can optimize the performance of the Intel or AMD CPU installed in your computer by installing the latest version of its microcode. Optimization is achieved mainly by correcting errors in the standard microcode received from the motherboard firmware.

BIOS/UEFI firmware updates for your motherboard usually contain new firmware versions for supported motherboard central processors. For this reason, you should first ensure that you are using the latest BIOS/UEFI version.

This guide allows you to optimize the performance of only those central processors that were developed by Intel and AMD.

Notes:

  • Installing the package software with microcodes can lead to unstable operation of the computer. For this reason, you should install this package only when you experience any problems with the functioning of your computer's central processor!
  • Do not install a software package with microcodes for central processors if it is released earlier than the BIOS/UEFI firmware of your computer's motherboard!

1. Central processors manufactured by Intel

If you are using an Intel CPU, you can proceed as follows.

Note: do you need a software package with microcodes for central processors manufactured by Intel that is newer than what is in the official distribution repository? In this case, you can download the software package file with the extension .deb from

Synaptic Package Manager Software

Synaptic Package Manager"Search on your computer"), enter your request "Synaptic" "Synaptic Package Manager" Synaptic package manager "Search" "microcode" and press the button "Search" next to him.

3.201501106.1 (in this case, version 3 of the package was created on November 6, 2015).

« intel-microcode" and press the button "Apply"

dmesg | grep microcode

Enter

2. Central processors manufactured by AMD

If you are using processors manufactured by AMD, this guide will only be relevant for those that were released after 2006 (AMD K10 and newer). If your computer has one of these CPUs, you can proceed as follows.

Note: Do you need a software package with microcodes for AMD CPUs that is newer than what is in the official distribution repository? In this case, you can download the software package file with the extension .deb from the Debian distribution repository into which the packages are placed latest versions. After downloading the package file, you should find it using the file manager and double-click to install the microcodes on the system. After installation is complete, you must restart your computer.

A. If you are using Ubuntu distribution, you will have to install Synaptic Package Manager(this can be done using the application Software). IN Linux Mint This package manager is present immediately after installation.

B. The first thing you should do is run Synaptic Package Manager. On Ubuntu, you can do this by clicking on the white Ubuntu logo at the top of the sidebar ( "Search on your computer"), enter your request "Synaptic" and select the first of the proposed application options "Synaptic Package Manager". No need to use the main window's quick search for software packages box Synaptic package manager, since the corresponding mechanism is unreliable; instead you should press the button "Search" on the toolbar, enter a query in the search field of the dialog box that opens "amd64-microcode" and press the button "Search" next to him.

C. Now you should check the creation date of the software package with the microcodes of the central processors: this package must be created later than the BIOS / UEFI firmware of the motherboard of your computer! The creation date of the package in question is reflected in its version number, for example 2.20160316.1 (in this case, version 2 of the package was created on March 2, 2016).

D. It's time to check the box next to the software package name "amd64-microcode" and press the button "Apply" on the application toolbar.

E. Once the software package installation is complete, you must restart your computer.

F. After rebooting, it is worth checking that one of the installed microcodes loaded correctly by entering the following command in a terminal window (use the copy/paste functions to avoid errors):

dmesg | grep microcode

After finishing entering the command, press the key Enter for its execution. If the microcode was successfully downloaded, you will see several messages indicating this.

Want to learn about other settings and techniques for working with Linux systems? This website contains a large amount of similar materials.

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 details were made public by Google's Project Zero team.

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 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 for 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 reminded that there are other methods of combating the exposed vulnerabilities of the branch prediction block 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 in more information about Retpoline and how it works, the company has published a special technical report.

Intel's anti-Specter microcode updates will begin rolling out in the form of fresh BIOS firmware for various motherboards in the coming days and weeks. I wonder if they will have an additional effect on the performance degradation of end systems?

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.

Tell friends