x86-64双字节非法操作码相关技术问题咨询

我最近编写了一个C程序用于查找x86-64的双字节非法操作码，并输出了结果。以下是部分非法操作码示例：

0x0f,0x04  0x0f,0x0a  0x0f,0x0b  0x0f,0x0c  0x0f,0x0e  0x0f,0x0f  0x0f,0x24  0x0f,0x25 0x0f,0x26  0x0f,0x27  0x0f,0x36  0x0f,0x37 0x0f,0xaa

通过搜索，我仅找到少量操作码的说明：

0x0f,0x0b - ud2 - 生成无效操作码。

0x0f,0x37 - getsec - 退出认证代码执行模式。

0x0f,0xaa - rsm - 恢复被中断程序的运行。

现咨询并解答以下技术问题：

问题解答 #

1. 是否有能解释大多数非法操作码的官方文档？ #

Intel和AMD的官方架构手册是最权威的参考依据：

• Intel的《Intel 64 and IA-32 Architectures Software Developer Manuals》（卷2：指令集参考）会明确标记哪些操作码属于未定义或保留类别，部分保留操作码会注明其专属的硬件/模式限制，或是为未来指令扩展预留的编码。
• AMD的《AMD64 Architecture Programmer’s Manual》（卷3：通用和系统指令）同样包含类似的详细归类说明。
  你提到的大部分双字节非法操作码，都能在这些手册中找到对应的定义或归属说明。

2. 非法操作码为何会存在？ #

非法操作码的存在主要源于三个核心原因：

• 预留扩展空间：x86架构坚持向后兼容，新指令集（如AVX、AVX-512）需要持续迭代，保留未使用的操作码是为未来的指令扩展预留编码，避免破坏旧程序的兼容性。
• 模式/硬件专属限制：部分操作码仅在特定运行模式（如系统管理模式SMM、虚拟化模式）或带特殊扩展的硬件上有效，在普通用户态或通用处理器中执行时会被判定为非法。比如getsec属于Intel安全扩展指令，仅在认证环境下可用；rsm是SMM模式专属指令，用户态执行会触发异常。
• 历史遗留：早期x86指令集设计时，部分编码未被分配用途，后续因兼容性优先级或设计规划问题，一直未被转为有效指令，成为遗留的未定义操作码。

3. x86-64架构为何不将这些非法操作码视为NOP或分配为有用指令？ #

• 向后兼容风险：若将非法操作码转为NOP，会导致依赖这类操作码触发异常的旧程序（如调试工具、安全检测程序、错误处理逻辑）失效。比如ud2常被开发者主动用来触发异常做边界检测，若转为NOP，这类程序会出现逻辑错误。
• 未来扩展需求：保留未使用的操作码是为了未来能高效添加新指令，如果现在分配给NOP，后续新增指令只能使用更长的编码，降低指令执行效率。
• 错误检测机制：非法操作码触发的#UD（无效操作码异常）是处理器的错误检测手段，能帮助开发者快速定位代码错误（如指令编码错误、内存损坏导致的非法指令），若全部转为NOP，这类错误会被隐藏，大幅增加调试难度。

内容的提问来源于stack exchange，提问作者vengy