flat assembler
Message board for the users of flat assembler.
Index
> Main > Update microcode |
Author |
|
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:
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. |
|||
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
Quote: Is the internal microcode open-documentation Quote: 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.
Quote: 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:
ftp://ftp.sandpile.org/mcupdate/ 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 http://www.sandpile.org/post/msgs/20004679.htm |
|||
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):
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 |
|||
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. 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 : http://www.ing-steen.se/share/unix/kernel/microcode/microcode.pdf |
|||
18 Sep 2006, 17:22 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.