I find this... somewhat hard to believe, both because Intel's volumes are huge and it would mean something like the original Pentium III Processor Serial Number came back to haunt us.
There was recently a leak of Intel internal information, but based on the contents of this article, it seems that was really mundane (schematics, etc. --- which any companies buying and using their chips would easily have access to) in relation to the true depth of the secrets that lie within these processors... part of me really wishes there was far more that got leaked, because besides the security aspect, and the despicable practice of companies hiding information on devices from their actual owners and locking them out, this stuff is just intensely curiosity-satiating.
however, the existence of such instructions poses a security threat since there is publicly available PoC code  that can activate the Red Unlock mode on one of the modern Intel platforms.
Security threat, or maybe path to freedom...?
As an aside, the VAX microcode (and hardware schematics) can be easily found, for those interested in this stuff and looking for something less secretive.
Freedom means the owner (laptop thief) can steal the data from the previous owner (victim). Freedom means the owner can steal movies from hollywood. Freedom means Linus could create an OS without the blessing of Microsoft, etc... The problem is it is everything or nothing. So if you're a victim of theft, you want security. If you're pirating, you want freedom. If you want to clone the DVD your toddler keeps watching and destroying, you also want freedom. If you want to fully use all capabilities of your device, you want freedom.
Freedom in the OP context means we actually own the things we buy rather than existing in a total corporate oligarchy were we only ever lease the temporary right to use a product but never actually own it in the legal sense.
Take your own example of "owner" as in "rightfully, legally". There can be a huge difference between rightfully and legally. Think about all the things western nations took away legally from 'their' colonies. Or the completely legal civil forfeiture procedures in the US. Plenty of multidimensional trouble just by putting the word rightful after legal.
I want to actually own my hardware, hack mu hardware, and I would love to see things like TPMs and DRM and locked phones banished from this planet, even if this encourages some people to steal hardware. But plenty of corporations love bitlocker and love to trade away the useless hackability of hardware. And after talking for a few scary minutes with a movie exec, I got the impression they see computers as nothing more but theft machines and the current copyright enforcement mechanisms as way to inadequate.
Filenames for general search (in case the above links aren't found in the future):
"EP-ES0AA-DL-124_6of6_780uCode_Jan82.pdf" (There are 6 of them, matching the same 'Xof6' pattern, in case that wasn't obvious...)
"First new VAX in 30 years?"
mov $0x123, %r16
0: $0xb8 # opcode for mov
1: $0x10 # destination register
2: $0x23 0x01 0x00 0x00 # constant
So you can't just decode instructions starting from the program entry to find out if an opcode is trying to execute malicious code. You need to find all possible paths, including all computed jumps, to make that decision.
mov rax, [table + rax*8]
mov [table + rax*8], rax
Even better, there are multiple encodings of those instructions. And even better than that, there are Turing-complete subsets comprised only of printable ASCII characters. And even better than that, there are subsets of x86 the instruction set that can masquerade as readable English text: https://news.ycombinator.com/item?id=16312317
If your program counter ever diverges off to start executing unsanitized user data on x86, you are potentially pwn'd.
> The ENDBRANCH (see Section 73 for details) is a new instruction that is used to mark valid jump target addresses of indirect calls and jumps in the program. This instruction opcode is selected to be one that is a NOP on legacy machines such that programs compiled with ENDBRANCH new instruction continue to function on old machines without the CET enforcement. On processors that support CET the ENDBRANCH is still a NOP and is primarily used as a marker instruction by the processor pipeline to detect control flow violations.
> The CPU implements a state machine that tracks indirect jmp and call instructions. When one of these instructions is seen, the state machine moves from IDLE to WAIT_FOR_ENDBRANCH state. In WAIT_FOR_ENDBRANCH state the next instruction in the program stream must be an ENDBRANCH. If an ENDBRANCH is not seen the processor causes a control protection exception (#CP), else the state machine moves back to IDLE state.
Above text: https://binpwn.com/papers/control-flow-enforcement-technolog... (from page 8, page 15 also has info)
"How do prior processors execute these?": https://stackoverflow.com/questions/56120231/how-do-old-cpus...
Random example of someone trying to leverage this capability to harden an app: https://github.com/dotnet/runtime/issues/40100
Random comment that has a bunch of semi-interesting info in it: https://news.ycombinator.com/item?id=26061230 (the bit about the lack of Linux support is potentially(?) out of date)
LWN article: https://lwn.net/Articles/758245/
He set up a room full of PCs running his code and had hardware to auto-reset them when they crashed.
It's definitely possible to decide whether some programs will halt.
In an architecture that used fixed-length instructions and required the program counter to be aligned on them -- or had some other mechanism that disallowed overlapping instructions -- it would be easy to scan for an opcode like this. (Assuming you can distinguish the instructions from the data segment, anyway.) Such a solution doesn't run into any problems with the halting problem or Rice's theorem because it's not attempting to tell you with certainty whether the program will hit that opcode; it just gives you a one-sided test that says, aha, it could hit that opcode (because it's present) and therefore the program is suspicious. A negative result guarantees it won't hit the opcode, a positive result doesn't guarantee anything.
It's only x86's allowing of overlapping instructions that makes this problem hard. I mean, notionally you could scan for such an opcode at every offset, it's just that the false positive rate might be unacceptably high. (Whereas in the fixed-length instruction case, it wouldn't be, because a program using one of these opcodes at all truly is suspicious, regardless of whether it's hit. Although, again, I'm assuming you can somehow filter out the data segment; if you can't, then we have more of a problem.)
That's not the problem being posed here, though. To be useful as a security feature, it needs to be able to work on arbitrary x86 programs, i.e. ones that can contain potentially malicious opcode sequences. And many of these programs will not in fact be malicious, i.e. they never jump into the middle of some other legit opcode to have it interpreted differently. A one-sided test that tells you it could hit that opcode isn't useful if it flags every useful program on the computer.
They found that the instructions are actually executed, but they couldn’t jump to arbitrary microcode (a side effect of one of the undocumented instructions) because of a single lfence ucode op. They proved that at least on the atom processor they could unlock, the speculative execution of the undocumented instruction calculated an offset and placed it in internal registers even though the instruction was executed from the “green” (normal) operating mode.
so in short: no
"In mid-2020, our team managed to extract microcode for modern Atom processors that are based on the Goldmont
microarchitecture. It became possible to do this on Atom Goldmont systems-on-chip (SoCs) due to an arbitrary code
execution vulnerability in Intel CSME (Intel-SA-00086)."
 C. Domas. Breaking the x86 ISA.https://www.blackhat.com/docs/us-17/thursday/us-17-Domas-Bre..., Jul. 2017.