Is there any reason to believe those opcodes do anything close to what they did on 8086? In any case, albeit relevant, I think your comment is beside his main point.

I think his point is more that we have little ways to verify the trust we put in the CPUs. Complete reference manuals are great and all, but they rarely are complete. At the very least this kind of tool will put some pressure on the manufacturers to not leave out any details (as innocuous as they may be).

Given that x86 is built from 8086 architecture and inherited its instruction set, I think it's more reasonable to ask if there's any reason to believe those codes DON'T do what they did on the 8086. Furthermore, it would be easy enough to verify. Run both instructions on each processor and check the results.


If his presentation was purely that he created a clever way to verify processor instruction sets, and that he found some instructions he wasn't sure what they were and offered them up as a way to crowdsource their meaning, that would be fine. The idea of independently auditing that hardware does what it's advertised to do is great. However, some of his conclusions are flawed, some of his claims are false and trivially provably so, and his presentation of his findings to the public is irresponsible. He's CLEARLY trying to strike a fearful tone, but I'm not convinced it's deserved.

Mostly it chaps my ass if someone publishes claims I can debunk in 2 seconds of googling in my underwear.

Fair enough.

I can't watch the video right now but the idea is not without merit. It's well known Intel/AMD and the rest tend to have extra registers and other functions in cases there is problems, as well as microcode.

https://en.wikipedia.org/wiki/Microcode

Which is used to reprogram a chip if there is issues.

Things are less hardcoded after their original fuck up with the FP look up table.

My bigger concern is side-channel attacks. It would be very difficult to verify if a certain chip leaked info via other means then hidden instructions in there.