In my last post breaking down classic Intel microarchitectures, I mentioned in passing that my Core i3-350M was the first processor in my lab setup packaged alongside Intel's Management Engine-and I promised I'd eventually write a dedicated post about why that little detail changes everything. Well, here we are.
When you power on a modern x86 computer, you like to think your operating system-whether it's Linux, BSD, or Windows-has total ownership of the hardware. But that hasn't been true for a very long time. Tucked away beneath your kernel sits an entirely separate computer system running its own operating system, executing code on its own dedicated processor, and maintaining complete, unfiltered access to your RAM, storage, and network interfaces. You didn't install it, you can't inspect its source code, and you can't truly turn it off.
Both major x86 chipmakers have built their own version of this hidden management coprocessor:
It's fascinating to look back at where both companies started compared to where we are now. Intel's CPU journey began in 1971 with the historic Intel 4004-a 4-bit chip containing just 2,300 transistors running at 740 kHz. AMD entered the processor business four years later in 1975 with the Am9080, a reverse-engineered clone of Intel's 8080 fabricated on AMD's own manufacturing process. Decades after competing over raw clock speeds and pipeline efficiency, both giants arrived at the exact same architectural decision: putting an autonomous microcontroller on the board that operates outside user control.
While Intel ME and AMD PSP share a similar mission, their physical architecture and silicon layouts are fundamentally different-especially when it comes to where their processing cores live.
AMD chose complete physical integration. The AMD PSP core isn't a separate chip sitting on the motherboard; its execution core is an ARM Cortex-A5 processor equipped with ARM TrustZone technology. To be crystal clear about its location: this ARM Cortex core is integrated directly inside the main AMD CPU die itself as a hardware coprocessor block. Before your primary x86 cores ever fetch their first instruction, that tiny ARM Cortex core wakes up, handles initial DRAM configuration, and decides whether the rest of the CPU is even allowed to boot.
Intel took a slightly different path. The Intel ME execution core doesn't sit inside the CPU die on classic architectures; instead, it lives within the Platform Controller Hub (PCH)-the chip that evolved from the traditional Southbridge. Early Intel ME implementations ran on 32-bit ARC microcontrollers (specifically the ARCTangent-A4 and ARCompact architectures). Starting with ME version 11 (introduced alongside Skylake CPUs), Intel ditched ARC and replaced it with a 32-bit Intel Quark x86 core embedded inside the PCH.
Where the firmware and operating systems live reveals another huge structural divide:
What kind of software runs on these invisible microcontrollers?
For Intel ME 11 and newer, the operating system is none other than MINIX 3-a lightweight, open-source UNIX-like microkernel created by computer science professor Andrew Tanenbaum. (Older versions of ME running on ARC cores used the ThreadX RTOS instead). It's one of the great ironies of computing history that MINIX, the teaching OS that famously inspired Linus Torvalds to write Linux, is now running stealthily on hundreds of millions of Intel computers across the globe.
AMD's PSP runs a proprietary, closed-source micro-OS running inside the ARM Cortex-A5's isolated TrustZone execution environment. Because AMD has consistently refused community calls to open-source the PSP firmware, its internal kernel operations remain largely opaque to independent security researchers.
In standard x86 security models, user software runs at Ring 3, kernel code runs at Ring 0, hypervisors sit at Ring -1, and System Management Mode (SMM) operates at Ring -2. The Management Engine and PSP operate at Ring -3. They sit entirely beneath the operating system and hypervisor, possessing unrestricted hardware authority over every single component on your system.
Here's the kicker: the management engine is constantly running, even when your computer is turned off. As long as your PC is plugged into the wall-or your laptop battery has a charge-the motherboard's standby power rail (5VSB) keeps the ME or PSP core powered up and listening in the background.
Because these shadow systems have direct access to system memory via Direct Memory Access (DMA) and control over the network hardware, an exploit in their firmware introduces massive security risks:
People often ask how the SMBIOS (System Management BIOS) relates to all of this. SMBIOS is a standardized data structure exposed by system firmware that provides the host operating system with a detailed inventory of the underlying hardware-reporting things like RAM speed, processor sockets, and motherboard revisions.
SMBIOS itself doesn't execute management engine code or handle security tasks. Instead, it acts as an informational bridge. The system firmware writes status flags, capability records, and provisioning states for Intel ME or AMD PSP directly into the SMBIOS tables (and DMI records). When you run a command-line tool inside Linux to check if Intel AMT is provisioned or if PSP security features are enabled, that tool is typically parsing those SMBIOS structures to read the status reported by the management engine.
The core problem comes down to user ownership. When you purchase hardware, you ought to have full control over the code running on it. Management engines break that contract entirely. They force a closed-source black box into the foundation of your hardware, running code you can't review, controlling peripherals you can't isolate, and remaining active even when the machine is supposed to be powered off.
Now, to be fair, the traditional BIOS/UEFI firmware isn't without its own concerns-it can technically run in the background all the time via System Management Mode (SMM), too. But there's a big difference: you can at least dump the BIOS image straight off the SPI flash chip with a hardware programmer and disassemble or decompile it in tools like Ghidra or IDA Pro to analyze what it's doing. The management engine goes a step further into secrecy. Key parts of its code are cryptographically signed, encrypted, or locked away in immutable on-die ROM, making complete reverse-engineering a massive uphill battle.
Project communities have spent years fighting back with open-source tools like me_cleaner, which strips unnecessary modules out of the Intel ME firmware image stored on the SPI flash chip, leaving only the bare minimum code required to initialize the hardware and prevent the motherboard from auto-shutting down after 30 minutes. Even the US National Security Agency (NSA) recognized the danger-requiring Intel to include an undocumented kill-switch bit (the High Assurance Platform, or HAP bit) so government agencies could disable the ME on high-security machines.
Working on clean, retro x86 systems without these hidden microcontrollers isn't just about nostalgia. It's a stark reminder of what computing felt like when the hardware in front of you actually belonged to you-executing only the instructions you told it to, and nothing else.
Threat: Ask for permission before republishing full text copies of this blog, or I will hunt you down.
Copyright © 2026 ~cartwright