I read that microcode is loaded in the processor on each reboot. It resides on flash memory and when the machine is booted, it gets copied to the CPU. Or in the case of Linux, the OS itself has the microcode copy for the processor. But how does the microcode get copied to the processor? All data moves in a computer by the consent of the CPU. CPU is given instructions in machine language. As microcode is imperative for execution of these machine language instructions, so without the microcode being present in the processor, how the instruction for accessing the flash memory and doing the consequent operations are done by CPU? Does this mean that hard-wired non-microcoded instructions copy the microcode in real mode?
I read that microcode is loaded in the processor on each reboot.
The BIOS can issue a microcode update during boot. So can the operating system. Frequently these updates are required, especially with later Intel CPUs.
It resides on flash memory and when the machine is booted, it gets copied to the CPU. Or in the case of Linux, the OS itself has the microcode copy for the processor. But how does the microcode get copied to the processor?
Modern Intel and CPUs have a mechanism called "Model Specific Registers", and special CPU instructions to read (RDMSR) and write to them (WRMSR). While these registers affect CPU settings, writing to a specific one with the address of the new microcode tells the CPU to read a region of memory and apply over the existing microcode.
All data moves in a computer by the consent of the CPU. CPU is given instructions in machine language. As microcode is imperative for execution of these machine language instructions, so without the microcode being present in the processor, how the instruction for accessing the flash memory and doing the consequent operations are done by CPU?
There is always a microcode. The mechanism above updates the microcode. Intel/AMD don't really publish specifics on how it works, they only provide an update mechanism. Obviously somehow it is copying a ROM microcode to some sort of CPU internal memory. But there is some microcode there when the CPU starts. Some recent Intel and possibly AMD CPUs won't work reliably after boot without a microcode update done by the BIOS but evidently they will function well enough to perform an initial microcode update.
Does this mean that hard-wired non-microcoded instructions copy the microcode in real mode?
The initial microcode setup is done internally by the CPU and no instructions are executed to achieve that. It's setup before the first CPU instruction is executed.
To update the BIOS the appropriate RDMSR and WRMSR instructions must be executed.
Reference: "This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) will be generated." If it's not executed in real mode it must be done in ring 0 or kernel mode. You can update the microcode anytime.
Modern CPUs come with complete microcode already installed. This microcode resides in a special ROM area on the CPU itself and cannot be changed/erased. Thus, the CPU can function out-of-the-box.
The system BIOS and/or Operating System can then initiate the loading of a microcode update into the CPU. Such an update is not a complete microcode, but rather a small patch to address bugs. The CPU contains a small area of volatile RAM for this purpose.
A useful reference: https://www.dcddcc.com/pubs/paper_microcode.pdf
The question is ill-formulated. There are many "microcodes" in modern x86/IA64 CPU, and there is a difference between "microcode patch" and microcode.
The microcode in its classic understanding (as step-by-step elements of execution of long CPU instructions) is almost certainly en-carved in silicon, as there is no reason to keep bugs unfixed along many generations of CPU, when new silicon/RTL is compiled with every new manufacturing node.
However, all recent CPUs have several internal units that are controlled by independent microprocessors that are embedded inside the x86 CPU chip.
Most notable/known is so-called "P-unit", a processor that controls dynamic power management of the CPU. As core frequencies went up and leakage went up with further miniaturization of CPU transistors, the only way to keep power in reasonable limit is by aggressive clock throttling and dynamic power gating. The problem is that the CPU can execute infinite varieties of software codes, and each reaches a certain peak of power consumption. Some patterns of "power viruses" may not be known at the moment when CPU was finalized for retail, and some parameters of managing algorithms must be corrected. This is done via dedicated "microcode patches".
There are several more microprocessors of this sort that control other CPU blocks like graphics and memory.
The details of patching process are top secret, to prevent malicious interference. Here is some hacker's report on the attempt to reverse engineer the mechanism.
In short, the x86 architecture microcode is not loaded in modern CPUs, but microcodes for various auxiliary embedded microprocessors can have patches.
The microcode update is a patch only to the existing CPU microcode which is burned into ROM permanently. The CPU has a permanent ROM and a patch RAM which can contain new code. There is also a table of "match" values that is in RAM. This table has an entry for every patchable part of the ROM. When the CPU executes a patchable instruction, it checks this table. If there is an entry, then it uses the code in RAM. If it has the default value, then it jumps to ROM. So, to patch the CPU it is necessary to upload the new code to RAM and then modify entries in the match table appropriately. The procedure for doing this is roughly as follows:
Clear EAX, read the current processor signature using CPUID, and load the matching microcode update into kernel memory.
Clear EAX and EBX, and read the current microcode revision using the RDMSR instruction from the revision match specific register.
Write the memory address of the microcode update using the WRMSR instruction to the update match specific register.
Read the new microcode revision, and return success if it matches that of the update. Otherwise, return failure.
In Linux-based operating systems, this process is done on boot by a specific kernel module called "microcode". You can read the source code for this module to see the exact process.
Note that the patch files have a documented header, but the patch data itself, the actual code, is encrypted by a secret key which is hard-coded into the processor. Unless you know this key, you would have no way of writing your own patches.