为什么CPUID + RDTSC不可靠？

Question

我试图分析x86-64处理器上执行时间的代码。我指的是这、英特尔的白皮书，以及其他讨论使用CPUID+RDTSC、这里和这里的主题的线程。

在上述白皮书中，使用CPUID+RDTSC的方法被称为不可靠的方法，并通过统计数据进行了验证。

CPUID+RDTSC不可靠的原因是什么？

同样，图1(最小值行为图)和图2(方差行为图)中的图也有一个“方波”模式。，是什么解释了这样的模式？

Answer 1

我认为他们发现测量间隔内的CPUID会导致总时间上的额外变化。他们建议在3.2中使用RDTSCP指令进行改进，这突出了这样一个事实:当他们使用CPUID / RDTSC启动时，在时间间隔中没有CPUID，使用RDTSCP/CPUID停止。

也许他们可以在执行CPUID之前确保EAX=0或EAX=1，选择要读取的数据页(0000h)，以防CPUID时间取决于您进行的查询。除此之外，我不知道为什么会这样。

或者更好的方法是使用lfence而不是cpuid来序列化OoO exec，而不是完全序列化操作。

注意，Intel白皮书中的inline很糟糕:如果您使用适当的输出约束(如mov )(如"=a"(low), "=d"(high) )，则不需要使用这些"=a"(low), "=d"(high)指令。更好的方法请参见64来自C++？。

Answer 2

CPUID+RDTSC不可靠的另一个原因是VM侧通道攻击.

当在VM中运行CPUID指令时，会导致VM退出，因此VM将根据他的需要处理CPUID，并操作CPUID指令。

执行此操作会增加额外的时间，并且使用RDTSC将返回"high“值，因为”整个value操作“是在这段时间执行的。

然后可以使用这个值来检测我们是否正在VM中运行。

VM可以防止这种行为，因为VM可以扩展或虚拟化TSC，从而使RDTSC不可靠。

检测VM退出开销