Hacker News Reader

The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder.

I don't think that has been true for a very long time.

If the backdoor depends on some "magic values", it would be relatively easy to spot just by looking at the microcode.

The problem with both your theory and the article's theory is that nobody outside the chip companies themselves really knows how the microcode works. This reduces both the people who could pull off such a backdoor and the people who could discover it to a very small number.

A similar thing applies to your point about changes during manufacturing.

Overall, this means that CPU backdoors are a thing to be concerned about, keeping in mind that it's probably a technique that will, for a long time, be limited to the kind of people who were responsible for Stuxnet.

I don't think that has been true

In support of that: http://www.xbitlabs.com/images/news/2009-11/amd_bulldozer_sc...

There are so many people involved in the design and manufacturing of a processor, that I don't see how it's possible to hide a backdoor, either in the microcode or during manufacturing. We're not talking about some secret government agency, we're taking about a place with many workers around the world, with different agendas. Eventually someone will find about about the backdoor and leak information about its existence.

> There are so many people involved in the design and manufacturing of a processor, that I don't see how it's possible to hide a backdoor, either in the microcode or during manufacturing. We're not talking about some secret government agency, we're taking about a place with many workers around the world, with different agendas.

However, the end result of both CPU design and the microcode team is essentially unreadable.

No-one outside Intel can read their microcode updates, as they are obfuscated in some way, possibly encrypted. This means that compromising just the last step, the people or tools doing the obfuscating, means you can output whatever you want with no-one on the team being able to find it out.

The same is true for the CPU design. Created masks are generally not looked at, other than to verify small spots if it seems there are bugs. Because of this, compromising the last step between the model and the mask would allow you to output whatever you want with no-one of the thousands of the people working on it ever finding out.

This is a very interesting topic - how much can we rely on the tendency of people to leak.

I notice that despite the thousands who have worked for Intel, virtually no Intel confidential material has been leaked. At least, that I'm aware of.

People value their careers and houses, and I'm sure Intel threatens employees with consequences for leaking.

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/

> having a floating point uOp look at more than two operands would have humungous implications for the architecture.

Actually, in HSW and later all FP ops can have 3 register inputs, they added one to support FMA.

However, this is irrelevant. The scenario basically everyone has been talking about is exploiting a microcoded instruction. In case you are unfamiliar with the term, when the CPU frontend reads in an instruction it deems microcoded, it will stop decoding normally, and instead reads a sequence of ops from the microcode buffer that corresponds to the microcoded instruction you just executed. These ops can be anything the cpu can run -- it would be completely possible to emit a bunch of floating point compares, instructions to and their results, then take this result to the integer flags and do compare and jump on them. And for the longer microcoded ops like fp transcendentals, it would probably be possible to hide all these ops in the shadow of the normal ops, so that there would be no increase in latency.

Oh, I see. I hadn't recognized that fyl2x was a microcoded instruction. Looking at the page again I totally missed the footnote and he's completely right.

However, for FMA I assume that they break the FMA instruction into two uOps that have to be issued back to back to the same execution unit. The changes to the reorder register renaming logic would be just too painful otherwise, especially since Intel uses a unified scheduler which also handles the integer ops.

EDIT: I suppose that I tend to forget about microcoded instructions since none of the instruction sets I've worked with directly has really had them.

> However, for FMA I assume that they break the FMA instruction into two uOps that have to be issued back to back to the same execution unit. The changes to the reorder register renaming logic would be just too painful otherwise, especially since Intel uses a unified scheduler which also handles the integer ops.

FMAs are not split, they are executed as single instructions issued in a single cycle. There were no changes to renaming or reorder logic from 3-op instructions. Since SNB, Intel has been using PRF, where the rename system is decoupled enough from the scheduler that there is no need for any changes.

If the entire design team was in on it...

If that's the case you could probably do just about anything...

> 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.

> "magic values"

Actually you can make something that checks for a magic value without encoding the magic value in the microcode. Triggering a buffer overrun in software often requires very particular inputs, but those inputs are not explicitly encoded in the binary. If you were clever, you could make microcode that looks correct, but backdoors under the right conditions.

Modifying the masks struck me as a fairly farfetched scenario. I don't know how many spare gates a processor ships with but you would have to know the design pretty intimately to be able to include something malicious by remapping, both in terms of logic and physical constraints.