sandsifter VS tatradas

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),

edge via patent and other legal protections" constantly-expanding-the-instruction-set approach.

So the issue, at least in x86-land is, "Who is the absolute source of truth with respect to the instruction set?"

Also, remember that Christopher Domas (Google him, you'll find a whole lot of interesting stuff) -- discovered that x86 processors typically can and do implement all sorts of undocumented instructions:

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. After binning the anomalies, the summarize tool attempts to assign each instruction to an issue category:

o Software bug (for example, a bug in your hypervisor or disassembler),

o Hardware bug (a bug in your CPU), or

o Undocumented instruction (an instruction that exists in the processor, but is not acknowledged by the manufacturer)

Anyway, thanks for the link! (The second one! )

A discussion of the techniques and results can be found in the Black Hat presentation. Technical details are described in the whitepaper. Slides from the Black Hat presentation are here.