Log in

View Full Version : Accessing the microcode ROM

TBone
May 18th, 2005, 17:17
The article posted over in this thread:
http://www.woodmann.com/forum/showthread.php?t=7090
about defeating self-CRC-checking code brought up the idea of messing with the processor's microcode ROM to implement the attack in hardware rather than software. Most processors utilize a separate instruction uop cache and memory uop cache, so it's at least within the realm of possibility.

At any rate, until I read that, I was aware of microcode on CISC processors, but I didn't know of the existance of the microcode ROM, let alone that it could be accessed and updated via software. Well, the More You Know™...

I've been trying to find out how this is done, but haven't had much luck in getting details. There is, of course, a linux utility for updating the microcode ROM:
http://freshmeat.net/projects/intelp6microcodeupdateutility/

I've downloaded this and looked at the source code, but that really wasn't much help since the code is in the context of interacting with the linux microcode ROM driver rather than direct access. I suppose there might me be something more direct in the kernel source itself. Perhaps this will get me slapped for being lazy, but I really don't want to resort to digging through all of that to find out how their driver works just yet. Moreover, I don't have much of a grasp on C code or the linux kernel's internals, so I'm not sure it would do me much good even if I found it.

The text file included with the kernel update utility said:
Quote:
***************************************************************************
>>> Special thanks
***************************************************************************

o Intel Corporation, for supplying microcode update data and publishing
the specifications that enabled us to write microcode driver for Linux.

The microcode updates themselves are included in the update utility, but I can't find that Intel has published any specifications that pertain to accessing the microcode ROM.

A similar explanation and source code is available for K8 processors:
http://www.a42.com/node/view/443
Quote:
Modern x86 microprocessors from Intel and AMD contain a feature known as "microcode update", or as the vendors prefer to call it, "BIOS update". Essentially the processor can reconfigure parts of its own hardware to fix bugs ("errata" in the silicon that would normally require a recall.

This is done by loading a block of "patch data" created by the CPU vendor into the processor using special control registers. Microcode updates essentially override hardware features with sequences of the internal RISC-like micro-ops (uops) actually executed by the processor. They can also replace the implementations of microcoded instructions already handled by hard-wired sequences in an on-die microcode ROM.

Again, it seems that all of the "guts" are handled outside of the source code, so I'm still not sure what's actually being done.

Does anyone know how this is done at the assembly level? I doubt its possible to do much with this information anyway. If the rumors are true, both AMD and Intel have designed their Microcode ROMs not to accept arbitrary data, but only patches which have somehow been "signed" by the company and can be verified against some internal key wired into the ROM. Still, I'm curious.
Opcode
May 18th, 2005, 19:22
Hi...

Microcode is really a very interesting topic.

Take a look:

http://www.bitrake.com/phpBB2/viewtopic.php?t=125
http://www.bitrake.com/phpBB2/viewtopic.php?t=144

Regards,
Opc0de
TBone
May 19th, 2005, 12:07
Thanks for those links, Opc0de. I followed all the links in those threads and got a lot of answers. Both Intel and AMD handle this roughly the same way - you just write the update block to a specific MSR (model specific register) using the WRMSR opcode. I really don't know anything about the MSRs for the various and sundry processors (or really for that matter ring0 in general =/), so I guess I have some more reading and research cut out for me.

Anywya, several interesting points arise. First, from here:
http://www.eetimes.com/news/97/963news/hole.html
Quote:
...said Ajay Malhortra, a technical marketing manager based here at Intel's microprocessor group. "Not only is the data block containing the microcode patch encrypted, but once the processor examines the header of the BIOS update, there are two levels of encryption in the processor that must occur before it will successfully load the update."

Well, now we know that it's not just rumors. The double-encryption story comes straight from the horse's mouth. And the analysis done in the documentation for this project:
http://microcodes.sourceforge.net/
seems to confirm that it's been encrypted at least once.

Second point - it seems that AMD's 64-bit processors *don't* encrypt their updates at all, and only use a checksum for verification:
http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=2527&Thread=1&entryID=35446&roomID=11
This, of course, opens up all sorts of interesting possibilities. I know in the past there was a big broohaha about AMD exactly duplicating Intel's microcode base. It just seem kind of funny that now that the shoe is on the other foot, AMD seemingly isn't doing anything to make it hard for someone to RE their microcode.

In keeping with that thought, is the third point. Skim AMD's patent #6438664:
http://patft.uspto.gov/netahtml/srchnum.htm
Now take a look at the section called "Miropatching" (page 3) of this:
http://www.intel.com/technology/itj/q21998/pdf/fa.pdf
The AMD patent was filed in '99, and the Intel document is from Q2 of '98. Considering how much Intel liked to brag about their new microcode patching function in that first article I linked, did they just forget to patent it? Weird.

Finally, I have another question of clarification. According to this Intel document:
http://www.intel.com/technology/itj/q12001/pdf/art_2.pdf
the processor only hits the microcode ROM for opcodes that get decoded into more than 4 uops. Otherwise, the instruction decoder just translates it and dumps the uops in the trace cache. Both the Intel and AMD process indicates that their updates are loaded into the patch RAM on die, and they operate by replacing existing code in the micrcode ROM. That would seem to imply that the only thing their updates can do is to fix problems with complex opcodes that result in a microcode ROM hit. But several of these sources, especially the Failure Analysis PDF from Intel, suggest that you can even theoretically create new opcodes via the microcode updates. Intel says that they use this to aid in debugging the silicon.

So, what's the deal here? Does the instruction decoder itself always reference the microcode ROM? That sounds like that would introduce some significant delay in order to fetch things from the MROM on every single decode. The specs don't agree with that interpretation either. But I don't see how else you could create a whole new opcode unless the microcode ROM can somehow effect the instruction decoder regardless of the "more than 4 uops" criterion.