Microcode Research Team
github.com
github.com
https://en.wikipedia.org/wiki/United_States_v._Elcom_Ltd.
Ah, memories.
IMO the fact a huge portion of hardware ships with obscure, unverifiably secure microcode is one the biggest threat vectors in existence today.
https://grsecurity.net/watch_your_stepping_atoms_breaking_ap... https://www.ptsecurity.com/
Positive Technologies got sanctioned by the US government. Seems Google deleted their blog as a result.
https://web.archive.org/web/20210419105554/http://blog.ptsec...
Perhaps the path to such an endeavor is simply taking an existing open-source FPGA RISC CPU (RISC-V would be a good choice) -- and then trying to implement a single x86 instruction in open-source Microcode, on it...
Success?
Well, then let's try another x86 instruction! Eventually we'll have a few!
If this or other x86 microcodes are copyrighted and/or patent-protected, what could occur is that a new microcode format (non-copyright or patent infringing) could be defined during this process...
Also, an x86 subset FPGA "Soft" CPU -- would never be as fast or as instruction-complete as current Intel or AMD CPU's...
In other words, such devices would be for hobbyist and/or educational use only -- they wouldn't compete with current Intel or AMD CPU's...
Sure, one could use every computer program in existence without becoming a computer programmer and gain useful function from them, and this would not be wrong in any way -- but there are also those of us who wish to understand things at a very deep level...
There are those of us who not only want to understand how computer programs work -- but how ISA's work, how the underlying hardware works, everything down to the substructures, the the adders, the logic gates, the flip-flops, the transistors, everything...
And that list includes (but is not limited to!)... x86 microcode...
Or more specifically, microcode in general...
You can implement the x86 ISA with existing Intel reference manuals and then testing instructions on a CPU to vet out differences/errata. Microcode doesn't add value to this. Knowing how the instructions work on this level can help optimize code and compilers. This is knowledge Intel likely builds into its ICC compiler that GCC, MSVC and others don't have.
Custom microcode could potentially run instructions faster than Intel's, but I really doubt anyone will get there. Another interesting thing is customized instructions. But again portability between microarch's is probably difficult.
SIMD is not necessary, nor is most of x86...
In fact, I'd be happy to emulate the 386's x86 instruction set in microcode -- and that would be the sum of it...
Even all of the 386's instruction set -- probably isn't necessary...
You see, what I alluded to earlier was "RISC Core" + microcode.
In other words, abstract a layer above a given RISC core with microcode (it could be completely different than Intel's) -- but it could implement x86 instructions.
The classic example here is the x86 'REP' instruction prefix.
REP when prepended to an x86 instruction -- basically says, "Hey x86 CPU, I want you to implement what basically amounts to a LOOP -- but with a lower-level RISC instruction..."
In other words, the looping behavior for those types of instructions -- are implemented at the microcode layer -- they are not implemented by additional physical hardware.
Perhaps I'm not thinking abstract enough here...
Perhaps the words Intel and x86 confuse things...
I suppose what I'd really like to see is an Open-Source RISC CPU (ideally implemented on an FPGA) -- which then implements a microcoded ISA on top of that, and heck, the microcoded ISA doesn't have to be x86 or Intel's -- the microcoded ISA -- could be a completely separate assembly language, but the thing is, it's Open-Source (unlike Intel/AMD's microcode to date), and created by an abstraction layer on top of the FPGA RISC (which should also be Open-Source)...
> abstract a layer above a given RISC core with microcode.
> I suppose what I'd really like to see is an Open-Source RISC CPU (ideally implemented on an FPGA) -- which then implements a microcoded ISA on top of that, and heck, the microcoded ISA doesn't have to be x86 or Intel's
Microcode's a very CPU-specific thing - as in specific to how the CPU is implemented internally, which can differ between vendor, microarch, stepping, or other things.
Different RISC CPUs may have different microcode--heck the same RISC CPU by the same vendor may have different microcode.
So:
- Sure, a RISC CPU can implement Intel x86 instructions in its microcode. But if you're thinking there could be a universal microcode "micro-binary" that implements the x86 ISA and can be applied to any CPU - nope. Would be nice but again the microcode is specific to a particular CPU microarch. So far easier and cheaper to just have a JIT facility in the operating system convert x86 opcodes to the equivalent RISC CPU opcodes when it's being loaded. You pay this penalty once if your OS does this right and caches the converted binary, and then you're done with it.
- If you want to expose the microarch so it can be directly programmed - that'd be interesting, but you're probably not going to make better decisions than the microarch in so far as keeping all the engines in the CPU 100% utilized. You might make it more secure, but it's a lot of work. It's probably more easier and profitable just to develop an ASIC for your application at that point, or if you're Apple, develop your own CPU.
I don't think many RISC processors even use microcode in the first place. On most RISC chips I know of, most instructions are cracked/decoded/ran in one cycle, with only very complex instructions needing to be run across multiple CPU cycles. Most RISC-V implementations don't use microcode at all, AFAIK.
If you're just saying we should make an open source x86-compatible CPU core that can be synthesized to FPGA, there are actually several projects that do so, including several on OpenCores, like:
https://opencores.org/projects/ao486
If we don't agree -- then I can submit link after link, URL after URL, text excerpt after text excerpt -- to prove to you that this is the case with Intel/AMD CPU's (and pretty much most other commercial CPU's that use large instruction sets) since the 1980's.
Anytime a CPU is microcoded in any way -- that's a good indication that there's a RISC core in there -- at a level below the microcode dispatch mechanism...
Why?
Because there are so many reasons to architect a CPU like that! It makes a huge amount of sense!
Why put tons of extra gates on a CPU to implement a super-large instruction set, many of which won't be used in most applications -- when the CPU design can be simplified and streamlined by use of a RISC core -- and microcode on top of that layer?
https://stackoverflow.com/questions/5806589/why-does-intel-h...
But you see, while most of the x86 Instruction Set is documented -- (I say most, because we always seem to be discovering new x86 instructions!) -- most of the x86 microcode -- the code which implements those x86 instructions -- has not historically been documented by Intel...
In other words, it's a gray area, black box, a "dragon"...
If someone wants to understand their computer, from the smallest transistor to the largest OS/Compiler/Application -- then they'd certainly seek an understanding of the microcode as well.
Historically Intel/AMD have not been forthcoming, not transparent, in their disclosure of Microcode, thus trying to gain an understanding into this aspect of computational hardware -- is left to independent researchers, such as the Microcode Research Team, above.
That's not good -- because in an ideal world, it would be transparent -- as transparent as any other piece of Open Source software...
Thus, my proposal to remedy the problem via an Open-Source equivalent.
Have I answered your question?
I agree an open source microcode for Intel/AMD would be a very good thing, although I think if it was based on actual Intel microcode, it would need to run on an Intel or AMD processor, or require a lot of work to reverse engineer a modern Intel microcode sequencer/front-end.
If the goal is to make an efficient, microcoded CPU that implements the x86 ISA, I can see where you'd benefit from re-using an existing core, although I think you'd need to make many modifications to the hardware to get there. If using a modern Intel chip as an example, say Skylake [0], a RISC chip could be turned into the "execution engine", but you'd still need to design a new front-end to fetch/decode/sequence the microcoded instructions to the RISC backend.
I'm surprised there's not more work to do something like that. Most FPGA re-implementations of CISC processors I know of don't seem to implement a core like this, I guess there are other bottlenecks that make it a pointless optimization unless you plan to make an ASIC out of it eventually.
[0] https://en.wikichip.org/wiki/intel/microarchitectures/skylak...
Also microcoding, which is distinct from uop splitting, predates RISC by decades.
Because at that time it became feasible to have fast cache memories for instructions, the speed of executing a sequence of instructions from the instruction cache became the same as the speed of executing the equivalent sequence of (vertical) microinstructions from a microcode memory.
Because microcoding complex instructions could no longer provide any speed advantage, the RISC proponents advocated the removal of the complex instruction decoder and of the microcode memory and the use of the space thus freed for faster execution units and larger cache memories.
So RISC CPUs were conceived as just (vertically) microcoded CPUs which exposed the micro-operation ISA directly to the programmer, instead if using it for implementing a complex ISA to be used by the programmer.
A few years later, the VLIW CPUs appeared as an alternative for RISC, which were conceived as CPUs with a horizontal micro-operation ISA exposed directly to the programmer.
An x86 CPU is made for executing x86 instructions.
On one hand, the subject of microcode would benefit from more transparency. Indeed, there are papers describing microcode behavior (Citadel's gpu papers come to mind).
With that said, I'm concerned that the authors are more interested in exploits, given they have a disassembler repo. While a disassembler alone doesn't warrant concern (microcode is very specific to hardware), it is concerning if their presentation's claim is true; that is, the whole Atom line has similar microcode. I hope I'm wrong. I'm by no means an expert, but the sanctions leave me uneasy lol.
I wish all russians a great day. Allowing this mentality to take a foothold in other parts of the world would be a major loss to humanity as a whole.
The authors appear to be in Russia, where black box RE is also (probably) legal. But they have the added benefit of living under a government that doesn't particularly care about that anyways, as long as the target isn't a domestic one.
There is also this walkthrough https://igor-blue.github.io/2021/02/04/secure-boot.html
And here in the EU some sorts of reverse engineering is legal which will include microcode, but interpretation of law is a minefield in its own right, because no one can tell what mood a Judge or Judges might be in on decision day! https://www.vidstromlabs.com/blog/the-legal-boundaries-of-re...