Recently, Gravis made one hell of a dive into the horrible abuse of the BIOS to make a bootleg hypervisor, and then went even deeper to find truly cursed usage of forbidden processor features. User DecayWTF had a few things to add to this, and I wanted to add on further, but... well, I didn't want to hijack the thread. I've been putting this off for far too long, and now I'm going to finally get around to doing something I said I was going to do a few months ago.

Welcome to the first installment of my article series called "Education Yourself". This series aims to highlight the weird, failed, obscure, and interesting aspects of computing and technology history, usually in an entertaining tone with a short-ish length. I might go kind of fast, but I do hope that you get a kick out of this, and learn something new along the way. So sit back, relax, and prepare to be horrified when I tell you that your modern Intel or AMD x86-64 CPU... is not x86-64.

---

Part 1: How CPUs Actually Compute

So let's start with the very beginning. When a CPU is given an instruction to do something, that instruction first has to be decoded. Traditionally, this is done with hard-wired logic circuits within the CPU, using the opcode to select what the instruction is. But as CPUs grew more complex, they needed more and more logic gates to handle all the instructions. To solve this, CPU designers instead created a much simpler CPU core that only had a limited amount of instructions - the bare minimum needed - and then created a lookup table within a chunk of read-only memory within the CPU die that mapped the more complex instructions to a series of the limited internal instructions. This lookup table is what is known as microcode, and it allows for programs to be smaller and use the more complex instructions, at the tradeoff of having the translation from microcode to the internal instructions add extra overhead to processing time. There is a class of CPU called RISC that cuts out the middleman and makes people directly code on the limited internal instructions only, making programs larger but overall faster.

Using a microcode model for a CPU can make it very, very flexible. The Motorola 68000 uses such a model and can demonstrate this quite well. For starters, when issues arise, they can be fixed by simply modifying the mask ROM that contains the microcode, rather than redesign the entire CPU itself. The 68010 is such a revision, which fixes a problem with a certain MOVE operation not being properly protected, and adding a new MOVE instruction that is similar to the aformentioned operation, but correctly limited in its scope. This properly allows the processor to handle virtual memory correctly. Another upside is that the CPU can be completely reconfigured into a new purpose by simply replacing the microcode. IBM created the Personal Computer XT/370 in 1983, which used a pair of 68000 CPUs with replaced microcode to become a tiny embedded S/370 computer system!

Unfortunately, such a design is only as strong as its underlying internal core. The PowerPC was able to supplant the 68000 by emulating it faster than what the real hardware ran at. Which brings us to the next part of the story...

Part 2: AMD RISCs x86

Back in the mid 80s, AMD had one of the more popular RISC-style processors around, the Am29000 series. It was doing quite well, until the mid 90s, when AMD wanted to focus more on the x86 market. Rather than completely scrapping the next iteration of their RISC processor, they decided to use it as the internal core for their new K5 CPU, which implemented the x86 architecture as microcode. This turned out to work very well, creating a fast and robust processor! It's a design model they use even today. When Intel abandoned the Itanium, which is a dumpster fire that deserves its own dedicated piece, they adopted the 64-bit extension to x86 that AMD developed, and also made their own RISC CPU core to execute the instruction set as microcode. Using flash memory, the microcode can even be *updated* without needing to physically make a new chip!

So you're probably wondering, how can these processors be impostors? They're just using a lookup table to execute code on a more effective core. I mean, it's not like you can just bypass that lookup table and directly execute code on the core itself... right? Right?

Part 3: Intel Management Engine and AMD Platform Security Processor

So we've finally circled back to the start of this post. Ever since the 386SL processor, the x86 CPU family has a mode called "System Management Mode" which allows the CPU to basically access and do *anything*, with the original intent being for software-based thermal management. It has been christened "ring -2" since it is above the *hypervisor* (ring -1) and the operating system kernel itself (ring 0). But, it's not protected enough. Even though it supercedes all the other software on the computer, you can still see what it is doing from the *hardware*, given a fast enough logic analyzer to capture the address and data buses.

So how did Intel and AMD make something even more secure? Well... why does the code have to even go through the microcode decoding process?

This led to "ring -3", where the CPU stops pretending to be x86-64. The code is executed from within the CPU itself, bypassing microcode altogether, completely unable to be observed from hardware connections. This is why Intel ME and AMD PSP are considered so scary: we don't know entirely what is going on in here. It is shrouded in secrecy and protected by NDAs signed in blood. But there is a little bit of information we can glean and make educated guesses about.

For the AMD processors, we don't know what the exact code being executed is. However, it SHOULD be safe to say that the core it is running on is a descendant of the Am29000 series. This is the architecture they developed, and it would make sense to keep improving on it rather than take a lot of time, effort, and money to make a completely new architecture from scratch.

For the Intel processors, we don't know what the core itself is; it's some unknown, proprietary RISC design from within Intel. But we do know what the code being run came from. It is based on Minix, an operating system originally developed for educational use that inspired a certain Linus Torvalds to make his own kernel. However, it is a proprietary fork, and we don't know what the hell Intel has done with it.

Spooky shit!

NEXT TIME ON EDUCATION YOURSELF

Better address that dumpster fire... who wants to make smores?