Updating microcodes

Hi all,
This will be a slightly longish one about updating microcodes to run machines smoother than before. There are/would be certain acronyms used and I apologize for not explaining all of them as it would have made the blog post bigger and perhaps a bit more complex.

Disclaimer :- I had more experience on Intel Microprocessors than AMD and hence am using examples from Intel in the blog post. The same examples would probably be true in the AMD space as well. As AMD is not easily available here haven’t been able to observe and report any similarities or lack thereof.

Since the early or late 1970’s transistors and it’s derivative the Microprocessor have been part of all Consumer Electronics. By Consumer Electronics I mean everything from the humble calculator, the Microwave, Television, Cars, Bikes etc. and of course the PC.

Now all of this Consumer Electronics need to know what the parameters under which to work and what to do in event something goes wrong. Let’s take the e.g. of a Remote control. whenever we press something on the Remote control of A T.V. or an A.C. the ‘firmware’ is responsible for all the actions done by the Remote. There is a limited combination of actions that can be performed by the Remote hence they are programmed/flashed/burnt on a chip inside the Remote Control P.C.B.

The ‘firmware’ is nothing but a program. The only difference is it’s a low-level program usually written in assembly language for faster execution on the machine.There are time constraints under which it has to perform and hence the name ‘firmware’ is given .

Now the same thing applies in the Personal Computing too. Now these firmwares were usually not made by the company which is making the microprocessor but are a different brand name. This ‘firmware’ is/was called as ‘ROM BIOS’.

ROM BIOS stands for ‘Read Only Memory – Basic Input/Output System’ . It is/was generally complemented by a ‘CMOS battery’ as it needs power all the time to maintain an RTC (Realtime Clock). The ROM BIOS is/was responsible for doing POST (Power On Self Test), making sure all the components and accessories of PC are working properly or give warnings to the user if they are not, Assigning IRQ’s (Interrupt Request numbers or/and lines) before an Operating System is loaded and handing over to the OS to start doing it’s thing. The CMOS can be seen on any motherboard and is usually besides the BIOS.

To put it more simply, the BIOS is/was responsible from the moment you start your PC till the time the OS starts to boot. All the intermediate steps are the responsibility of the BIOS.

Now as everything else BIOS is also written by humans, it’s prone to all the mistakes that we humans do. Now when people report any mistake/goof-up the manufacturers issued a ‘BIOS update/fix’ .

Some of the reasons for BIOS updates :-

a. Gaining support for new/er hardware :- I remember the time when the shift happened from Intel Core processors to Intel Core duo Processors happened. Both of these procs. used the same socket. Now people could either change to a newer motherboard or just update the BIOS and use the newer processor. Just updating the BIOS could result in saving from 3-10k as a newer motherboard is not needed to take advantage of the newer processor (at least for the time-being).

b. Fixing some bug in the firmware :- I remember the time when Intel P4’s had experienced a BIOS issue. It was either in floating point instruction or memory but at some high values it would return ‘bad values.’

To give a concrete example, let’s say you were making number of spreadsheets. In some of the affected Microprocessors the mathematics would come out wrong or have wrong values. This would translate into everything as basic maths (addition,subtraction,multiplication) is embedded in all systems.

My memory is hazy but IIRC Intel had issued an advisory and issued a BIOS update to fix the issue as well as asked people to return defective CPU’s.

Now just imagine if you were an insurance company or pension calculating agency (to distribute pension to people). A few paise (pennies) here and there could result into millions of rupees of outgo or unaccounted money in a bank/company’s account.

I remember of a case a few years ago of a famous hacker by the name of Kevin Mitnick. He was able to hack into a bank’s accounts and put a program there. The program would activate itself whenever a transaction happened in any of the bank’s account and take a few pennies (paise) from one of the parties in the transaction and deposit it another account made by Kevin. For these and other things he was charged, prosecuted and then put behind bars. Now he’s a famous security consultant atm.

