82

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
  • 8,220
  • 2
  • 26
  • 45
Quamis
  • 10,924
  • 12
  • 50
  • 66
  • 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
  • 5
    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 OurBigBook.com 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 OurBigBook.com 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

2 Answers2

77

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
  • 72,986
  • 14
  • 147
  • 189
  • 48
    "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
19

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
  • 69,149
  • 8
  • 89
  • 168
  • 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
  • 5
    *"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
  • @EuroMicelli: Just to clarify for future readers: that's the management engine, outside of the x86 cores themselves. It's not involved in the process of fetch/decode/execute of x86 machine code by an individual core. Microcode updates *can* update things about how the CPUs cores work, like for Spectre mitigation they added a new MSR, since writing an MSR effectively is a way to give access to totally new microcode that wasn't part of any previous instruction, without changing how existing instructions work. They've also done stuff like disable some HW bits, like the loop buffer on Skylake. – Peter Cordes Oct 10 '22 at 02:39
  • @EuroMicelli: Also, the management engine is in the *chipset*, not on the CPU proper. IDK if a CPU microcode update can even affect it. (Which is still somewhat insane, and yeah there'd be room to put something like that on the CPU dies if they wanted.) What's actually onboard the CPU's silicon is an extra controller with about as many transistors as a 486, which manages power / turbo states according to temperature and load history, and some knobs like energy_performance_preference. – Peter Cordes Oct 10 '22 at 02:43