4 ms·

Related: https://news.ycombinator.com/item?id=27334855 https://news.ycombinator.com/item?id=27334855 https://www.google.com/search?q=%22christopher+domas%22+x

Related: https://news.ycombinator.com/item?id=27334855 https://news.ycombinator.com/item?id=27334855 https://www.google.com/search?q=%22christopher+domas%22+x86+%22god+mode%22 https://www.google.com/search?q=%22christopher+domas%22+x86+... https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://en.wikipedia.org/wiki/Alternate_Instruction_Set >"In 2018 Christopher Domas discovered that some Samuel 2 processors came with the Alternate Instruction Set enabled by default and that by executing AIS instructions from user space, it was possible to gain privilege escalation from Ring 3 to Ring 0.[5] Domas had partially reverse engineered the AIS instruction set using automated fuzzing against a cluster of seven thin clients.[12] Domas used the terms "deeply embedded core" (DEC) plus "deeply embedded instruction set" (DEIS) for the RISC instruction set, "launch instruction" for JMPAI, "bridge instruction" for the x86 prefix wrapper, "global configuration register" for the Feature Control Register (FCR), and documented the privilege escalation with the name "Rosenbridge".[5]" Also -- I should point out that the debate of if x86 (CISC) CPU's contain RISC cores -- is largely academic. Both RISC and CISC CPU's contain ALU's -- so our only debate, really, if we have one, is how exactly data that the ALU is going to process -- is going to wind up at the ALU... It is well known in the x86 community that the x86 instructions are an abstraction, a level of abstraction which runs on top of lower-level of abstraction, the x86 microcode layer... Historically, intentionally or unintentionally, most x86 vendors have done everything they can to hide, obfuscate, and obscure this layer... There (to the best of my knowledge, at this point in time) is no official documentation of this layer, how it works (etc., etc.) from any any major x86 vendor. x86 microcode update blobs -- are binary "black boxes" and encrypted. Most of our (limited) knowledge in this area comes from various others who have attempted to understand the internal workings of x86 microcode: https://www.google.com/search?q=%22reverse+engineering+x86+processor+microcode%22 https://www.google.com/search?q=%22reverse+engineering+x86+p... https://github.com/RUB-SysSec/Microcode https://github.com/RUB-SysSec/Microcode https://twitter.com/_markel___/status/1262697756805795841 https://twitter.com/_markel___/status/1262697756805795841 https://www.youtube.com/watch?v=lY5kucyhKFc https://www.youtube.com/watch?v=lY5kucyhKFc It should be pointed out that even if a complete understanding of x86 microcode were to be had for one generation of CPU -- there would always be successive generations where that implementation might change -- leaving anyone who would wish to fully understand it, back at square one... To (mis)quote Douglas Adams: "There is a theory which states that if ever anyone discovers exactly what the x86 microcode layer is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable." There is another theory which states that this has already happened." :-) <g>

bri3d 3y ago
It's also worth noting that "microcode" in a modern x86 CPU is not really the same thing as "microcode" in an older, "microcoded" CPU. What do I mean by this? Some older CPUs were truly "microcoded." The heart of the CPU was an interpreter loop which took instructions, then invoked a ROM / microcode routine corresponding to the implementation for that instruction. Each instruction began with the runtime selecting an instruction and ended with the microcode routine returning to a loop. A good example of this is the 8086: http://www.righto.com/2022/11/how-8086-processors-microcode-engine.html http://www.righto.com/2022/11/how-8086-processors-microcode-... . These CPUs worked like a traditional "emulator." That is NOT how a modern x86 CPU works. A modern CPU works a lot more like a JIT. In a modern x86 CPU, "microcode" runs _alongside_ the main CPU core execution. The microcode runtime can be thought of as a co-processor of sorts: some complex instructions or instructions with errata are redirected into the microcode co-processor, and it's responsible for breaking those instructions down and emitting their lower-level uOps back into the execution scheduler. However, most instructions never touch microcode at all: they are decoded purely in hardware and issued into the scheduler directly. This is important because when people start talking about the x86 "microcode layer," they quickly get confused between the "microcode" (which is running _alongside_ the processor) and uOps, which are the lower level instructions issued into the processor's execution scheduler.
- allenrb 3y ago
  Thanks, I’d been wondering about this for years. I couldn’t imagine how microcode would be directly involved with so many pipeline stages and execution units. But if it’s reserved for the “highly unusual”, it all fits together. And the explosion of transistor budgets since 8086 means we can afford to implement all but the wackiest stuff in hardware.
