This is an interesting talk I found in the recommendations on YouTube: Breaking the x86 Instruction Set.
In some ways it brings me memories from the 90s again. Especially writing a code that will run differently depending on what CPU and/or mode is it executed on, I loved playing with such tricks.

I should note, however, that these DB E0 and DB E1 instructions that he listed as undocumented consistently across CPUs are actually 8087's FNENI and FNDISI, you can find them defined in 8087.INC in my fasmg package (well, fasm 1 knows them too). These were for the enabling and disabling the coprocessor's interrupts. It is probably for compatibility that they are still recognized, even though I'd guess they no longer do anything meaningful.

And F1 is the good old ICEBP, implemented by fasm as INT1.

{C0-C1}{30-37, 70-77, b0-b7, f0-f7} etc. is the family of opcodes for SAL instruction. Intel officially defines SAL and SHL to be alternative names for the same instruction, but SAL actually had a separate hidden code, which does the same as SHL anyway. I think I initially had these separate opcodes implemented in fasm (as I was using OPCODES.LST packaged with Ralph Brown's Interrupt List as my reference, and it lists the separate instruction code for SAL) but later I changed it to be in line with what is officially documented. Having a separate code for SAL was actually giving this system a nice symmetry, since there were then 8 shift/rotation instructions enumerated on 3 bits (0 - ROL, 1 - ROR, 2 - RCL, 3 - RCR, 4 - SHL, 5 - SHR, 6 - SAL, 7 - SAR). All the opcodes listed in the three rows in the video have the code 6 in the field that selects the shift/rotation instruction.

Finally for F6 /1 and F7 /1 we can also get a hint in the old reference: I'd guess they are one of the original 8086's contractions of opcode space that was preserved for compatibility, perhaps because some software might have been using it?

Oh, and since the F00F bug was also mentioned, I highly recommend reading Robert R. Collins's treatment of this topic from 1998. The workarounds did amaze me back in the day when I first read about them.

I can't believe some of these bugs are actually real. I mean, locking up the CPU from ring 3, seriously? Do they not do any sort of QA or what? Even more ridiculous if this happens in the future after this guy made his code open source so Intel/AMD can actually use it to test their products.

CPUs are complex. They have bugs. They will continue to get more complex. So they will continue to have bugs.

Also, the method he presented is very good for finding undocumented instructions, but it definitely cannot find all the potential hardware bugs. Even if a bug does not depend on additional context (like the contents of some GPRs or MSRs) it still may be invoked only by a very specific combination of fields in the opcode, looking for them would require an exhaustive search that is not realistically possible.

That doesn't mean they need to have bugs. Testing your own instructions is a no-brainer. How difficult can it be to have a proper test-case QA for every instruction and prefix available to see it performs as you want it to? It wouldn't even need to be an exhaustive search since Intel/AMD know all of the instructions they use so they can just test them all.

Of course instructions that under very special states lock the CPU are a different matter. Those bugs are harder to find when doing simple test-cases. I'm not complaining about those kind of bugs here but the obvious ones.

Having an instruction that always locks the CPU due to a bug is stupid and not excusable no matter how complex the CPU is. This should never pass the test-case.

Someone once told me: If you are not making mistakes then you are not making anything.

And let's not forget the Pentium FDIV bug.

Well if nobody made mistakes, test-cases would be useless. However just because you make a mistake and have bugs doesn't mean they have to be let in the wild, and that's the problem. Testing reveals simple mistakes that can be corrected before it's too late.

Like I said, bugs that happen only under very specific states/circumstances are a different thing, since those are hard to track down or test. But something as obvious as "this instruction always locks up the CPU" is inexcusable to me...

People can also make mistakes in the test cases. Just because something has a test case doesn't mean the test is complete, comprehensive, accurate or working.

I'm not sure how we should punish Intel for the inexcusable mistake. Stop buying from them maybe?

The five billion dollar Hubble Space Telescope was tested and verified and sent into space with a flawed mirror.

He didn't disclose the identity of the processor or its maker to protect people using it, so I'm not sure who to blame. FDIV/FOOF bug is a bit more excusable since it's so old. Back then, testing required more (comparatively speaking) resources and such.

Another consideration is that there can be secret modes that such fuzzing like this can't find. Setting a particular set of bits in particular registers (like say CR1, or something) can enable the CPU to perform other functions, or disable certain functions, or copy data direct from memory, zeroing the RNG seed, or pretty much anything. It could even be masked by generating the expected #UD exception making the user think everything is normal.

And even the regular and well known modes still may require attention. Especially long mode is known for re-defining many instruction codes, so the results may vary substantially from 32-bit. As for the 16-bit modes, this method could only work for V86, testing instruction codes in real mode would be a bit more difficult. But people were doing it back in the 80s and 90s, as far as I know.

Document doesn't have but when running there's no #UD(but some other fault)

Originally this encoding has not been documented, but since around 2008 the Intel manuals state this in the description of "Move to/from Control Registers" instructions:

There is another interesting talk from the same guy about "ring -2" or "power managment mode"

https://www.youtube.com/watch?v=lR0nh-TdpVg

The Breaking the x86 Instruction Set video got recommended today by youtube - Funny how the algo works. Did the ring 3 processor lock instruction thats discussed ever get documented? Given its been years I figure there must have been some movement on this by now.

https://www.youtube.com/watch?v=_eSAF_qT_FY

Good talk.

According to http://www.os2museum.com/wp/undocumented-8086-opcodes-part-i/ , {D0-D3}{30-37, 70-77, b0-b7, f0-f7} was (C)SETMO(CL). Seems they didn't wire for this opcode, and if 80C86 exist (not sure if they do) this unlikely do the thing