Hacker News Reader

Comment by RjQoLCOSwiIKfpm | Hacker News Reader

Which machine language is the microcode written in?

Is it even possible to fully decode that language with publicly available information/tools?

Given that microcode is an internal mechanism of CPUs, I would expect its language to be impossible to decode for regular people because there is zero knowledge on how it works?

And even if there is some knowledge on it, won't Intel change the machine language around a lot among CPU generations because the lack of public usage means it can be changed constantly, thus rendering the existing knowledge useless quickly?

View on HN

> Which machine language is the microcode written in?

The mirocode is generally a sequence of uOps. But in Intel's case, there seems to be a more complex mechanism, called XuCode, that generates the uOps sequence. The XuCode ISA seems to be based on x86-64, as Intel says [1]:

> XuCode has its own set of instructions based mostly on the 64-bit Instruction Set, removing some unnecessary instructions, and adding a limited number of additional XuCode-only instructions and model specific registers (MSRs) to assist with the implementation of Intel SGX.

PS: Decoding of the XuCode microcode can potentially give precious information about uops encoding

PS2: You can find more information on uops encoding in another work from the same team [2].

[1]: https://www.intel.com/content/www/us/en/developer/articles/t...

[2]: https://github.com/chip-red-pill/uCodeDisasm

Reading this:

https://www.intel.com/content/www/us/en/developer/articles/t...

What this seems to be is:

- Intel CPUs with SGX have an additional CPU mode that understands and runs XuCode, "XuCode is implemented as a variant of 64-bit mode code, running from protected system memory, using a special execution mode of the CPU."

-- I know that "ring" terminology is used to describe CPU modes, e.g. calling a hypervisor setup ring -1, SMM ring -2, and the Intel management engine ring -3. Seems like this mode is something like ring -2.5.

- "It is authenticated and loaded as part of a microcode update and is installed into a Processor Reserved Memory (PRM) range, typically allocated by system firmware. The memory range itself is protected from software and direct memory accesses by the Processor Reserved Memory Range Registers (PRMRRs)."

So the BIOS steals a bit of your RAM (which the ME already does), sets it up to be the PRM, and a microcode update unpacks XuCode now contained in the microcode data, and puts it in this PRM. I guess some SGX instructions are essentially a specialized form of INT instructions that "exception out" specifically to this special CPU mode/PRM space.

So I'm under the impression XuCode is essentially called by the microcode when certain SGX instructions are encountered.

Weird ...

The microcode is a sequence of fixed-length microinstructions.

Each microinstruction is composed of many bit fields, which contain operation codes, immediate constants or register addresses.

The format of the microinstruction is changed at each CPU generation, so, for example, the microinstructions for Skylake, Tiger Lake, Gemini Lake or Apollo Lake have different formats.

Therefore, someone who discovers the microinstuction format for one of them has to repeat all the work in order to obtain the format for another CPU generation.

In the presentation from

https://www.youtube.com/watch?v=V1nJeV0Uq0M

the authors show the microinstruction format for Apollo Lake, which is a kind of VLIW (very long instruction word) format, encoding 3 simultaneous micro-operations, each of which can contain three 6-bit register addresses and a 13-bit immediate constant.

For Apollo Lake, the microinstruction encoding is somewhat similar to the encoding of an instruction bundle (containing 3 instructions) in the Intel Itanium processors.

It is likely that in the mainstream Intel Core or Xeon CPUs the micro-instruction format is significantly more complex than this.

The team which reverse-engineered the microinstruction format was able to do this because they have exploited a bug in the Intel Management Engine for Apollo Lake/Gemini Lake/Denverton to switch the CPU into a mode in which it allows JTAG debugging.

Using JTAG they could read the bits from some internal busses and from the microcode memory. The bits read were intially meaningless, but by executing many test programs and comparing what the CPU does, with the bits read at the same time via JTAG, they eventually succeeded to guess the meaning of the bits.

For most Intel CPUs, there is no chance to switch them into the debugging mode, unless you receive a secret password from an Intel employee (which probably is within the means of some 3-letter agencies).

Once switched into the debugging mode, it is possible to do things as complex as making the CPU to replace the normal execution of a certain instruction with the execution of an entire executable file hidden inside the microcode update (and you can also update the microcode directly, bypassing the normal signature verification step).

However, for most motherboards, it is likely that switching to the debugging mode also requires physical access to change the connection of some pin, not only the secret password, though exceptions are known, where the MB manufacturers have forgotten to disable the debugging mode on the PCB.

>...unless you receive a secret password from an Intel employee (which probably is within the means of some 3-letter agencies).

Phone calls are easier.

It's still receiving a secret password from an employee if you just call and ask nice and they give it to you.

There's a lot of precedent bout figuring out undocumented instruction sets (the microcode sequencing format here) from history.

Changing things around is expensive, even if they don't have external compatibility obligations.

Yeah but Intel's engineers aren't going to just change the machine language around for funzies. I'd expect it to be semi-stable because if it ain't broke, there's no reason to go in and change it.

They might not change existing stuff, but they may very well constantly add new instructions, that doesn't break their usecase, but it will break the usecase of the public trying to decode it easily.

Yes but that won't make the existing knowledge useless.

They changed from ARC to a 32-bit Quark core for the ME from version 11 up.

That's just the CPU arch running IME. The uOps is designed by Intel.

When you say quark, do you mean the 486 that uses 25mA? Or did intel use that name twice?

I have a couple of quarks, never used them.

Looks like I misunderstood the original point, but to follow up on your comment: yes. https://en.wikichip.org/wiki/intel/management_engine#Current...

> Which machine language is the microcode written in?

Seems logical that it would be mostly be standard machine code, since there are instructions which translate 1:1 to microcode (I assume) no use translating everything, that’d require more space and be harder on everyone for little reason.

Though there might be privileged instructions which would only be available in microcode (would be rejected by the frontend), and which you would have to reverse-engineer separately.

The thing with high-performance x86 is that it is not really an microcoded design. The CPU is RISC-like OoO thing that can execute some pretty substantial subset of x86 ISA after some simple conversion (ie. to some fixed-width format). Thus it makes sense for such design to not have separate microcode sequencer but run the "microcode" that emulates instructions that are not directly supported through the same execution engine (with the low-level "micro" ISA having extensions to manipulate the CPU state that is not directly modifiable by user code, like filling TLBs and changing shadow descriptors).

Reply on news.ycombinator.com