Message board for the users of flat assembler.
> Main > Update microcode
Madis731 01 Feb 2006, 10:49
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.
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 of optimization capabilities. I mean..
Intel Manual wrote:
...the processor provides 40 internal, general-purpose registers, which are used for the
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 http://www.agner.org/optimize/
|01 Feb 2006, 10:49||
Borsuc 01 Feb 2006, 17:11
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
|01 Feb 2006, 17:11||
Chewy509 02 Feb 2006, 01:17
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...
|02 Feb 2006, 01:17||
revolution 02 Feb 2006, 12:35
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.
|02 Feb 2006, 12:35||
LocoDelAssembly 02 Feb 2006, 14:52
Yesterday I downloaded the award BIOS source code from eMule. Maybe there is some info there about microcodes. However every source says this:
; =========================================================== ; ; 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.
|02 Feb 2006, 14:52||
MazeGen 02 Feb 2006, 17:28
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.
|02 Feb 2006, 17:28||
Borsuc 04 Feb 2006, 12:18
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
|04 Feb 2006, 12:18||
revolution 04 Feb 2006, 21:51
Is the internal microcode open-documentation
or do we have to 'hack' it.
Good luck with reversing the update data. Let us know how you get on with it.
|04 Feb 2006, 21:51||
Madis731 04 Feb 2006, 23:00
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" CPU itself!?
|04 Feb 2006, 23:00||
revolution 05 Feb 2006, 08:42
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.
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.
The checksum is nothing more than adding all DWORDs together and it must sum up to 00000000h.
|05 Feb 2006, 08:42||
Madis731 05 Feb 2006, 12:57
Hmm...CPU makers throw rocks at our gates
Its harder than thought. So we should get only valid microcode updates from vendors and no hacking
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?
|05 Feb 2006, 12:57||
MazeGen 08 Feb 2006, 08:12
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:
Christian Ludloff wrote:
Those files contain microcode updates for various Intel processors
Christian Ludloff wrote:
Sometimes a BIOS doesn't contain a suitable microcode update. Besides
These quotes comes from
|08 Feb 2006, 08:12||
vid 08 Sep 2006, 08:13
moved to Main, and linked from interesting topics
IMHO this topic could be explored further...
|08 Sep 2006, 08:13||
Turok 08 Sep 2006, 10:03
Now i became really interested in this subject I found a page on google about AMD K8 Microcode updates not being encrypted (migt be false):
Would be really nice if we could optimize instructions or reprogram some unused ones into something usefull
|08 Sep 2006, 10:03||
f0dder 08 Sep 2006, 10:26
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".
|08 Sep 2006, 10:26||
vid 08 Sep 2006, 10:28
i order one conditioned movcc eax, imm32
|08 Sep 2006, 10:28||
Madis731 08 Sep 2006, 11:15
yeah - movcc r,imm has been on my mind too
and the movcc r,m | movcc m,r should be possible both ways
|08 Sep 2006, 11:15||
Turok 18 Sep 2006, 17:22
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.
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 : http://www.ing-steen.se/share/unix/kernel/microcode/microcode.pdf
|18 Sep 2006, 17:22||
< Last Thread | Next Thread >
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.