[J-core] Breaking the x86 Instruction Set - Lot's of undocumented instructions found in x86 at this years black hat conference

Rob Landley rob at landley.net
Fri Sep 8 16:15:55 EDT 2017


On 09/06/2017 10:16 AM, Joh-Tob Sch├Ąg wrote:
> When you prepare a presentation for future j-core talks on why open
> hardware is a good idea you can show several examples of undocumented
> instructions in the main processor.
> These sometimes are exploitable but not under anybodies control.
> 
> The talk is here: https://www.youtube.com/watch?v=KrksBdWcZgQ

I independently came across that (via youtube recommendations) and
tweeted a link to the #j-core irc channel. It's a good talk.

I suspect what that really demonstrates are the hazards of a CISC
instruction set, multiple manufacturers, and 40 years of extensions. The
actual nefarious parts are more like System Management Mode and that ME
nonsense:
https://www.bleepingcomputer.com/news/hardware/researchers-find-a-way-to-disable-much-hated-intel-me-component-courtesy-of-the-nsa/

The emulators getting the corner cases wrong so you have code that only
runs on (certain) real hardware is kinda creepy though. (As demonstrated
in the talk.) Speaking of which we really need somebody to bring qemu up
to speed with j-core, so far it just does superh.

> A Sandsifter like tool can be used to compare actual behavior and
> simulated behavior of a CPU family. That approach might be interesting
> for j-core too.

Indeed. I'd be interested in seeing what you come up with if you give it
a try. However j-core has a fixed length instruction set (every
instruction is 16 bits, the trick is you can index relative to any
register so constants are loaded relative to code pointer and stuck
right before or after the function by the compiler).

So the main new trick of drilling down to see what variable length stuff
gets parsed is difficult to apply to this context.

That said, the proposed j64 design (which I need to write up and post to
the website on my next trip to Japan) adds a mode bit that interprets
some instructions differently. (16 bit operations become 64 bit
operations, for example, so you have 8, 32, and 64 bit and the compiler
would need to do funky things for "short". Or maybe toggle the mode bit,
dunno what'll wind up being cheapest.) So that's somewhat unavoidably
going to introduce complexity to the instruction set parsing, and it'd
be nice to have a systematic test to prove we didn't screw something up
when we get around to implementing that. :)

Thanks,

Rob


More information about the J-core mailing list