我可以依靠 TSC 增量频率进行 VM 检测吗？

如何解决我可以依靠 TSC 增量频率进行 VM 检测吗？

我需要检测我的代码是否在 VM 上运行，因为我知道我的一些用户会试图伪造它，假装它在真机上运行，​​而实际上并没有。 AFAIK 依赖供应商或设备名称不是一个好主意，因为它可以通过更改 VM 设置或更换 BIOS 固件来覆盖。问题是，我可以依靠 TSC 频率吗？

解决方法

问题是，我可以依赖 TSC 频率吗？

简短回答：不（可能）

用于以字面方式使用 TSC 频率（例如“该 CPU 的 TSC 频率应该是 2345 MHz，但 TSC 频率被测量为 1234 MHz”）；通常（对于其他人在未知计算机上安装的软件），无法知道 CPU 的 TSC 频率应该是多少；鉴于管理程序可以告诉您任何感觉通过。 cpuid（如果不以某种方式依赖 cpuid，就无法确定 TSC 频率应该是多少）。

对于简单的管理程序，您可以使用 TSC 来检测导致“进入管理程序的陷阱”的原因（因为它比在裸机上花费的时间要长得多）。

但是，更复杂的管理程序可以通过虚拟化 TSC 来隐藏其时间消耗。这可以包括一种“橡皮筋”技术 - 例如告诉客人“虚拟 TSC 频率”比实际 TSC 频率慢一点，然后在“虚拟 TSC”超前时引入短暂的暂停。或者，hyper-visor 可以只告诉来宾“虚拟 TSC 频率”与真实 TSC 的频率相同，通过减少“TSC 偏移”来隐藏“陷阱到 hyper-visor”的额外时间消耗，然后平滑随着时间的推移去除 TSC 偏移量，这样来宾无法知道时间去了哪里（并且无法知道时间是否没有被其他东西消耗，例如系统管理模式或稍慢的 RAM 或 ..）。>

大部分；最终结果是一场竞赛 - 当您找到检测 VM 的新方法时，VM 开发人员会找到改进其虚拟化和防止检测的新方法。

,

您需要将多个时间源放在一起进行比较。如果可以，您应该将多个内核放在一起比较。

基于 TSC 的检测最简单的解决方法是执行 Brendan 提到的橡皮筋。但是当涉及多个核心时，就更难欺骗 TSC。 TSC 偏移/乘数是每个内核的。如果 VMM 试图隐藏自己，每个 VMEXIT 都会导致 TSC 倾斜。

现在，当任何单个核心退出时，VMM 可以尝试踢出其他 vCPU，以便它们可以同步 TSC，但这非常昂贵（并且可能存在其他可检测的问题，因为很难同步重新进入的 vCPU）。

总而言之，您至少需要两个内核：

1. 一个核心应该设置一个原子变量，调用 RDTSC，然后调用一堆带有强制 VMEXIT 的指令（例如 CPUID），调用 RDTSC，然后取消设置原子变量。
2. 另一个核心应该监视该原子变量，然后调用 rdtsc，然后再次监视它，最后在未设置时调用 rdtsc。

这需要一些校准。像这样的事情时间可能非常挑剔。 此外，您可以使用递增变量的循环来充当 rdtsc 的代理，但对此的校准可能更加挑剔（但值得，因为 TSC 可以普遍撒谎，包括在上面提到的第二个核心中）。