In the U.S. and other developed countries if a bank or company did the same thing even inadvertently, they are and would be sued for civil liabilities as well as negligence.

I do remember another case (this I think was after the Pentium series) where heat used to be much more in some of the chips. This was also corrected by a BIOS bug-fix.

Another scenario I remember was in some motherboards the BIOS was not able to correctly identify USB slots or/and define the correct speeds at which the data should be transported.
This was also corrected by a BIOS update.

c. Gaining some additional functionality and/or performance :- This one is similar to a. Many a times due to performance boosts either in the OS or some hardware you can have some additional functionality or performance but as the BIOS defines all limits (for e.g. address space) without a ‘BIOS update’ you cannot use it without a BIOS update. For e.g. few years back we had this move from 32-bit to 64-bit computing. One of the main reasons for the move from 32-bit to 64-bit is being able to use more than 4 GB of RAM which is/was not possible in 32-bit.

Now a simple BIOS fix could make the system use more than 4 GB of RAM in the same system.

Now when to issue a BIOS update/fix is a company’s prerogative. They may not issue a BIOS update/fix as a business strategy as well. I know of lot of times where Intel could have just issued a BIOS update instead of making the fix ‘ONLY’ in new components and leaving the old ones unfixed but that’s a whole different kettle of fish.

Now all of the above things shared above would need a ‘BIOS update’. Doing a BIOS update can be easy or can be heart-breaking. Doing it the right way would probably give some more years to your dated systems, doing it badly could ‘brick’ your computer and make it unusable.

Now on MS-Windows the only thing you could do is to a BIOS update by going to the manufacturer’s website, downloading the BIOS update (if you find the correct version and everything and then flash the BIOS correctly.) For e.g. Intel’s, Asus, Gigabyte etc.

Here are examples for Gigabyte and Intel

On GNU/Linux instead of going the way of the riskier BIOS flashing you can use iucode-tool. This tool/package is primarily for Intel microprocessors.


$ aptitude show iucode-tool
Package: iucode-tool
State: installed
Automatically installed: no
Version: 1.0-1
Priority: optional
Section: contrib/utils
Maintainer: Henrique de Moraes Holschuh
Architecture: amd64
Uncompressed Size: 51.2 k
Depends: libc6 (>= 2.14)
Recommends: intel-microcode (>= 1)
Description: Intel processor microcode tool
iucode_tool is a program to manipulate Intel® X86 and X86-64 processor microcode collections, and to use the kernel facilities to upgrade the microcode on Intel system processors.

It can load microcode data files in text and binary format, sort, list and filter the microcodes contained in these files, write selected microcodes to a new file in binary format, or upload them to the kernel.

It operates on non-free microcode data downloaded directly from Intel or installed by the intel-microcode package.


So from the description we come to know that the package is specifically for Intel microprocessors and needs a non-free package called intel-microcode which is in recommends. That is the reason that the package is in ‘contrib’ and not in ‘Main’ .

Anyways, install both iucode-tool and if recommends is on (by default in apt) then you should get intel-microcode too. Before we go further, it would be wise to inspect and know about the intel-microcode as well.


$ aptitude show intel-microcode
Package: intel-microcode
State: installed
Automatically installed: yes
Version: 2.20130906.1
Priority: extra
Section: non-free/admin
Maintainer: Henrique de Moraes Holschuh
Architecture: amd64
Uncompressed Size: 449 k
Depends: iucode-tool (>= 1.0)
Recommends: initramfs-tools (>= 0.113~)
Conflicts: microcode.ctl (< 0.18~0)
Description: Processor microcode firmware for Intel CPUs
This package contains updated system processor microcode for Intel i686 and Intel X86-64 processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates.

For AMD processors, please refer to the amd64-microcode package.
Homepage: http://feeds.downloadcenter.intel.com/rss/?p=483&lang=eng


So if both are installed, the first thing to do is find out about cpu you have. For instance, here’s mine :-


