不能只靠VMCALL判断未授权Hypervisor，因其执行无异常、可被静默处理；真正有效的是CPUID叶子0x40000000响应+多级fallback验证。
不能只靠 VMCALL 是否成功来判断存在未授权 Hypervisor，它本身不报错、不触发异常，且现代 VMM（如 Hyper-V Gen2、AWS Nitro）默认拦截并静默处理该指令；真正有效的信号是 CPUID 叶子 0x40000000 的响应行为 + 多级 fallback 验证。
为什么 VMCALL 单独用没意义
VMCALL 是 guest-to-hypervisor 的特权调用指令，但它的执行结果完全由 VMM 控制：没有 VMM 时会直接触发 #UD（非法指令异常）；有 VMM 时通常被拦截、处理、返回，不抛异常也不改寄存器——你根本不知道它有没有被执行。更糟的是，部分云平台（如 Azure Nested Virtualization）会把 VMCALL 当作普通 NOP 处理，返回 EAX=0，看起来“一切正常”，实则掩盖了底层虚拟化。
- 在物理机上执行
VMCALL会 crash（SIGILL），但你不能靠 crash 来检测——程序直接挂了，不是“检测到物理机” - 在 VMware Workstation 中启用
hypervisor.cpuid.v0 = "FALSE"后，VMCALL仍可执行，但 CPUID 不暴露 hypervisor，形成“有调用无标识”的盲区 - Windows 上若未开启 HVCI（Hypervisor-protected Code Integrity），
VMCALL可能被内核驱动劫持，返回伪造结果
必须先查 CPUID 叶子 0x40000000 的响应模式
这是唯一无需特权、不可绕过的入口点。VMM 必须实现该叶子（否则客户机无法识别自身运行环境），但实现质量差异极大：有的返回真实 vendor ID，有的返回全零，有的甚至返回乱码或截断字符串。
- 先调用
__cpuid(info, 0)确认 CPUID 基础功能可用（info[0] > 0），否则跳过全部后续检测 - 再调用
__cpuid(info, 0x40000000)（MSVC）或__cpuid_count(0x40000000, 0, a, b, c, d)（GCC/Clang） - 若
info[0] == 0：大概率是物理机（但 AWS Nitro 实例也返回 0，需继续查 DMI 或 cgroup） - 若
info[0] >= 0x40000001：检查info[1]、info[2]、info[3]拼出的 12 字节 vendor 字符串，用 uint32_t 直接比对，例如：info[1] == 0x4b4d564b && info[2] == 0x4b4d564b && info[3] == 0x4b4d564b→ “KVMKVMKVM” - 若
info[1..3]全为 0 或重复值（如 0x00000000 / 0xdeadbeef），说明 VMM 故意隐藏，此时应立即触发二级检测（WMI / DMI / cgroup）
交叉验证时避开常见权限和伪造陷阱
单点检测失效是常态，关键在于 fallback 路径是否可控、是否覆盖主流场景。
立即学习“C++免费学习笔记（深入）”；
- Linux 下读
/sys/class/dmi/id/product_name：普通用户可读，但 Google Shielded VM 会返回空，需同时查/sys/class/dmi/id/sys_vendor和/proc/1/cgroup - Windows 下优先走 WMI：
Win32_ComputerSystem.Manufacturer，失败时 fallback 到注册表HKEY_LOCAL_MACHINE\SYSTEM\HardwareConfig\Current\SystemBiosVersion（含 VMware/Hyper-V 字样），而非依赖Win32_BIOS.SMBIOSBIOSVersion（常被伪造） - 容器与虚拟机易混淆：若
/proc/1/cgroup含docker或kubepods，直接判定为容器环境，不再走 Hypervisor 检测路径——因为容器内嵌套 KVM 是合法场景，但“未授权加载的 Hypervisor”一般不会出现在容器里 - 避免用
std::system("dmidecode -s system-product-name")：需要 root 权限，且在 Alpine 或 distroless 镜像中根本不存在 dmidecode
最易被忽略的一点：检测逻辑本身可能被 JIT 编译器优化掉（尤其是 VMCALL 这种无副作用指令），GCC/Clang 在 -O2 下可能直接删掉整段 inline asm。务必用 asm volatile (".byte 0x0f, 0x01, 0xc1" ::: "rax", "rbx", "rcx", "rdx") 并禁用优化段，或改用 __cpuid 这类编译器内置函数——它们自带 memory barrier，不会被误删。
