This is great. That a program can learn about and exploit the CPU on which it is running from unprivileged userspace reminds me of the notion in Charlie Stross' Accelerando of running a timing attack against the universe to learn about the virtual machine in which we are being simulated.

tl'dr of the slides:

    Found on one processor... instruction
    Single malformed instruction in ring 3 locks
    Tested on 2 Windows kernels, 3 Linux kernels
    Kernel debugging, serial I/O, interrupt analysis seem to confirm
    Unfortunately, not finished with responsible disclosure
    No details available [yet] on chip, vendor, or instructions

Related: https://www.theregister.co.uk/2013/05/20/intel_chip_customiz...

"Everybody hates the golden screwdriver upgrade approach, where a feature is either hidden or activated through software, but the truth of the matter is that chip makers have been doing this sort of thing for decades – and charging extra for it."

""We are moving rapidly in the direction of realizing that people want unique things and they are going to want them in silicon. In some cases, it will be done in software," said Waxman."

Also, Github says "several million" undocumented instructions.. is that right? I don't know much about assembly but that number sounds absurdly high.

This is highly interesting. I assume a lot of those are going to be debug and instructions to help the binning process. Some of these might even unlock access to parts of the CPUs we aren't supposed to have access too, opening the doors to custom microcode (unlikely that anyone outside the CPU OEM can do that though) but may allow us to disable "security features" such as the Management Engine. This is a really interesting approach and i would love to see the results ported to other hardware/vendors. The same could potentially be done with GPUs, ARM-CPUs, etc.

Here's a link to the slides [pdf]: https://github.com/xoreaxeaxeax/sandsifter/raw/master/refere...

Also from the same author https://sites.google.com/site/xxcantorxdustxx/visual-re

Christopher Domas does some very cool work. His System Management Mode exploit a few years back was quite nice. It will be interesting to see which processor it is that he found the ring 3 hard lockup instruction in...

...isn't the usability of the tool limited because it's running in userspace, which has fewer privileges in terms of what instructions can be ran?

Lot of weird stuff done happening nowadays in CPUs.

There's a lot of mystery in microcode (equivalent to the CPU firmware), the "system management mode" aka protection ring -2, and the infamous management engine.

I wonder what dbe0, dbe1, and df{c0-c7} do? They are present and undocumented in all of Intel, AMD and VIA's variations (see p4-p5 of the paper).

For what it's worth, the size-prefixed jcc/call binutils bug had already been fixed a couple of years ago: https://sourceware.org/bugzilla/show_bug.cgi?id=18386

The slides mention an 'apicall' opcode 0ffff0; searching the web turns up nothing but these same slides. Does anyone know anything about it?

Regarding the ring 3 hard lockup he didn't disclose yet: isn't that the recent kaby lake/skylake error, released about a month ago?

Chip vendors do the same in the course of validation, and technically even before any silicon has been fabricated, using simulators.

No instructions there to disable the IME?

found another that is QEMU-specific.

https://github.com/unicorn-engine/unicorn/issues/364

wow... anyone have a link to the video of his talk?

Is this basically a CPU fuzzer?

Out of curiosity, are there any toy compiler projects out there that try and make use of the incedental instructions? Could you possibly expect to see a with while performance boost (I'm thinking it would be unlikely...)

Someone built a fuzzer for cpus