CPU Backdoors

Absolutely. NICs in general are a very fruitful vector for persistence, and had been extensively studied by the NSA.

Generally, anything with a microcontroller that might run firmware (BIOS or UEFI), access DMA (via PCI, PCIe, FireWire) or be a storage peripheral that might pass code to the boot process (HDD/SSD/CD/DVD/BD/Flash drive/memory card firmware, including USB) or input (USB) is a potential problem.

That is a pretty damn big attack surface, and civilian researchers are able to do this too (the only big advantages Nation State Adversaries really have is funding and occasionally vendor cooperation, although I'd expect that to be rare in this case for operational security reasons - they might get datasheets under false pretenses, however, but so could we, we just wouldn't get away with it if caught ).

The TPM arch isn't so much of a problem here as trying to be a solution, but it falls short and has down sides too.

Supply chain integrity is a huge, possibly unsolvable problem. I'd be interested to see however some solutions to massively complicate any such attack, like an open trusted processor which boots ROM externally readable in hardware with no override and keeps secure hash chains of the firmware that loads - again, which would be externally verifiable with no way to override in firmware. That would put a crimp in their day.

    to reverse engineer the contents of intel's microcode updates

I don't think that's (sanely) possible. The amount of information needed about the silicon is very high and modern x86 processors are (for now) pretty much impossible to reverse engineer by delayering and taking pictures of the insides of the chip (14nm = ~60 atoms)... Also the costs of people who are able to reverse engineer such stuff would be very very high.

Who needs dirty trace-able CPU backdoors when Intel's SGX technology will allow them perfect plausible deniability to give NSA (or China if they force them by law) the key to all "secure apps" that will be using the SGX technology:

> Finally, a problem that is hard to ignore today, in the post-Snowden world, is the ease of backdooring this technology by Intel itself. In fact Intel doesn't need to add anything to their processors – all they need to do is to give away the private signing keys used by SGX for remote attestation. This makes for a perfectly deniable backdoor – nobody could catch Intel on this, even if the processor was analyzed transistor-by-transistor, HDL line-by-line.

http://theinvisiblethings.blogspot.com/2013_09_01_archive.ht...

> For example, it would be difficult to make an instruction like fyl2x or fadd cause a privilege level change. The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder.

This is not true. On modern Intel CPUs, FP instructions are decoded by the same decoders as all other instructions. As for the rest of the pipeline, the whole point of picking a microcoded instruction is that microcode can emit any ops.

> It would make more sense to encode the backdoor on an illegal opcode, i.e. an opcode that under normal conditions would generate a UD# exception, but with the correct values in the registers it would trigger some undocumented behavior.

This would only be exploitable through native code, and if suspicions arose, it would be detectable and it would be possible to extract the magic instruction from it.

A much better vector is a microcoded slow operation with lots of input bits, and that gets emitted by javascript jits.

> Another question is how to hide this backdoor in the microcode. Presumably, at some point someone might stumble upon the backdoor and ask around about it. If the backdoor depends on some "magic values", it would be relatively easy to spot just by looking at the microcode.

Microcode for modern CPUs is signed and encoded in some manner (encrypted?). So long as the bad guys get between the team that designs the microcode and whatever process that encodes it, no-one will ever be even able to see the evil ucode.

> There's also the point that the author mentioned of "fixing" the processor at some point during the production process. I don't think that the author understands the way mass production of microchips works. It's very much not possible to do something like this while keeping the production price on the same level (or someone noticing this extra step in the production process).

It doesn't take extra steps, it takes small modifications in the masks of a few metal layers. If someone could make their few modifications into the files before the masks are written, this would be damn near impossible to spot.

It's not that they're decoded by a seperate unit but that they're executed by it. Still, the values of the two operands aren't going to be available anywhere except that FPU. If the entire design team was in on it you could probably run a signal back from the FPU to the decoder to issue an instruction to do privilege escalation. As for the idea of looking at the value of multiple registers, well, modern OoO CPUs don't have registers in the sense that the author imagines they do and having a floating point uOp look at more than two operands would have humungous implications for the architecture. Like, Intel no longer being able to beat AMD implications.

But if you imagine emulating x86 in software everything the author writes makes perfect sense. It would be just a tiny bit of code to do all the checks the author mentions and it would be really easy to hide it. So I'm guessing the author is a software person without too much detailed familiarity with how modern CPUs work under the hood. And that's ok, since exploits like this are still possible, it's just that reality is really complicated and this is just an example of why it can be so hard to make up stuff convincingly[1].

If I were trying to do something like this I'd do it in the decoder. x86 has a lot of weird prefixes you can throw together and large constants can be included in the instruction stream. By using in invalid value as a floating point constant I can decrease the odds of someone accidentally discovering the problem. The extra fanout in the decoder will mean a bit more power and latency but x86 decode is already super complicated so probably nobody will notice. And once you know you've gotten a valid trigger I expect you should be able to issue uOps by the normal path that will do what you want. Only a few people will ever need to know.

[1]http://lesswrong.com/lw/uw/entangled_truths_contagious_lies/