80

From what I've read it's used to fix bugs in the CPU without modifying the BIOS. From my basic knowledge of Assembly I know that assembly instructions are split into microcodes internally by the CPU and executed accordingly. But intel somehow gives access to make some updates while the system is up and running.

Anyone has more info on them? Is there any documentation regarding what can it be done with microcodes and how can they be used?

EDIT: I've read the wikipedia article: didn't figure out how can I write some on my own, and what uses it would have.

edmz
  • 7,675
  • 2
  • 21
  • 43
Quamis
  • 10,181
  • 12
  • 45
  • 63
  • 4
    why would you need it? It could be the best possible way to permanently damage your CPU. – ruslik Dec 06 '10 at 13:35
  • 4
    It can be used to fix bugs in the CPU, or introduce bugs. Intel does the former for you, so unless you want to do the latter, there's very little point in messing around with it. – jalf Dec 06 '10 at 13:55
  • 2
    You might be interested in this: http://downloadcenter.intel.com/Detail_Desc.aspx?ProductID=483&DwnldID=14303. Please look at "Detailed Description" given in that link. – yasouser Dec 06 '10 at 14:09
  • Probably because you downvoted their answers :P I've removed my answer as I see what your true question is. You should edit the question to focus on your desire to modify microcode. – Matt Joiner Dec 06 '10 at 18:03
  • 1
    Why intel does not open it up: http://stackoverflow.com/questions/5806589/why-does-intel-hide-internal-risc-core-in-their-processors The circuitry that runs microcode is also known as the "RISC core". – Ciro Santilli新疆棉花TRUMP BAN BAD Jun 19 '15 at 20:06
  • 1
    A "how to manipulate it" version: http://security.stackexchange.com/questions/29730/processor-microcode-manipulation-to-change-opcodes – Ciro Santilli新疆棉花TRUMP BAN BAD Jun 19 '15 at 20:14
  • There is no risk of damaging the CPU, microcode is loaded at startup, not flashed permanently into the CPU. – doug65536 Apr 08 '17 at 00:01
  • From a deleted mostly-link-only answer: Daming D. Chen and Gail-Joon Ahn have written a very good (relatively new) Article about security and microcode in x86 CPU's. https://www.dcddcc.com/docs/2014_paper_microcode.pdf – Peter Cordes Jan 09 '18 at 00:30

3 Answers3

78

In older times, microcode was heavily used in CPU: every single instruction was split into microcode. This enabled relatively complex instruction sets in modest CPU (consider that a Motorola 68000, with its many operand modes and eight 32-bit registers, fits in 40000 transistors, whereas a single-core modern x86 will have more than a hundred millions). This is not true anymore. For performance reasons, most instructions are now "hardwired": their interpretation is performed by inflexible circuitry, outside of any microcode.

In a recent x86, it is plausible that some complex instructions such as fsin (which computes the sine function on a floating point value) are implemented with microcode, but simple instructions (including integer multiplication with imul) are not. This limits what can be achieved with custom microcode.

That being said, microcode format is not only very specific to the specific processor model (e.g. microcode for a Pentium III and a Pentium IV cannot be freely exchanged with eachother -- and, of course, using Intel microcode for an AMD processor is out of the question), but it is also a severely protected secret. Intel has published the method by which an operating system or a motherboard BIOS may update the microcode (it must be done after each hard reset; the update is kept in volatile RAM) but the microcode contents are undocumented. The Intel® 64 and IA-32 Architectures Software Developer’s Manual (volume 3a) describes the update procedure (section 9.11 "microcode update facilities") but states that the actual microcode is "encrypted" and clock-full of checksums. The wording is vague enough that just about any kind of cryptographic protection may be hidden, but the bottom-line is that it is not currently possible, for people other than Intel, to write and try some custom microcode.

If the "encryption" does not include a digital (asymmetric) signature and/or if the people at Intel botched the protection system somehow, then it may be conceivable that some remarkable reverse-engineering effort could potentially enable one to produce such microcode, but, given the probably limited applicability (since most instructions are hardwired), chances are that this would not buy much, as far as programming power is concerned.

