3 ms·

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 e

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/ http://lesswrong.com/lw/uw/entangled_truths_contagious_lies/

Tuna-Fish 12y ago
> 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.
- Symmetry 12y ago
  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.
  - Tuna-Fish 12y ago
    > 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.
sliverstorm 12y ago
If the entire design team was in on it... If that's the case you could probably do just about anything...

Tuna-Fish 12y ago

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

Symmetry 12y ago
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.
- Tuna-Fish 12y ago
  > 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.

sliverstorm 12y ago

If the entire design team was in on it... If that's the case you could probably do just about anything...