Breaking the x86 Instruction Set: how to find undocumented x86 instructions

Re:Breaking the x86 Instruction Set: how to find undocumente... by smegel on Monday September 11, 2017 @03:47AM (#15216763)

What's the bet the really secret instructions are hidden behind special conditional decode logic? I.e. the cpu wont even ask for the next byte if some register value is not set, possibly a secret register that first needs to be set via some other hidden instruction. Make that a sequence of 3 hidden instructions combined with arbitrary register and immediate values, and you won't get close to identifying them in a billion years.

I mean if you worked for Intel and your manager said "make me a really secret instruction" would your best response be "lets just not document it and hopes noone notices"?

What I would give to read the full microcode of the latest Intel processor. I am guessing it is stored in a vault with the real nuclear codes, Alien cadavers and the Holy Grail.

[ Parent | on HN ]

Re:Breaking the x86 Instruction Set: how to find undocumente... by vardump on Monday September 11, 2017 @05:37AM (#15217219)

You don't really need even that.

You just need a set of magic register values, like how CPUID [0] instruction already works.

[0]: http://www.sandpile.org/x86/cpuid.htm

[ Parent | on HN ]

Re:Breaking the x86 Instruction Set: how to find undocumente... by jevinskie on Monday September 11, 2017 @12:02PM (#15219515)

Yup, this was done in this years USENIX with AMD microcode. See the exploits that check for magic register values at [0] and the paper at [1].

[0]: https://github.com/RUB-SysSec/Microcode/tree/master/updates

[1]: http://syssec.rub.de/research/publications/microcode-reversi...

[ Parent | on HN ]

Re:Breaking the x86 Instruction Set: how to find undocumente... by micheljones on Monday September 11, 2017 @07:18AM (#15217618)

There is so many ways to implement backdoors in CPUs, even completely analog ones:

https://hackaday.com/2017/04/25/an-analog-charge-pump-fabric...

[ Parent | on HN ]

Re:Breaking the x86 Instruction Set: how to find undocumente... by mickronome on Monday September 11, 2017 @07:30AM (#15217677)

Such decoding logic might actually be detectable by something like differential power analysis, thought it could be excessively difficult if someone really wanted it hidden.

I suspect that really keeping it out of view would also cost both silicon and propagation delays in what would probably be some of the most critical paths, but then I'm not a vlsi engineer, or whatever the correct title would be :)

[ Parent | on HN ]

Re:Breaking the x86 Instruction Set: how to find undocumente... by smegel on Monday September 11, 2017 @09:45AM (#15218436)

When you say might...are there any case studies showing how the internals of a CPU can be exposed using this technique?

[ Parent | on HN ]

Re:Breaking the x86 Instruction Set: how to find undocumente... by greenpenguin on Monday September 11, 2017 @05:43AM (#15217250)

I'm not really qualified to answer this, but I suspect the instruction decoder(s?) would be decoupled from register state as much as possible (unless x86 is even weirder than I thought).

Given this, I suspect wiring in a path all the way from the relevant versions of the relevant registers might be quite expensive. Plus part of the decode logic now needs to block on a register value - so a timing based attack might find these.

More qualified comments welcome...

[ Parent | on HN ]

Re:Breaking the x86 Instruction Set: how to find undocumente... by dfox on Monday September 11, 2017 @08:01AM (#15217822)

i386 instruction decoding at least partially depend on what descriptor is loaded into (shadow) CS. For example the effects of 0x66 prefix are reversed between 16b and 32b code.

[ Parent | on HN ]