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?
> 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].
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.
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.
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.
> 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.
Getting a dump means getting access to a memory controller of sorts and asking it to read you back the contents of addresses, right?
But you’re really getting what the memory controller decides to give you. There could be more indirection or sneakiness, right? Ie. I could design a memory controller with landmines, as in “if you ask for 0x1234 I will go into a mode where I send back garbage for all future reads until power is cycled.”
> But you’re really getting what the memory controller decides to give you.
Yes, here the memory is read through a debug bus.
> I could design a memory controller with landmines, as in “if you ask for 0x1234 I will go into a mode where I send back garbage for all future reads until power is cycled.”
Yes, it basically looks like a backdoor, and you can do it the other way around:
The memory read through the debug bus is exactly the content of the ROM, but the memory controller is made so that when the processor reads a specific address or data it doesn't return the value in memory but something else.
This way even a person who would use a visual or an intrusive memory extraction method would not notice the backdoor.
The only way to discover it is to do a full inspection of the logic, which probably nobody will do.
> Is this a thing?
Yes, sometimes some addresses in a memory system are effectively not readable (write only).
As for example with some memory-mapped configuration registers, a 0-value may be returned instead of the register contents.
But your question sounds to me more about mechanisms to hide a backdoor.
Regarding hardware backdoors, they are always theoretically and practically possible, and almost always undetectable.
Since nothing prevents the designer from introducing logic that has malicious behaviour and it's nearly non-observable.
This is the problem with theories about backdoors in modern processors.
Without evidence, these theories fall into the realm of conspiracy theories.
But it's almost impossible to have evidence and no-one can say that it doesn't exist.
Yes, see page 96 of Bunnie Huang's "Hacking the Xbox" where he tells the story of what happens when the machine seems to boot something else than the ROM.
There hasn't been any obvious reason to keep this secret behind encryption, so now there's a little buzz in the air if something newsworthy will be revealed once people start analyzing the microcode and diffs between microcode updates.
> If I'm understanding correctly, this allows us to view (previously obfuscated) code that runs on certain (recent-ish) Intel processors?
Yes, but this "code" is the Intel microcode.
In a modern processor, instructions are translated in a sequence of micro-operations (uOps) before execution; These uOps are small instructions that the processor can execute with more ease.
Ultimately, this allows to build more performant processors.
But some instructions require translation into a uOps sequence that is too complex to be handled like other instructions.
Modern processors therefore feature a "microcode sequencer", and the "microcode" is the configuration of this component.
And this work allows us to interpret a previously misunderstood part of the microcode.
> What are the consequences of this?
There are no real direct consequences for users.
But this helps to better understand how modern Intel processors work; Especially security researchers will be able to better understand how some security instruction works (mainly the SGX extension). In the long term, they may find Intel errors (as has already happened previously) which will be fixed in next Intel processor generation.
Although security issues may be detected in Intel processors, this will probably have no impact for normal users, but it could affect some companies.
Cool, I’m into cheap auditable hardware! This could maybe turn out like when they discovered Linksys was breaking the GPL which ended up opening up an entire class of hardware to hack on.
As someone who just makes Crud apps can someone please ELI5 this. Why is this a big deal and why are people freaking out about intel chips becoming obsolete overnight ?
A CPU executes the machine instructions of your program (you might think of this as "assembly" programs, like "put a zero in register 12" or "jump to address 0xFF3392"). There have been architectures where instructions map directly onto transistors, but since System/360 (*) there's an extra level: the CPU has it's own, lower-level programming language that's used to execute the machine instructions. Finding out how a CPU actually works is interesting per se, and very valuable for competitors, but this work might also expose vulnerabilities and/or backdoors, built into the chip itself. It seems to be around 100kB of code, so there's a whole lot of opportunity...
As someone still at the "piecing things together" stage, here's my understanding:
There are a bunch of privilege levels in Intel CPUs (https://en.wikipedia.org/wiki/Protection_ring, relatively boring), used for memory protection and user/kernel mode separation (IIUC, I think I'm correct). They can be controlled by whatever code boots the CPU ("gets there first"), because the CPU boots in the most trusting state.
Over time the set of available levels proved insufficient for security and new levels were added with negative numbers so as not to disrupt the existing status quo. Ring -1 is used for virtualization and can also be controlled by whatever boots first (ie, outer code can create VMs and enter them, but the CPU faults if inner code attempts to access the virtualization instruction set), but Ring -2 and Ring -3 are used by the CPU itself.
Essentially, in the same way whatever the bootloader loads gets control over a bunch of interesting functionality because that code got there first, Ring -2 and -3 are controlled by code running directly on the CPU that gained control of the system before the bootloader and in some cases even UEFI was started. The significant elements are that a) this code can theoretically be altered by system (microcode) updates; b) these components run *completely* independently of the operating system - IIRC, the Management Engine is based on Minix running on a tiny 486-class core somewhere on the CPU die; and c) this invisible functionality has the ability to read and write all of system RAM. What's that? A glitch? A couple of bytes of RAM just got modified? That made the running Linux kernel suddenly think a process's effective UID is 0? Must have been the butterfly effect!
A bit of Googling found this overview of Ring -1 to -3 which I'd say is really good, definitely worth clearing your cookies to read if Medium is yelling at you about subscribing:
It isn't. There is unnecessary hysteria. Encrypting microcode is just usual competitive play. Doesn't mean anything nefarious. If issues are found in the said microcode, that would be a different story.
Has someone tried to write own microcode and load it? Sounds like it should be much faster to run your own code this way than having the official microcode run an interpreter for your x86 instructions.
I guess that the amount of SRAM for microcode is limited so you cannot write a lot of code this way. Also, microcode might be used only for slow, rarely used instructions, and it doesn't make much sense to optimize them.
Judgement is nigh. I'd love to get my hands on one of the decrypted binaries but I expect there are much more capable reverse engineers are already carrying the torch :^)
As we know, processors run a series of instructions, things like "move data," "add," "store data."
Over time, these instructions have gotten more and more complicated. Now there are "instructions" like "Enter Virtual Machine Monitor" which actually complex manipulations of tons of different registers, memory translations, and subsystems inside of the CPU.
And, even simple, primitive instructions like call, jump, and return actually need to check the state of various pieces of the processor and edit lots of internal registers, especially when we start to consider branch prediction and issues like Spectre.
It wouldn't be very plausible to hard-wire all of these complex behaviors into the CPU's silicon, so instead, most instructions are implemented as meta-instructions, using "microcode." "Microcode" is just software that runs on the CPU itself and interprets instructions, breaking them down into simpler components or adding additional behaviors. Most CPUs are really emulators - microcode interprets a higher level set of instructions into a lower level set of instructions.
Historically, Intel and more recently AMD have encrypted this "microcode," treating it as a trade secret. This makes people who are worried about secret hidden backdoors _very_ worried, because their CPU's behavior is depending on running code which they can't analyze or understand. This has led to all sorts of mostly unfounded speculation about secret back doors, CPUs changing the behavior of critical encryption algorithms, and so on and so forth.
Decrypting this microcode will theoretically allow very skilled engineers to audit this functionality, understand the implementation of low-level CPU behaviors, and find bugs and back-doors in the CPU's interpretation of its own instructions.
Replacing this microcode silently would be absolutely catastrophic security-wise, because an attacker could silently change the way the CPU worked, right out from under running software. But, there is no evidence this is possible, as the microcode is digitally signed and the digital signature implementation, so far, seems to be correct.
There are SO many easier attack vectors for the urna eletrônica that you don't need to worry about this. I'm not implying there is anybody actually attacking them, but if I were to commit election fraud I wouldn't look at low level microcode backdoors.
When there are no paper ballots or printing of ballot receipts, I take it that the quiet intent is not to have a paper trail so that election fraud can be more easily hidden or for plausible deniability. Often, such methods, are to be used against the votes of minority groups or minority parties.
My guess is that the next discovery will be quite significant, but for the time being, this feature is read-only and restricted to Atom processors only.
Does the disclaimer at the top have any legal merit? If they didn’t include that disclaimer, would they actually be liable for damage or loss caused by its use?
Doubtfully legally "required" to avoid liability, but everything you can do to knock down arguments that you injured a third party by warning them of the danger really takes the air out of lawsuits. You can point to the warning to discourage from filing lawsuits, to encourage dismissal, or to make winning a case more likely.
[+] [-] FatalLogic|3 years ago|reply
Two Hidden Instructions Discovered in Intel CPUs Enable Microcode Modification
https://news.ycombinator.com/item?id=27427096
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] RjQoLCOSwiIKfpm|3 years ago|reply
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?
[+] [-] avianes|3 years ago|reply
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
[+] [-] adrian_b|3 years ago|reply
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.
[+] [-] fulafel|3 years ago|reply
Changing things around is expensive, even if they don't have external compatibility obligations.
[+] [-] fragmede|3 years ago|reply
[+] [-] masklinn|3 years ago|reply
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.
[+] [-] Waterluvian|3 years ago|reply
Getting a dump means getting access to a memory controller of sorts and asking it to read you back the contents of addresses, right?
But you’re really getting what the memory controller decides to give you. There could be more indirection or sneakiness, right? Ie. I could design a memory controller with landmines, as in “if you ask for 0x1234 I will go into a mode where I send back garbage for all future reads until power is cycled.”
Is this a thing?
[+] [-] avianes|3 years ago|reply
Yes, here the memory is read through a debug bus.
> I could design a memory controller with landmines, as in “if you ask for 0x1234 I will go into a mode where I send back garbage for all future reads until power is cycled.”
Yes, it basically looks like a backdoor, and you can do it the other way around: The memory read through the debug bus is exactly the content of the ROM, but the memory controller is made so that when the processor reads a specific address or data it doesn't return the value in memory but something else.
This way even a person who would use a visual or an intrusive memory extraction method would not notice the backdoor. The only way to discover it is to do a full inspection of the logic, which probably nobody will do.
> Is this a thing?
Yes, sometimes some addresses in a memory system are effectively not readable (write only). As for example with some memory-mapped configuration registers, a 0-value may be returned instead of the register contents.
But your question sounds to me more about mechanisms to hide a backdoor.
Regarding hardware backdoors, they are always theoretically and practically possible, and almost always undetectable. Since nothing prevents the designer from introducing logic that has malicious behaviour and it's nearly non-observable.
This is the problem with theories about backdoors in modern processors. Without evidence, these theories fall into the realm of conspiracy theories. But it's almost impossible to have evidence and no-one can say that it doesn't exist.
[+] [-] sabas123|3 years ago|reply
However the way they obtained these dumps is by going deep into debugger mode of the cpu which makes me doubt anything spooky would be going on.
[+] [-] jeffrallen|3 years ago|reply
[+] [-] notRobot|3 years ago|reply
If I'm understanding correctly, this allows us to view (previously obfuscated) code that runs on certain (recent-ish) Intel processors?
What are the consequences of this?
[+] [-] fulafel|3 years ago|reply
[+] [-] avianes|3 years ago|reply
Yes, but this "code" is the Intel microcode.
In a modern processor, instructions are translated in a sequence of micro-operations (uOps) before execution; These uOps are small instructions that the processor can execute with more ease. Ultimately, this allows to build more performant processors.
But some instructions require translation into a uOps sequence that is too complex to be handled like other instructions. Modern processors therefore feature a "microcode sequencer", and the "microcode" is the configuration of this component.
And this work allows us to interpret a previously misunderstood part of the microcode.
> What are the consequences of this?
There are no real direct consequences for users.
But this helps to better understand how modern Intel processors work; Especially security researchers will be able to better understand how some security instruction works (mainly the SGX extension). In the long term, they may find Intel errors (as has already happened previously) which will be fixed in next Intel processor generation.
Although security issues may be detected in Intel processors, this will probably have no impact for normal users, but it could affect some companies.
[+] [-] pueblito|3 years ago|reply
[+] [-] mfbx9da4|3 years ago|reply
[+] [-] shmde|3 years ago|reply
[+] [-] tgv|3 years ago|reply
(*) first commercial architecture I know of...
[+] [-] exikyut|3 years ago|reply
There are a bunch of privilege levels in Intel CPUs (https://en.wikipedia.org/wiki/Protection_ring, relatively boring), used for memory protection and user/kernel mode separation (IIUC, I think I'm correct). They can be controlled by whatever code boots the CPU ("gets there first"), because the CPU boots in the most trusting state.
Over time the set of available levels proved insufficient for security and new levels were added with negative numbers so as not to disrupt the existing status quo. Ring -1 is used for virtualization and can also be controlled by whatever boots first (ie, outer code can create VMs and enter them, but the CPU faults if inner code attempts to access the virtualization instruction set), but Ring -2 and Ring -3 are used by the CPU itself.
Essentially, in the same way whatever the bootloader loads gets control over a bunch of interesting functionality because that code got there first, Ring -2 and -3 are controlled by code running directly on the CPU that gained control of the system before the bootloader and in some cases even UEFI was started. The significant elements are that a) this code can theoretically be altered by system (microcode) updates; b) these components run *completely* independently of the operating system - IIRC, the Management Engine is based on Minix running on a tiny 486-class core somewhere on the CPU die; and c) this invisible functionality has the ability to read and write all of system RAM. What's that? A glitch? A couple of bytes of RAM just got modified? That made the running Linux kernel suddenly think a process's effective UID is 0? Must have been the butterfly effect!
A bit of Googling found this overview of Ring -1 to -3 which I'd say is really good, definitely worth clearing your cookies to read if Medium is yelling at you about subscribing:
https://medium.com/swlh/negative-rings-in-intel-architecture...
[+] [-] Akronymus|3 years ago|reply
As in, there may a possibility for almost every computer being vulnerable to a RCE that bypasses even the OS.
[+] [-] bubblethink|3 years ago|reply
[+] [-] vbezhenar|3 years ago|reply
Reality: nobody cares.
[+] [-] punnerud|3 years ago|reply
[+] [-] W4ldi|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] goombacloud|3 years ago|reply
[+] [-] fulafel|3 years ago|reply
edit: there was this piece interesting headway mentioned elsewhere in comments: https://news.ycombinator.com/item?id=32149210
[+] [-] codedokode|3 years ago|reply
[+] [-] jacquesm|3 years ago|reply
[+] [-] no_time|3 years ago|reply
[+] [-] marcodiego|3 years ago|reply
[+] [-] ccbccccbbcccbb|3 years ago|reply
[+] [-] exikyut|3 years ago|reply
[+] [-] ItsTotallyOn|3 years ago|reply
[+] [-] bri3d|3 years ago|reply
Over time, these instructions have gotten more and more complicated. Now there are "instructions" like "Enter Virtual Machine Monitor" which actually complex manipulations of tons of different registers, memory translations, and subsystems inside of the CPU.
And, even simple, primitive instructions like call, jump, and return actually need to check the state of various pieces of the processor and edit lots of internal registers, especially when we start to consider branch prediction and issues like Spectre.
It wouldn't be very plausible to hard-wire all of these complex behaviors into the CPU's silicon, so instead, most instructions are implemented as meta-instructions, using "microcode." "Microcode" is just software that runs on the CPU itself and interprets instructions, breaking them down into simpler components or adding additional behaviors. Most CPUs are really emulators - microcode interprets a higher level set of instructions into a lower level set of instructions.
Historically, Intel and more recently AMD have encrypted this "microcode," treating it as a trade secret. This makes people who are worried about secret hidden backdoors _very_ worried, because their CPU's behavior is depending on running code which they can't analyze or understand. This has led to all sorts of mostly unfounded speculation about secret back doors, CPUs changing the behavior of critical encryption algorithms, and so on and so forth.
Decrypting this microcode will theoretically allow very skilled engineers to audit this functionality, understand the implementation of low-level CPU behaviors, and find bugs and back-doors in the CPU's interpretation of its own instructions.
Replacing this microcode silently would be absolutely catastrophic security-wise, because an attacker could silently change the way the CPU worked, right out from under running software. But, there is no evidence this is possible, as the microcode is digitally signed and the digital signature implementation, so far, seems to be correct.
[+] [-] LeonTheremin|3 years ago|reply
[+] [-] dyingkneepad|3 years ago|reply
[+] [-] Tozen|3 years ago|reply
[+] [-] saltminer|3 years ago|reply
RC4 had already been busted wide open when the two generations of CPUs (Gemini Lake and Apollo Lake) this affects were released.
Why would they use a known insecure cipher?
[+] [-] Heleana|3 years ago|reply
[+] [-] rolph|3 years ago|reply
[+] [-] dqpb|3 years ago|reply
[+] [-] colechristensen|3 years ago|reply
[+] [-] fulafel|3 years ago|reply
[+] [-] hansendc|3 years ago|reply
"In a statement, Intel officials wrote: ... we do not rely on obfuscation of information behind red unlock as a security measure."
(BTW, I work on Linux at Intel, I'm not posting this in any official capacity)
[+] [-] jacquesm|3 years ago|reply