flat assembler
Message board for the users of flat assembler.

Index > Main > Update microcode

Author
Thread Post new topic Reply to topic
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
Hi,
Here's an advanced topic that I've always been interested in. This idea could be a project if someone had the knowledge and patience.
Code:
mov ecx,79h ; MSR to read in ECX
xor eax,eax ; clear EAX
xor ebx,ebx ; clear EBX
mov ax,cs ; Segment of microcode update
shl eax,4
mov bx,offset Update ; Offset of microcode update
add eax,ebx ; Linear Address of Update in EAX
add eax,48d ; Offset of the Update Data within the Update
xor edx,edx ; Zero in EDX
WRMSR ; microcode update trigger
    

Well, here's a start but someone needs to include this in some boot code. I know that Intel recommends to do it before POST or while in POST, but you can do this even in protected mode and I've seen Linux do it.

This would mean custom instruction set and A LOT Very Happy of optimization capabilities. I mean..
Intel Manual wrote:
...the processor provides 40 internal, general-purpose registers, which are used for the
actual computations. These registers can handle both integer and floating-point...

Changing instructions on-the-fly can be dangerous, but it wouldn't be fun without it. And afterall the changes get lost in the next reboot so...

_________________
My updated idol Very Happy http://www.agner.org/optimize/
Post 01 Feb 2006, 10:49
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Madis731: sorry to be so confused, but can you pls explain what this is? i've never had experience with this, and i simply don't know what it is.. and what's with the 40 internal registers? thanks
Post 01 Feb 2006, 17:11
View user's profile Send private message Reply with quote
Chewy509



Joined: 19 Jun 2003
Posts: 297
Location: Bris-vegas, Australia
Chewy509
The Intel P4 translates your x86 code into an internal form of microcode. The CPU then processes this microcode to do the work... So some more complex instructions like:

xchg reg32, mem32 gets translated into in order to be processed:

mov tmp_reg, mem32
mov mem32, reg32
mov reg32, tmp_reg


where tmp_reg is one of the hidden internal registers, which Madis mentions.

What the code above (what Madis posted) lets you do, is modify the microcode internal to the P4, in short lets you do a firmware or BIOS upgrade on the CPU itself, which is normally used to correct bugs in the CPU.

But unlike your typical motherboard BIOS upgrade, the changes are LOST when you reboot or reset the CPU.

Now here is the fun bit, if you know the internal microcode, you can modify how certain instructions work within the CPU, or even create new instructions, (based on opcode mappings of previous instructions), so something like 90h (NOP) can be reprogrammed into another instruction...

I'm personally not familiar with microcode programming on the P4, but that's the general idea behind it...
Post 02 Feb 2006, 01:17
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17264
Location: In your JS exploiting you and your system
revolution
It was my understanding that the update data has to have to correct crc/signature before the CPU will do any such update. And I have been informed that Intel do not give out information on how to properly put a signature on an update data file. I have even heard talk that the data file must be encrypted with asymetric algorithms (ECC or RSA type of stuff). Therefore, chances seem slim for people to make their own updates as they please.

However I would like to be proven wrong, since changing such things seems to be interesting topic.

Of course you would also need you very own OS to support whatever new instructions you might decide to make.
Post 02 Feb 2006, 12:35
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Yesterday I downloaded the award BIOS source code from eMule. Maybe there is some info there about microcodes. However every source says this:
Code:
;       []===========================================================[]
;
;       NOTICE: THIS PROGRAM BELONGS TO AWARD SOFTWARE INTERNATIONAL(R)
;               INC. IT IS CONSIDERED A TRADE SECRET AND IS NOT TO BE   
;               DIVULGED OR USED BY PARTIES WHO HAVE NOT RECEIVED       
;               WRITTEN AUTHORIZATION FROM THE OWNER.
;
;       []===========================================================[]
;
    


