【发布时间】：2021-05-25 09:09:43
【问题描述】：
我需要检测我的代码是否在 VM 上运行，因为我知道我的一些用户会尝试伪造它，假装它在真实机器上运行，而实际上它没有。 AFAIK 依赖供应商或设备名称并不是一个好主意，因为它可以通过更改 VM 设置或替换 BIOS 固件来覆盖。问题是，我可以依赖 TSC 频率吗？
【问题讨论】：
标签： operating-system virtualization
【发布时间】：2021-05-25 09:09:43
【问题描述】：
问题是，我可以依赖 TSC 频率吗？
简短回答：不（也许）
用于以字面方式使用 TSC 频率（如“此 CPU 的 TSC 频率应为 2345 MHz，但 TSC 频率测量为 1234 MHz”）；通常（对于其他人在未知计算机上安装的软件）没有办法知道 CPU 的 TSC 频率应该是多少；鉴于 hyper-visor 可以通过它告诉你任何感觉。 cpuid（如果不以某种方式依赖 cpuid，就无法确定 TSC 频率应该是多少）。
对于一个简单的虚拟机管理程序，您可以使用 TSC 来检测导致“虚拟机管理程序陷阱”的某些东西（因为它比裸机上花费的时间要长得多）。
但是，更复杂的管理程序可以通过虚拟化 TSC 来隐藏其时间消耗。这可以包括一种“橡皮筋”技术 - 例如。告诉客人“虚拟 TSC 频率”比真实 TSC 频率慢一点，然后在“虚拟 TSC”超前时引入短暂的停顿。或者，管理程序可以只告诉客户“虚拟 TSC 频率”与真实 TSC 的频率相同，通过减少“TSC 偏移”来隐藏“陷阱到管理程序”的额外时间消耗，然后进行平滑处理随着时间的推移，TSC 偏移量使客人无法分辨时间去哪儿了（并且无法知道时间是否没有被其他东西消耗，例如系统管理模式或稍慢的 RAM 或..）。
主要是；你最终会遇到一种竞赛——当你找到检测 VM 的新方法时，VM 开发人员会找到改进虚拟化和防止检测的新方法。
【讨论】：
-
但是虚拟机不会伪造挂钟时间，所以我可以将 TSC 读取时间与挂钟时间进行比较？假设比较 TSC 值的空闲周期增量与使用挂钟时间进行密集 TSC 读取时所采取的增量之间的差异。
-
@ababo：有些虚拟机也会伪造挂钟时间（有些可以设置为“确定的时间，挂钟时间完全是假的，真实的挂钟时间无关紧要”）。如果挂钟时间不是假的，但 TSC 是假的；那么 TSC 可以告诉您它喜欢的任何“空闲时间”和任何它喜欢的“花费大量时间阅读 TSC 的时间”，并确保这两种情况都符合合理的现实。
您需要同时比较多个时间源。如果可以的话，你应该比较多个核心。
基于 TSC 的检测最简单的解决方法是使用 Brendan 提到的橡皮筋。但是当涉及多个核心时，就更难欺骗 TSC。 TSC 偏移/乘数是每个内核的。如果 VMM 试图隐藏自己，每个 VMEXIT 都会导致 TSC 倾斜。
现在，VMM 可以在任何单个内核退出时尝试踢出其他 vCPU，以便它们可以同步 TSC，但这非常昂贵（并且可能还有其他可检测到的问题，因为很难同步重新进入的 vCPU）。
总而言之，您至少需要两个内核：
- 一个内核应该设置一个原子变量，调用 RDTSC，然后调用一堆带有强制 VMEXIT 的指令（例如 CPUID），调用 RDTSC，然后取消设置原子变量。
- 另一个核心应监控该原子变量，然后调用 rdtsc，然后再次对其进行监控，最后在未设置时调用 rdtsc。
这需要一些校准。对于这样的事情，时间安排可能非常挑剔。 此外，您可以使用递增变量的循环来充当 rdtsc 的代理，但对此的校准可能更加挑剔（但值得，因为 TSC 可以普遍存在，包括在上面提到的第二个核心中）。
【讨论】：