Thomas Pornin
  • 68,772
  • 14
  • 141
  • 184
  • 44
    "This is not true anymore. For performance reasons, most instructions are now "hardwired": their interpretation is performed by inflexible circuitry, outside of any microcode." I don't think this is correct. Agnor Fog has done a lot of reverse engineering of modern x86 CPUs and mentions microcode frequently, in fact I think microcode is what gets pipelined and OOE instead of normal instructions, and normal things like using a memory address instead of a register for an operation generate extra u-ops. Agnor Fog manual here: http://www.agner.org/optimize/microarchitecture.pdf – Joseph Garvin Aug 30 '12 at 02:20
  • 5
    Also, pltsim, which attempts to do a full x86-64 CPU simulation, specifically emulates microcode: http://www.ptlsim.org/ – Joseph Garvin Aug 30 '12 at 02:22
  • 2
    @JosephGarvin: another revealing fact is that the Pentium IV had a _trace cache_ instead of a normal _L1 icache_. – ninjalj Sep 08 '12 at 09:27
  • 5
    That reads like a whole lot of speculation and no references. – ʇsәɹoɈ Nov 24 '15 at 18:32
  • 1
    What's the reason for this? What harm could come from enabling people to write their own microcode? I'm assuming it would require kernel access to do so, so it wouldn't hurt security, and it's stored in volatile memory, so it can't brick the processor or anything. – flarn2006 Dec 24 '15 at 09:57
  • 2
    It seems ptlsim.org no longer exists, but [Marss86](http://www.marss86.org/~marss86/index.php/Home) is based on ptlsim. – Jordan Miner Jan 30 '16 at 19:30
  • @flarn2006 Being stored in volatile memory doesn't mean it can't brick the processor if the execution of the microcode causes physical harm (extremely unlikely, but not impossible). – JAB Mar 13 '17 at 12:58
  • @JosephGarvin So you inferred some speculations from Agner Fog's documentation and somehow got to "microcode is what is pipelined"? Microcode is used when a single instruction needs to generate a lot of micro-ops (which are executed in the normal pipelines) and/or requires making multiple choices during instruction execution, such as validating arguments of `wrmsr` or doing lots of validations of the TSS when jumping to a task gate. "Fast" instructions which can be decoded in parallel (up to four per clock) are not microcoded. – doug65536 Apr 08 '17 at 00:19
  • @doug65536 I specifically said I "think" because I wasn't completely sure. What I was trying to say is I didn't know how to reconcile the statement that microcode isn't used much anymore with Agner Fog's constant references to u-ops (why have the distinction from instructions if instructions are the fundamental ops?) and pltsim specifically advertising it emulated microcode (why advertise it if it's not used?). – Joseph Garvin Apr 08 '17 at 03:42
  • 2
    @JosephGarvin Oh, I see. Yes, there are many microcoded instructions, specifically, many system instructions perform one or several validations. However, most of the instructions frequently used by compilers are hardwired and special cased. Instructions with a throughput of less than one in Agner Fog's list are not microcoded. To achieve a throughput less than one, multiple instructions must be decoded in the same clock and only the first decoder handles microcoded instructions. Instructions with a throughput of greater than one are probably microcoded. – doug65536 Apr 08 '17 at 18:48
  • 1
    @JosephGarvin I'm no expert on this either, but I think there's some semantic mixups/confusion going on with microcode and micro-ops. I believe *all* instructions get turned into some number of uops (which I think is how the processor can do register renaming and things like that), but "microcode" is being used to describe the implementation of more complex operations (loops/others?) in the instruction->uops layer. Again, I'm not 100% clear on this either, this is just my current impression... – mbrig Jan 04 '18 at 04:33
  • @JosephGarvin: Yes, decoded uops are what modern x86 CPUs schedule out-of-order, but most common instructions decode to a single uop. And more importantly, [*the decoding is hardwired* for instructions that decode to 4 or fewer uops (on Intel CPUs)](https://stackoverflow.com/questions/40366643/what-is-a-microcoded-instruction). An instruction like `add eax, [rdi]` decodes to 1 micro-fused uop which represents an ALU add uop and a load uop. Most of the pipeline tracks it as a single uop, but the scheduler does track the load and the add separately. (So the load can start before `eax` is ready) – Peter Cordes Jan 09 '18 at 00:34
  • Anyway, the key point here is that "microcode" is not a synonym for uops. – Peter Cordes Jan 09 '18 at 00:35
18

Think loosely about a virtual machine or simulator where say for example qemu-arm can simulate an arm processor on an x86 host, ideally the software running on the simulated arm has no idea that it isnt a real arm. Take this idea to the level where the whole chip is designed such that it always looks like you are an x86, the software never knows there is some programmable items inside the chip. And that some other processor inside is somewhat designed for the purpose of implementing/simulating an x86. Supposedly the popular AMD 29000 product line just went away because the hardware team and perhaps processor/core became the guts of an early x86 clone. Transmeta, where Linus worked, had a vliw processor that was made to be a low power x86. In that case the translation layer was not (as much of) a secret. Vliw, very long instruction word, RISC taken to the extreme, is the kind of thing you build for this kind of task.

No it is not as much of an emulation layer as I am implying, there isnt some linux running there with a qemu program inside each chip. It is somewhere between hardwired where there is no software/microcode in the middle and a full blow emulation. The programmable bits may be like an fpga, programmable gates, or it may be software or programmable state machines, meaning not-programmable gates, just what runs on the gates is programmable.

Your non-x86, non-big iron type processors. Take ARM for example, are hardwired, no microcode. Microcontrollers, PIC, MSP430, AVR, assume these are not microcoded. Basically do not assume all processors are microcoded, few if any processor families are. It is just that the ones we deal with in PCs have been and may still be, so it may feel like they all are.

As fun as it may sound to play with this microcode, it is likely very specific to the processor family, and you likely will never gain access to how it works unless you work for Intel or AMD, each of which likely have their own internals. So you would need to get a job at one of the two, then work your way through the trenches to become one of what is likely an elite team that does this work. And once you get that far your career is trapped, your skills may be limited to one job at one company. You might have more fun programming individual gpus on a video card, something that is documented or at least has tools, something you can do today without spending 10 years at AMD or Intel to possibly get nowhere.

old_timer
  • 62,459
  • 8
  • 79
  • 150
  • Thanks for the clear answer. So, in a way, we can say that a CPU is a lesser and specialized form of a FPGA, and we can think microcode is something similar to Verilog? – Tu Do Sep 24 '15 at 08:29
  • 1
    it is not that generic inside, more like a cpu inside a cpu but the inner one is more primitive, possibly RISC but likely simpler than that (simpler in that it may take multiple instructions to do anything one interesting or useful thing). – old_timer Sep 24 '15 at 11:31
  • 3
    *"there isnt some linux running there with a qemu program inside each chip."* I would have laughed at that prospect - until a few days ago. Then, this got reported: http://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/. Things have gotten a lot more complicated than they used to be. – Euro Micelli Nov 16 '17 at 07:13
10

You don't normally write micro-code. To do so requires intimate knowledge of the CPU micro-architecture. Intel doesn't general release any information on either their micro-architecture or their micro-code.

Paul R
  • 195,989
  • 32
  • 353
  • 519
  • 1
    And even if there were such documentation, it's difficult to test the code: 1 try == 1 broken CPU (with 99% probability) . – ruslik Dec 06 '10 at 14:05
  • 1
    @ruslik: in the past there have been CPUs with some spare instruction slots for user microcode - you could use these to add your own custom instructions to the ISA. The core instruction set would not be broken, even if your custom instructions were buggy. But yes, in general, this is not stuff to be messed with lightly. – Paul R Dec 06 '10 at 14:07
  • 5
    why would that lead to broken cpu as long as the microcode is not persistent? (i'm not talking here about overclocking, i'm simply asking what can be done on a stock cpu) – Quamis Dec 06 '10 at 14:08
  • @Quamis: try running a computer with damaged BIOS. – ruslik Dec 06 '10 at 14:10
  • @Quarnis: microcode usually *is* persistent (CPUs wouldn't be able to boot otherwise). If it's not hard-wired then it might typically be in some kind of small fast ROM. – Paul R Dec 06 '10 at 14:11
  • 1
    @Paul R: in that case, if they were designed for public, they were documented. But trying to play with such undocumented features with no apparent reasons does not make sense. Maybe it's because OP don't understand the problem completely. – ruslik Dec 06 '10 at 14:11
  • 6
    @Paul R: microcode is NOT persistent:) read that wiki again. Also, linux keeps pathing the CPU on every reboot... Also, on wiki it said the usually the BIOS is responsible for pathing the CPU on EVERY init. – Quamis Dec 06 '10 at 14:15
  • @Quarnis: **persistent** means something that will survive across reboots or power downs. Intel has a patching mechanism for updating their microcode ROMs, but these are still persistent. Intel will have tested their microcode updates fully before releasing them, so there is little chance of you breaking your CPU. If you patch the microcode yourself then it's a different story. – Paul R Dec 06 '10 at 14:19
  • @Quarnis: then all you have to do is to read and implement this: http://www.intel.com/Assets/PDF/manual/253668.pdf – ruslik Dec 06 '10 at 14:36
  • 4
    If you want to play with microcode and other cpu implementation details, you might consider getting into FPGA soft-core processors. Or just play with simulators. – Chris Stratton Dec 06 '10 at 21:09
  • 12
    @Paul R: Intel microcode updates aren't persistent across hard resets. At a hard reset, the processor reverts back to the factory microcode. – caf Dec 07 '10 at 00:34
  • @caf: thanks for the clarification - I was assuming that the microcode patches were persistent in the same way as the original microcode but it sounds like that's not the case. – Paul R Dec 07 '10 at 08:07
  • 5
    There are microcode simulators, if you want to learn more about microcode and try one out, ex: http://www.mythsim.org/, http://en.wikipedia.org/wiki/MikroSim, http://www.forth.com/archive/jfar/vol3/no3/article1.pdf – ChuckCottrill Oct 18 '13 at 20:08