So is very probably that this is a stolen source code. Decide by your self download it or not.
Post 02 Feb 2006, 14:52
View user's profile Send private message Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 975
Location: Czechoslovakia
MazeGen
Did anybody read some of Pinczakko's articles about BIOS reverse engineering in this connection? Here is, for instance, his Guide to Award BIOS Reverse Engineering. There should be some notes about microcode too.
Post 02 Feb 2006, 17:28
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Chewy509: Thanks a lot for the explanation.
ps: Is this specific to Pentium?

EDIT: Is the internal microcode open-documentation, or do we have to 'hack' it.


Last edited by Borsuc on 08 Feb 2006, 12:49; edited 1 time in total
Post 04 Feb 2006, 12:18
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17264
Location: In your JS exploiting you and your system
revolution
Quote:
Is the internal microcode open-documentation
No
Quote:
or do we have to 'hack' it.
Yep.

Good luck with reversing the update data. Let us know how you get on with it.
Post 04 Feb 2006, 21:51
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
Some correction to revolutions first post. The checksum is nothing more than adding all DWORDs together and it must sum up to 00000000h. This means that the checksum area must correct the summation of other bits so that the final result is zero. At least this it what Intel said in their documents. They also said that you can get these updates only from Intel and usually they are bugfixes.
But if you have your hands on RAW CPU, then the difference would be something like C vs BASIC or ASM vs C or other competition between languages you can think of.

The following is only my theory and don't take it as a bible:
Because the update is 2KB with 48-byte header, the 2000 bytes that must describe all the instructions that CPU can handle. If you define each instruction with the op-code byte and then what it can do, then 256 different instructions can have 7 or up to 8 bytes as description on the microcode level until the 2000 bytes are full. I don't recall where I heard it from but some CPUs use 56-bit descriptors to describe everything, but I've got no idea how to define:
1) multibyte mnemonics (prefixes, postfixes, etc...).
2) multiclock instruction i.e. how they can fit division algorithm in 56-bits.

I don't think the Intel guys would be servin' the documents on the silver-plate because of their new virtualization technology, but why add another technology, when you can make so much changes in the "basic" Smile CPU itself!?
Post 04 Feb 2006, 23:00
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17264
Location: In your JS exploiting you and your system
revolution
My guess is that only that a subset of instructions can be altered. Perhaps the basic instructions (like ADD, SUB, etc.) cannot be changed since they are most likely hard wired into the fabric of the thing. Think back to the days to the DIV bug in the pentium. All that was required to fix it was a change in a loopup table. Things like SIN/COS/RECIP use lookup tables so perhaps the update data are simply the lookup tables for such instructions.
Quote:
The checksum is nothing more than adding all DWORDs together and it must sum up to 00000000h.
This is information that is provided so that programmers can check they have a vlid copy of the update data. The header is where the real signature is encoded, and the following 2k of data is encrypted. I once tried a test and changed one bit in the data section and updated the checksum, the CPU rejected to update as invalid.
Post 05 Feb 2006, 08:42
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
Hmm...CPU makers throw rocks at our gates Sad
Its harder than thought. So we should get only valid microcode updates from vendors and no hacking Razz

BTW, do you think that Linux just ouputs reports from the BIOS that the microcode was updated or does it make the update as part of the bootup process of the kernel?
Post 05 Feb 2006, 12:57
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 975
Location: Czechoslovakia
MazeGen
I'm not sure how important this can be in the topic, but... I've just recollected that ftp.sandpile.org contains up-to-date microcode updates:

ftp://ftp.sandpile.org/mcupdate/

Christian Ludloff wrote:
Those files contain microcode updates for various Intel processors
based on either the P6 core or the P4 core. A microcode update can
fix errata; a specific WRMSR is used to attempt to load the update
into a suitable processor.

Normally the BIOS contains several microcode updates, and tries to
load a suitable one during boot.

From time to time I extract those updates from various BIOSes, and
add them to my collection.

