在某个时候，英特尔将开始运送支持CET的CPU( c ontrol-flow e nforecement t t ECHNOLOGY(，添加了两个指令ENDBR64和ENDBR32。
这两个将被编码为
F3 0F 1E FA for ENDBR64 and
F3 0F 1E FB for ENDBR32 respectively.
这些将如何在较旧的x86 CPU上执行？
例如，核心i5甚至复古五角星II？
更新：
F3 0F = prefix indicating newer instructions
1E = ENDBR
FA = ENDBR64
旧的GDB解码F3 0F 1E FA ENDBR64作为repz nop edx。
在64位模式下将其在Core 2(Merom(上进行单步，在架构状态没有变化，也没有故障/异常。(在旧的Ubuntu 15.10安装中在GDB 7.10中测试(。
根据https://gist.github.com/quasilyte/b60c94b9cb608d5b1a359d54f1be8aca，
0f 1e /r是一个2字节OPCODE，使用MODRM ，NOP r/m32, r32，与Intel文档的标准多字节0f 1f NOP相同。
它说它是pentium pro添加的，因此任何pii/piii或以后都可以。
https://github.com/nationalsecurityagency/ghidra/sissues/197#issuecomment-472906147说AMD文档记录了这些额外的nop opcodes；英特尔将它们列为"保留"。
rep通常会默默忽略它们不适用的操作编码。这使Intel/AMD可以灵活地使用REP作为强制性前缀的一部分，以便将来的说明以创建赢得的编码，以创建赢得的编码。t旧CPU的故障。
cpus比PPRO大，例如原始的奔腾，可能会错。就像0f 1f长NOP一样。
顺便说一句，您对解码的尝试没有意义。0f是2个字节Opcodes的"逃生"字节，因此1e push ds与如何解码无关。这就是1e本身解码的方式，而无需0f逃脱字节。(除了无效的64位模式以外。(
我自己最近遇到了ENDBR32指令的问题。VirtualBox版本6.0.14_Ubuntu r132055错误地将ENDBR32解码为非法OPCODE和STI的序列。当我需要中断禁用时，这将产生各种错误。我想出的唯一解决方案是使用-fcf-protection=branch和启用-mmanual-endbr选项调用GCC。
顶部的VirtualBox调试控制台，底部