💾 Archived View for dioskouroi.xyz › thread › 29399504 captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
________________________________________________________________________________
Is that the same Dmitry Sklyarov who was arrested by the FBI back in 2001, triggering a protest campaign?
https://en.wikipedia.org/wiki/United_States_v._Elcom_Ltd
.
Ah, memories.
Looks like
https://raw.githubusercontent.com/chip-red-pill/Sildes/maste...
(PDF, 1.8MB) might be a more useful link for general information?
The IME JTAG is pretty dang interesting. Shame they are sanctioned.
IMO the fact a huge portion of hardware ships with obscure, unverifiably secure microcode is one the biggest threat vectors in existence today.
Who are these people?
Its the work of Positive Technologies according to this article from grsecurity:
https://grsecurity.net/watch_your_stepping_atoms_breaking_ap...
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...
It’s a pretty BS sanction - PT is sanctioned just because the FSB is/was one of their clients with no claims that PT had anything to do with the actual hacks, at least as far as what was publicly disclosed. Compare what the link below says about PT vs what it says about some of the other entities insofar as to their complicity in the malicious incidents.
https://home.treasury.gov/news/press-releases/jy0127
What is this?
I would love to see an open-source x86 Microcode (or x86 subset Microcode) which would enable a separate open-source RISC CPU (i.e.,
https://opencores.org/projects?expanded=Processor
) to run x86 instructions, or a subset of x86 instructions...
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...
A little confused by what exactly you're proposing. Microcode is closely tied to a specific hardware implementation, there's no way the existing Intel microcode could be meaningfully re-used to drive other CPU cores, unless you also reverse engineered Intel hardware :-)
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
https://opencores.org/projects/next186
https://opencores.org/projects/v586
OK, well, to begin this discussion then, we either agree that Intel/AMD CPU's (and other x86 CPU's) -- are basically RISC CPU cores with microcoded instructions above the RISC core layer -- or we don't...
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 think I understand what you mean now, although it's different from my first interpretation.
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...
The fact that CPUs internally have microcode doesn't mean there's a different RISC CPU lurking underneath that you could just take the lid off of. In particular, the instruction decoder, which is what you're proposing to change, is not implemented in microcode; that would just be way too slow.
An x86 CPU is made for executing x86 instructions.
That would depend on how and what you can feed it? Say if you'd got a backend for something like LLVM, which emits the µOps directly, thereby circumventing the instruction decoder, if technically/architecturally possible at all. Instead of going through the instruction decoder.
Microarchitecturally Intel CPUs are not RISC. Most instructions translate to a single uop, at least in the fused domain, including read-modify and modify-write, which is antithetic to RISC. Also ups are not fixed size.
Also microcoding, which is distinct from uop splitting, predates RISC by decades.
When it appeared, RISC did not claim to be something distinct from (vertical) microcoding.
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.
Here's [1] an example of a CPU with the same functionality that the parent poster is interested in: the ISA being implemented in what amounts to microcode.
[1]
https://en.m.wikipedia.org/wiki/Transmeta_Crusoe
You don't really need the microcode to implement the x86 ISA in a meaningful sense unless you are literally trying to copy the exact behavior of a specific x86 CPU down to that microarchitectural layer--which would be odd to need since any program written for x86 + SIMD level has to work on any microarch Intel puts out.
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.
>You don't really need the microcode to implement the x86 ISA in a meaningful sense unless you are literally trying to copy the exact behavior of a specific x86 CPU down to that microarchitectural layer--which would be odd to need since any program written for x86 + SIMD level has to work on any microarch Intel puts out.
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)...
Article is about reverse engineering Intel's microcode.
> 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.
What would be the use-case for this? Most open source software is trivially portable across architectures. For the stuff that isn't there are code transformation tools like qemu-user-static.
Most likely there are microcode bugs being quietly exploited by powerful actors. Documenting/reversing/auditing the code in public makes it more likely white hats will find these bugs and mitigate them.. which takes a little power away from these actors, or at least costs them a bit of money to find a replacement.. and there's always the chance you find a bug worth billions to the agency exploiting it. So while we may never know about it, this is a big deal.
Your argument is one of convenience, mine is one of education/understanding...
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...
I think it would be better to abandon x86 than to try to understand it :)
I question the legality of this post: I'm pretty sure the Intel microcode specification is proprietary. While it's hard to say with certainty since Intel makes their website as hard to navigate as humanly possible, I doubt they'd hand over their secret sauce to competitors.
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.
Would you consider this to be illegal as well?
https://www.researchgate.net/profile/Nikola-Zlatanov/publica...
"Microcode Update. Microcode is a hardware layer of instructions involved in the implementation of the machine-defined architecture. It is most prevalent in CISC-based processors. Microcode is developed by the CPU7 vendor and incorporated into an internal CPU ROM during manufacture. Since the infamous “Pentium flaw,” Intel processor architecture allows that microcode to be updated in the field either through a BIOS update or via an OS update of “configuration data.” Today an Intel processor must have the latest microcode update to be considered a warranted CPU. Intel provides microcode updates that are written to the writable microcode store in the CPU. The updates are encrypted and signed by Intel such that only the processor that the microcode update was designed for can authenticate and load that update. On socketed systems, the BIOS may have to carry many flavors of microcode update depending on the number of processor steppings supported. It is important to load the microcode updates early in the boot sequence to limit the exposure of the system to any known errata in the silicon. It is important to note that the microcode update may need to be reapplied to the CPU after certain reset events in the boot sequence. The BSP microcode update must be loaded before No-Eviction mode is entered."
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...
This looks like bog-standard "black box" reverse engineering, which is legal throughout the US and EU.
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.
I'm not sure what you think is illegal about this. I suspect I'm either I'm coming at it from the wrong context, or I'm lacking in some info to fill in the gaps to make me think the same, as otherwise reverse engineering a processor is well tread (and legally supported) ground to my knowledge
The problem is that they attained this by decrypting the microcode. That runs afoul of DMCA circumvention rules unless it can fall under an exempt activity.
No, the problem is that the DMCA potentially makes decrypting microcode illegal.
Does Russia fall under the DMCA? That's where the developers seem to be located.
Github's servers aren't in Russia.
Github takes down the repo -> authors host it in a country whose copyright laws are not written by billion dollar companies.
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.