Christian Ludloff wrote:
Sometimes a BIOS doesn't contain a suitable microcode update. Besides
that, there are people who just love to experiment. For example, it's
interesting to compare the date of an update to the release date of a
matching stepping. Or monitor the update frequency. Or trying to cor-
relate updates with particular errata in the spec updates. Or...

These quotes comes from

http://www.sandpile.org/post/msgs/20004679.htm
Post 08 Feb 2006, 08:12
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
moved to Main, and linked from interesting topics

IMHO this topic could be explored further...
Post 08 Sep 2006, 08:13
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Turok



Joined: 05 Jun 2005
Posts: 23
Turok
Now i became really interested in this subject Very Happy I found a page on google about AMD K8 Microcode updates not being encrypted (migt be false):
http://www.interesting-people.org/archives/interesting-people/200407/msg00251.html

Would be really nice if we could optimize instructions or reprogram some unused ones into something usefull Smile
Post 08 Sep 2006, 10:03
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Even if you had the documentation, it's probably pretty basic what you can do with microcode updates. Certainly nothing on the level of "creating new instructions".
Post 08 Sep 2006, 10:26
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i order one conditioned movcc eax, imm32 Very Happy Wink
Post 08 Sep 2006, 10:28
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
yeah - movcc r,imm has been on my mind too

and the movcc r,m | movcc m,r should be possible both ways Smile
Post 08 Sep 2006, 11:15
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Turok



Joined: 05 Jun 2005
Posts: 23
Turok
I found some "new" informations on this subject. It was written by prophet2003 (bottom of the page): http://forums.vr-zone.com/archive/index.php/t-14346.html
The thread was about another subject so here is the related info:

Finally some details on microcode structure!!!
It is for Pentium Pro but it probably hasn't changed too much.

P6 processors contain a small SRAM that holds up to
60 microinstructions. The patch code is downloaded into
this SRAM. The processor also contains a set of “match” registers
that cause a trap when a particular microcode address
is encountered. (This is similar to the “instruction breakpoint”
capability used to debug assembly code.) This trap,
which takes a single cycle to process, vectors microcode execution
into the patch RAM.
The downloaded microcode consists of two segments.
The first is an initialization routine that is run immediately
after the code is downloaded. This routine can be used to
reconfigure certain aspects of the processor. This segment of
microcode also initializes the match registers, if necessary.
The second segment contains one or more patches that
remain in the patch RAM during normal operation and are
accessed via a match-register trap. Since the original microcode
is stored in ROM, it cannot be modified; the match registers
allow the operation of the microcode to be changed. In
this way, an x86 instruction that is operating incorrectly can
be repaired, assuming it is implemented in microcode.
When an instruction needs to be repaired, a patch is
created to replace a section of the original microcode, performing
the correct operation and then jumping back to the
original flow. The extra cycles spent jumping to and from the
patch code will, of course, impact performance, but in some
cases a bug can be corrected using this mechanism.

About encryption:

The 2,000 data bytes are encrypted in a way that Intel
claims will be extremely difficult to break. The bytes are
divided into blocks of varying lengths, each of which is
encoded differently. Because the actual microcode patches
are typically much smaller than 2,000 bytes, the remaining
data is random noise intended to confuse anyone attempting
to break the encryption.
Even if a hacker could successfully decipher the encryption,
the next challenge would be constructing a legal patch.
Intel has not published any information on the format of
its microcode, which the company claims is deliberately
designed to be difficult to understand. Only a small number
of Intel employees know the P6 microcode formats. Thus, it
would be nearly impossible to construct a microcode patch
that would, for example, cause the processor to add when it
was supposed to subtract.

He also posted a link to microcode.pdf (deeper explenation) but it isnt working anymore so i found anotherone Very Happy : http://www.ing-steen.se/share/unix/kernel/microcode/microcode.pdf
Post 18 Sep 2006, 17:22
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.