<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">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.<br></div><div class="gmail_default" style="font-family:monospace,monospace">These sometimes are exploitable but not under anybodies control.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">The talk is here: <a href="https://www.youtube.com/watch?v=KrksBdWcZgQ">https://www.youtube.com/watch?v=KrksBdWcZgQ</a><br><br></div><div class="gmail_default" style="font-family:monospace,monospace">TL;DW:<br><ul><li>we test, reverse engineer and disassemble programs because we can not trust them because software is shown to be broken.<br></li><li>We do not do that for CPUs.</li><li>Documentations are full of holes and sometimes introduce new instruction to the public many years after they were in silicon</li><li>The presenter wrote a fuzzer for cpu instructions. It places an blob at a page boundary (from executable to non executable) and executes it. If the instructions is longer than what is on the page he catches the fault and shifts everything to the left. That way he can find out what bit changes of an instruction change the length of the instruction (heuristic for change in behavior).</li><li>He found many undocumented instructions</li><li>He found bugs in disassemblers which parse code wrongly which allows to hide malicious code</li><li>Found an azure hypervisor detector<br></li><li>He found an hold and catch fire instruction on an esoteric instructions.</li><li>available on GitHub as sandsifter</li></ul><p>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.<br></p><p><br></p></div></div>