x86_64架构下Windows 64位应用能否用INT 2E替代syscall执行系统调用？

问题解答 #

Wow64Transition跳转逻辑

你的理解是正确的。运行在64位Windows上的32位应用，调用32位ntdll的Zw/Nt系列函数时，会通过Wow64Transition切换CPU从32位模式进入64位模式，最终跳转到64位ntdll的同名函数入口，执行64位的系统调用逻辑。

INT 2E的触发规则

你看到的64位ntdll里的分支判断，校验的是KUSER_SHARED_DATA偏移0x308位置的系统调用标识位，这个位的取值由系统全局配置决定，和调用来源是不是WOW64没有关联：

• 标识位为0时走syscall快速系统调用路径
• 标识位为1时走int 2E软中断路径
  所以只要系统配置开启了这个开关，哪怕是从WOW64跳转过来的调用，也会用int 2E替代syscall执行。
  常见的把这个标识位置1的场景包括：系统开启内核调试模式、安装了依赖软中断挂钩实现功能的安全软件、系统层面配置了强制使用软中断的策略。

INT 2E与CET兼容性的关联

INT 2E保留的原因确实包含CET适配需求：
CET的影子栈机制会校验函数返回地址的合法性，syscall属于CPU原生快速系统调用指令，执行时不会向影子栈压入返回地址，早期CET实现对这个场景的兼容成本很高；而int 2E作为软中断，触发时的上下文切换逻辑符合常规的调用栈规则，能天然适配影子栈的校验逻辑。所以在部分启用了严格CET策略的环境下，系统会自动切换到int 2E路径保证兼容性。
补充一个认知修正：只有跑在64位Windows上的32位WOW64应用不会直接调用int 2E，原生32位Windows系统里的ntdll，系统调用本身就是直接通过int 2E触发的。

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