sandsifter VS trapcc

This has some background.

sandsifter

This is a really clever technique! I was impressed by sandsifter[1] when it originally came out, and this seems an awful lot faster and less prone to false negatives (since it's purely speculative and doesn't require sandsifter's `#PF` hack).

At the risk of unwarranted self-promotion: the other side of this equation is fidelity in software instruction set decoders. x86's massive size and layers of historical complexity make it among the most difficult instruction formats to accurately decode; I've spent a good part of the last two years working on a fuzzer that's discovered thousands of bugs in various popular x86 decoders[2][3].

[1]: https://github.com/xoreaxeaxeax/sandsifter

[2]: https://github.com/trailofbits/mishegos

[3]: https://ww.easychair.org/publications/preprint_download/1LHr

Idea:

If any assembler/disassembler author/team out there wants to produce an assembler/disassembler which is authoritative (difficult to do on x86, because there are so many different possible combinations of instruction encoding, https://github.com/xoreaxeaxeax/sandsifter : "Typically, several million undocumented instructions on your processor will be found, but these generally fall into a small number of different groups.") -- then what they'd do is to create a third program -- which "pits" the output of Assembler A vs. Assembler B, Disassembler A vs. Disassembler B...

That is, between any two assemblers (for the same CPU architecture/instruction set), or any two disassemblers, where are the anomalies?

If we think about an assembler as a simple function, y=f(x), that is, I give it a string of ascii bytes as input (x), and I get a string (1..n) binary bytes as output (y),

A variation of this has been done using Intel MMU fault handling. Behold: https://github.com/jbangert/trapcc

This is a proof by construction that the Intel MMU's fault handling mechanism is Turing complete. We have constructed an assembler that translates 'Move, Branch if Zero, Decrement' instructions to C source that sets up various processor control tables. After this code has executed, the CPU computes by attempting to fault without ever executing a single instruction. Optionally, the assembler can also generate X86 instructions that will display variables in the VGA frame buffer and will cause control to be transferred between the native (display) instructions and 'weird machine' trap instructions.

This thread is about hacking something up and not building a product.

For example imagine somebody shares the "one instruction set computer" (https://en.wikipedia.org/wiki/One-instruction_set_computer) project or x86 MMU being turing complete (https://github.com/jbangert/trapcc). Both are clearly just interesting hacks (which may have some interesting implications about security and what does it mean to be "code" etc) and certainly are not intended to be practical products

fwiw, linked to from the article:

> As others have shown, we can compute using alphanumeric machine code[1] or English sentences[2], using only the mov instruction[3], or using the MMU[4] as it handles a never-ending double-fault. Here is my contribution to this genre of Turing tarpit: x86 is Turing-complete with no registers.

[1] http://www.phrack.org/issues.html?issue=57&id=15#article

[2] http://www.cs.jhu.edu/~sam/ccs243-mason.pdf

[3] http://www.cl.cam.ac.uk/~sd601/papers/mov.pdf

[4] https://github.com/jbangert/trapcc

I think trapcc is what you're thinking about maybe?

MMU gang.

page fault handling is Turing complete