- peter_d_sherman 3y ago
  Some excellent points! uOps and how they function should be included in any serious study of x86 hardware. In an ideal world, they would be well documented by vendors. (Random Idea: I wonder if it is possible to use some feature of some newer x86 chip to issue an x86 instruction -- and then to have it retrieve the uOp structure for that instruction as data... sort of like a uOp proxy or debug facility... If newer x86 chips don't have that function -- then a future x86 chip (which doesn't necessarily have to be be Intel) should...) >In a modern x86 CPU, "microcode" runs _alongside_ the main CPU core execution. Indeed! The broader picture of a CPU, any CPU, is that there's a lot that is happening at the same time. A lot of signals (and data!) moving around, and changing around for various purposes! (In other words, modern CPU's don't work linearly, like a computer program -- unless perhaps we talk about the earliest oldest CPU's...) But the study of uOps should be undertaken in any serious study of the x86... It should be pointed out that the number of uOps -- should be less, way less, than the number of x86 instructions, since each x86 instruction is implemented in one to several uOps, and these uOps frequently repeat across instructions... Which again brings us the academic question of "if there are way fewer uOps than x86 instructions -- then can the set of uOps if taken by themselves be considered a RISC?" Why or why not? Which brings us to Christopher Domas' discovery that some VIA x86 Samuel 2 processors had an "Alternate Instruction Set" -- what is the Alternate Instruction Set's relation to uOps? Is the AIS direct uOps, or 1:1 mapping? Or was it implemented by microcode that translated each AIS instruction into multiple uOps, and if so, how was that microcode implemented? As an addendum, I found the following resource for uops online: https://uops.info/index.html https://uops.info/index.html Anyway, some excellent points in your post!

bri3d 3y ago

It's also worth noting that "microcode" in a modern x86 CPU is not really the same thing as "microcode" in an older, "microcoded" CPU. What do I mean by this? Some older CPUs were truly "microcoded." The heart of the CPU was an interpreter loop which took instructions, then invoked a ROM / microcode routine corresponding to the implementation for that instruction. Each instruction began with the runtime selecting an instruction and ended with the microcode routine returning to a loop. A good example of this is the 8086: http://www.righto.com/2022/11/how-8086-processors-microcode-engine.html http://www.righto.com/2022/11/how-8086-processors-microcode-... . These CPUs worked like a traditional "emulator." That is NOT how a modern x86 CPU works. A modern CPU works a lot more like a JIT. In a modern x86 CPU, "microcode" runs _alongside_ the main CPU core execution. The microcode runtime can be thought of as a co-processor of sorts: some complex instructions or instructions with errata are redirected into the microcode co-processor, and it's responsible for breaking those instructions down and emitting their lower-level uOps back into the execution scheduler. However, most instructions never touch microcode at all: they are decoded purely in hardware and issued into the scheduler directly. This is important because when people start talking about the x86 "microcode layer," they quickly get confused between the "microcode" (which is running _alongside_ the processor) and uOps, which are the lower level instructions issued into the processor's execution scheduler.

allenrb 3y ago
Thanks, I’d been wondering about this for years. I couldn’t imagine how microcode would be directly involved with so many pipeline stages and execution units. But if it’s reserved for the “highly unusual”, it all fits together. And the explosion of transistor budgets since 8086 means we can afford to implement all but the wackiest stuff in hardware.
peter_d_sherman 3y ago
Some excellent points! uOps and how they function should be included in any serious study of x86 hardware. In an ideal world, they would be well documented by vendors. (Random Idea: I wonder if it is possible to use some feature of some newer x86 chip to issue an x86 instruction -- and then to have it retrieve the uOp structure for that instruction as data... sort of like a uOp proxy or debug facility... If newer x86 chips don't have that function -- then a future x86 chip (which doesn't necessarily have to be be Intel) should...) >In a modern x86 CPU, "microcode" runs _alongside_ the main CPU core execution. Indeed! The broader picture of a CPU, any CPU, is that there's a lot that is happening at the same time. A lot of signals (and data!) moving around, and changing around for various purposes! (In other words, modern CPU's don't work linearly, like a computer program -- unless perhaps we talk about the earliest oldest CPU's...) But the study of uOps should be undertaken in any serious study of the x86... It should be pointed out that the number of uOps -- should be less, way less, than the number of x86 instructions, since each x86 instruction is implemented in one to several uOps, and these uOps frequently repeat across instructions... Which again brings us the academic question of "if there are way fewer uOps than x86 instructions -- then can the set of uOps if taken by themselves be considered a RISC?" Why or why not? Which brings us to Christopher Domas' discovery that some VIA x86 Samuel 2 processors had an "Alternate Instruction Set" -- what is the Alternate Instruction Set's relation to uOps? Is the AIS direct uOps, or 1:1 mapping? Or was it implemented by microcode that translated each AIS instruction into multiple uOps, and if so, how was that microcode implemented? As an addendum, I found the following resource for uops online: https://uops.info/index.html https://uops.info/index.html Anyway, some excellent points in your post!