$ cpuid -1 | grep 'Intel Pentium'
family = Intel Pentium Pro/II/III/Celeron/Core/Core 2/Atom, AMD Athlon/Duron, Cyrix M2, VIA C3 (6)
(synth) = Intel Pentium Dual-Core Processor E5000/E6000 (Wolfdale R0), 45nm


Now I simplified the output here as cpuid is a pretty verbose program. From the above info. it becomes clear that my system is from the Intel Pentium family and is a Pentium dual-Core Processor on 45nm silicon.

Now when you install the above, the microcode installs and updates the microprocessor if it finds something. Here’s mine :-


$ sudo aptitude install iucode-tool -y
The following NEW packages will be installed:
intel-microcode{a} iucode-tool
0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 371 kB of archives. After unpacking 484 kB will be used.
Get: 1 http://debian.ec.as6453.net/debian/ testing/contrib iucode-tool
amd64 1.0-1 [31.0 kB]
Get: 2 http://debian.ec.as6453.net/debian/ testing/non-free
intel-microcode amd64 2.20130906.1 [449 kB]
Fetched 480 kB in 51s (8,162 B/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package iucode-tool.
(Reading database ... 294220 files and directories currently installed.)
Unpacking iucode-tool (from .../iucode-tool_1.0-1_amd64.deb) ...
Selecting previously unselected package intel-microcode.
Unpacking intel-microcode (from .../intel-microcode_2.20130906.1_amd64.deb) ...
Processing triggers for man-db ...
Setting up iucode-tool (1.0-1) ...
Setting up intel-microcode (2.20130906.1) ...
Updating microcode on all online processors...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-3.10-3-amd64


You can test whether the microcode updated properly or not by doing :-


$ sudo grep 'microcode.*update' /var/log/kern.log
[sudo] password for shirish:
Nov 15 08:59:30 debian kernel: [ 0.000000] CPU0 microcode updated early to revision 0xa0b, date = 2010-09-28
Nov 15 08:59:30 debian kernel: [ 0.008000] CPU1 microcode updated early to revision 0xa0b, date = 2010-09-28


You could have multiple instances of the same output as above whenever the kernel wakes up but this output tells that the microcode has been updated.

Note :- From the beginning, Intel has not been transparent about what these microcodes or BIOS updates contain. While they are and can contain BIOS fixes, they can also contain backdoors for organizations such as NSA to eavesdrop on us. One of the arguments that Intel gives for lack of info. is there is a lot of IP (Intellectual Property) as well as third-party IP which it cannot break.Whether that’s the truth or it has more sinister motives only hackers and time can tell.

Note 2 :- Lot of thanx to Henrique de Moraes Holschuh for not only making iucode-tool which can be used in Debian and other GNU/Linux distributions (as in upstream) as well as packaging and maintaining both it as well as the intel-microcode package in Debian. A bottle of beer from me whenever you come to Pune, India :).

Note 3 :- While microcodes were part of BIOS updates, now that BIOS has morphed into UEFI, these microcode updates would probably be part of UEFI updates as well. The good point is Intel continues to give microcode downloads separately as well so GNU/Linux users do not have to run around and install a proprietary Operating system to fix, say a processor error or anything like that. I hope both Intel and AMD continue to maintain these separate downloads as well.

Note 4 :- These microcodes are one of the subsets of the firmware. It seems you need lot of know-how and knowledge about how the chip has been designed in order to do anything on the microcode level. Reverse-engineering firmware is much more easier than reverse-engineering microcodes because you need that inside knowledge and people who are in the PC business know how Intel and AMD jealously guard their chip designs.

So, in the end it’s a binary blob you are actually letting into the system, whether you should do that or not is entirely upto the user. If it improves performance to your system, make it thermally stable or whatever else, keep it otherwise just purge the packages and reboot.iucode-tool should clean after itself when being purged.

Links :-

a. Microcode
b. Machine code
Till l8er.