Your CPU Has a God Mode Nobody Told You About

You audit your dependency tree before installing an npm package. You generate an SBOM. You verify signatures. Supply chain security is table stakes now. But the thing all that software actually runs on — the CPU — when did you last check whether it ships with instructions that aren’t in the manual, or a second core nobody mentioned?

Up front: this is not a hot topic right now. Search the last month of discussion and you’ll find essentially nothing. So treat this as an old finding worth revisiting rather than breaking news. The silence is arguably part of the problem.

rosenbridge: one instruction from ring 3 to ring 0

In 2018, security researcher Christopher Domas disclosed a backdoor in VIA C3 x86 processors that he named rosenbridge. The premise is simple and unsettling. Alongside the x86 core, these chips contained a separate RISC coprocessor, and an undocumented instruction let you dispatch commands to it.

Why that matters: the coprocessor could bypass the x86 core’s privilege checks. An ordinary program running in ring 3 — user space, no special rights — could execute a few instructions and land in ring 0. No exploit chain. No memory corruption bug. No heap grooming. Just run the instruction.

Domas’s demo makes it visceral. An unprivileged process reads kernel memory and escalates to ring 0, and the whole thing is a handful of assembly lines. The operating system is irrelevant. Linux, Windows, whatever — none of them can see what happens on the floor below.

How you find it: fuzz the entire instruction space

The discovery method is the more interesting half. How do you find an instruction that isn’t documented? Domas’s answer was almost aggressively literal: fuzz the whole x86 instruction space.

x86 instructions are variable-length with famously baroque encoding. The theoretical combination count is astronomical. Domas built a tool called sandsifter that walks the encoding tree, pruning intelligently as it goes. Execute a candidate, watch whether the processor throws an exception or quietly does something. When the manual says “undefined” but the silicon executes it without complaint, you’ve hit something.

That’s how rosenbridge surfaced. The cost was steep: years of full-time research. One exceptional researcher, one chip family, one backdoor. Now count the number of CPU models shipping in the world. This is not a verification method that scales.

VIA’s explanation, and the question it leaves behind

VIA’s position was that this wasn’t a backdoor at all — it was a debug and test feature, and it was supposed to ship disabled. The functionality could indeed be toggled through a model-specific register.

The catch: on some of the chips Domas tested, it was enabled by default. Whatever the intent, the outcome is identical. On hardware sold to the public, anyone with the ability to run code could take the kernel.

Whether malice was involved is almost beside the point. A backdoor and a debug feature are indistinguishable at the implementation level. Both are the same object: an undocumented path that bypasses privilege checks. The difference lives only in the designer’s head, and you can’t read that.

The VIA C3 is legacy silicon now. But nothing about “we left a test-only privilege bypass switched on by accident” is specific to VIA.

You can’t open silicon

Run through your software verification toolkit. Open source. Reproducible builds. Static analysis. Fuzzing. Code signing. Dependency audits. Now apply that list to a CPU and see what survives.

The equivalent of source code is RTL, which is among the most fiercely guarded trade secrets on earth. Reproducible builds? There are a handful of leading-edge fabs on the planet and a single wafer run costs tens of thousands of dollars. You can inspect the finished product — grind the chip layer by layer, image it under an electron microscope, reconstruct the circuits. Against tens of billions of transistors on a modern node. Then there’s microcode, which updates after the chip leaves the factory, encrypted and signed. What logic is running on your CPU right now is known to the manufacturer and nobody else.

So the toolkit for silicon verification reduces to essentially one item: black-box fuzzing. Domas’s approach. It can prove presence but never absence. Finding a backdoor is a finding. Not finding one is not a result.

We didn’t verify. We decided to trust

This goes beyond the CPU. Intel ME (Management Engine) and AMD PSP are complete computers running independently of the main processor. Their own OS, access to all system memory, access to the network. They stay alive at moments when you believe you’ve powered the machine off. The firmware is signed, so you can’t audit it. And then there’s Spectre and Meltdown — not even backdoors, just the side effects of design decisions nobody noticed for two decades.

Honestly stated: we never verified hardware. We gave up on verifying it and decided to trust it instead. That decision is mostly reasonable, because there’s no alternative. Some people point to open architectures like RISC-V as the way out. But an open ISA doesn’t make the chip implementing it open. Even with a published design, confirming that what came out of the fab matches that design is very hard.

Should you worry

I don’t want to oversell this. The odds that your laptop has a backdoor in it are low. In most threat models, CPU backdoors rank far below ransomware and phishing, which are the adversaries you’ll actually meet.

Two things are worth holding onto anyway. First, when you write a threat model, mark “we trust the hardware” as a choice rather than a fact. In defense work or critical infrastructure — places where that assumption breaking is genuinely bad — the conversation changes from there. Second, support the research that keeps happening. A tool like sandsifter is itself a deterrent. The mere fact that somebody is systematically sweeping the instruction space raises the price of hiding anything.

We live in an era that demands a signature on every npm package. The silicon underneath all of it gets the manufacturer’s datasheet taken on faith — even after we’ve confirmed, at least once, that instructions absent from the datasheet were real. Where does your trust stack end? And what is holding it up down there?