It was recently asked on the lkml what value there is in upgrading the microcode on an Intel processor. Tigran Aivazian, author of the IA32 microcode driver
and Microcode Update Utility for Linux explained:"The answer to your question is that some Intel CPUs (just like any other hardware or software) contain bugs and, fortunately, their architecture is flexible enough to provide a way to fix those bugs by means of loading the microcode update on the fly, i.e. while the OS is running with no need to reboot (in fact, rebooting or otherwise resetting the CPU causes the update to be lost and requires to run the update again)."
The brief discussion went on to look at which processors support this functionality, and why you might or might not want to perform the update. On the whole, it seems there's little risk and often chance to gain. Unfortunately, a list of specific changes is not publicly available. In any case, the update is volatile, so if it introduces any problems a simple reboot will revert back to the original microcode.
From: Justin Piszcz [email blocked] To: linux-kernel Subject: Linux Kernel Microcode Question Date: Thu, 18 Mar 2004 16:40:49 +0000 The URL: http://www.urbanmyth.org/microcode/ The microcode_ctl utility is a companion to the IA32 microcode driver written by Tigran Aivazian [email blocked]. The utility has two uses: * it decodes and sends new microcode to the kernel driver to be uploaded to Intel IA32 processors. (Pentium Pro, PII, PIII, Pentium 4, Celeron, Xeon etc - all P6 and above, which does NOT include pentium classics) * it signals the kernel driver to release any buffers it may hold The microcode update is volatile and needs to be uploaded on each system boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts back to the old microcode. My question is, what are the advantages vs disadvantages in updating your CPU's microcode? Is it worth it? Does it matter what type of Intel CPU you have? Do some CPU's benefit more than others for microcode updates? I know RedHat distributions usually do this by default, but others do not. Can anyone explain reasons to or not to update the CPU microcode?
From: Dave Jones [email blocked] Subject: Re: Linux Kernel Microcode Question Date: Thu, 18 Mar 2004 16:59:52 +0000 On Thu, Mar 18, 2004 at 04:40:49PM +0000, Justin Piszcz wrote: > My question is, what are the advantages vs disadvantages in updating your > CPU's microcode? It'll fix known problems in the microcode thats in ROM on your CPU. > Is it worth it? In most cases, yes. It's zero cost. You don't waste RAM, as the microcode gets loaded into small RAM areas on the CPU that are otherwise unused. > Does it matter what type of Intel CPU you have? yes. You need at least a Pentium Pro. Also Pentium 4 needs a newer format microcode, which isn't available publically anywhere yet afaik. > Do some CPU's benefit more than others for microcode updates? Some CPUs have more bugs that need fixing than others 8) Additionally some CPUs may not have a newer microcode available than the one that it shipped with in ROM > Can anyone explain reasons to or not to update the CPU microcode? In some cases, your BIOS is doing this transparently already. I've seen instances where moving a CPU between two motherboards has meant that microcode_ctl has done an upgrade on one, and done nothing on the other as its already up to date. If you're already up-to-date, theres no reason to run it. Dave
From: "David Schwartz" [email blocked] Subject: RE: Linux Kernel Microcode Question Date: Thu, 18 Mar 2004 09:13:37 -0800 > > Is it worth it? > In most cases, yes. It's zero cost. You don't waste RAM, as the > microcode gets loaded into small RAM areas on the CPU that are > otherwise unused. It is at least theoeretically possible that a microcode update might cause an operation that's normally done very quickly (in dedicated hardware) to be done by a slower path (microcode operations) to fix a bug in the dedicated hardware that is very obscure and very unlikely to ever bother you. However, I have never heard of even a single confirmed instance where this happened. DS
From: Tigran Aivazian [email blocked] Subject: Re: Linux Kernel Microcode Question Date: Thu, 18 Mar 2004 22:20:07 +0000 (GMT) Hi Justin, The answer to your question is that some Intel CPUs (just like any other hardware or software) contain bugs and, fortunately, their architecture is flexible enough to provide a way to fix those bugs by means of loading the microcode update on the fly, i.e. while the OS is running with no need to reboot (in fact, rebooting or otherwise resetting the CPU causes the update to be lost and requires to run the update again). This is the advantage. There are no disadvantages. After the microcode update has been loaded into the CPUs, the microcode driver can be removed to save a tiny amount of memory that it takes: # rmmod microcode Yes, it does matter which Intel CPUs you have. The driver selects the appropriate chunk of microcode for every CPU present on the system and loads it accordingly. You may even have mixed CPUs (i.e. of different kind) in an SMP system and this is handled automatically. Kind regards Tigran
Interesting, but....
if there are any improvements for newer cpus - where do I get the microcode update? I mean the lates file is from may 2001...
Mostly available under NDA fr
Mostly available under NDA from Intel. You're probably already using these as they are almost always rolled in with OEM BIOS updates. So the Linux facility isn't especially useful although it's good that it's there.
Unmaintained BIOSes..
This could be useful for people with unmaintained BIOSes. A lot of manufacturers won't release BIOS updates after a year or two that the motherboard has been on the market. Updating the microcode from here could possibly fix some problems.
-molo
the last file upgraded my PII
the last file upgraded my PII for some versions. My PIII is not updated..
Security?
Seems to me that allowing microcode updates could be a security issue. Yeah, you need root to do it and once someone bad gets root you're screwed anyway, but messing with cpu microcode is even deeper than anything else root can normally do.
too low level
I think that this microcode would be too low-level to be useful for an attacker. I think that they would at most be able to cripple your CPU, hanging the system. A reboot would get you back to a known good microcode state.
Although.. if this was available to a user of SE linux or some such access controlled system, it has the potential to modify an area of memory to modify the access control.. But to do that would be extremely difficult. I don't think the instructions for this microcode is publicly documented.
-molo
Re: too low level
Microcode is very low level, but in theory it could be done if you for example would know for some specific kernel image that such and so internal registers have some value. I imagine that if such points in a binary exists and you would know the address of some kernel functions/variables/etc, it _could_ be done. Hypothetically.
But such a corruption would have to be extremely small because the microcode "RAM" is incredibly small (evil voices whisper that it was almost too small on the P4). And also, Intel microcode is undocumented, and most compilers try to avoid emiting instructions that execute as microcode because they're usually expensive.
Still, I would love to see someone pulling this off, just for kicks :-)
Also, aren't microcode update
Also, aren't microcode updates signed in such a way that they're extremely hard to forge?
Microcode updates are signed
Yes, microcode updates are written only by intel, and signed with a secret shared key which is built into each chip. The microcode patch has built into its header a specific processor model and stepping, and only the proper processor will accept the patch. It would take a HUGE security breach at Intel for that key to get out.
Thinking too small...
In fact, you don't need to implement a whole exploit in microcode. It would be fully sufficient if there was small "helper", like a command ignoring restrictions under certain circumstances, which could make microcode modifications attractive to virus writers. The exploit could be written in normal machine language then and be distributed separately...
You are realy f#cked
Thats all I wanted to say.
Microcode updates
Microcode updates are generated by Intel and are protected by some of the tightest security I have even seen. They require several proprietary tools and are double encrypted. So the chances of the average hacker understanding the structure of the microcode, understanding the tools necessary to generate the microcode, understanding the encryption methodology and understanding the update methodology is low. Even inquire about it and Intel lawyers will be very interested. I know, I was, they did.
Oh, BTW, microcode updates are frequently containned in motherboard BIOS updates and are loaded whenever your system boots.
And the chances of your being able to do something like recognizing data and doing something like sending it to a secret place for later retrieval is a bit low, it would take a lot of "convert how one instruction works to 50 instructions" to be able to do that.
AMD?
Sixth+ generation AMD processors also contain a microcode engine, right? Do they not have an way to upgrade microcode? Just curious why it seems to be an Intel-only thing. Certainly AMD must have put out a buggy chip once or twice.
microcode bugs elsewhere
Pretty much all microprocessors since probably the late 80s use microcode internally. But that has no relatiionship to whether you get any access to change it. Usually if there's a microcode bug they release a new version of the chip, like Intel did with the floating-point bug in the original Pentium.
Microcode and CISC/RISC
If I remember correctly my computer architecture lessons, practically all CISC processors have used microcode since the 60's or so. You just cannot implement a very complex instruction set without. In microprocessors, the early ones like 8080, 6502 and Z80 worked with hardwired logic, but I think the x86 and 680x0 lines has always used microcode.
One big part of the original RISC ideologue was that they were to be implemented in hardwired logic for speed. I don't know if that is still true of all current designs (which are rather more complex than the original RISCs, which usually did not even have multiply and divide instructions).
AMD ??
Does AMD have a similar way of updating faulty CPUs?
Yes, but its faulty. All of
Yes, but its faulty. All of the newer steppings of the K7 (Athlon) have an errata that prevents their microcode update mechanism from working properly. As far as I know some early K7, as well as the K8 (Athlon64, AthlonFX, Opteron) have a suppored microcode update function.