assembly - 在 x86-64 CPU 上通过交叉修改代码重现意外行为

Question

问题

交叉修改代码有哪些想法可能会在 x86 或 x86-x64 系统上触发意外行为，在这些系统中，交叉修改代码中的所有操作都已正确完成，但先在执行处理器上执行序列化指令除外执行修改后的代码？

如下所述，我有一个 Core 2 Duo E6600 处理器进行测试，该处理器被明确提到是容易出现与此相关的问题的处理器。我将在这台机器上测试与我分享的任何想法并提供更新。

背景

在 x86 和 x64 系统上，编写交叉修改代码的官方指南是执行以下操作:

; Action of Modifying Processor
Store modified code (as data) into code segment;
Memory_Flag ← 1; 

; Action of Executing Processor
WHILE (Memory_Flag ≠ 1)
  Wait for code to update;
ELIHW;
Execute serializing instruction; (* For example, CPUID instruction *)
Begin executing modified code;

某些处理器的勘误表中明确提到了序列化指令的必要性。例如，Intel Core 2 Duo E6000 系列有以下勘误:(来自 http://www.mathemainzel.info/files/intelX6800andintelE6000.pdf )

The act of one processor, or system bus master, writing data into a currently executing code segment of a second processor with the intent of having the second processor execute that data as code is called cross-modifying code (XMC). XMC that does not force the second processor to execute a synchronizing instruction, prior to execution of the new code, is called unsynchronized XMC.

Software using unsynchronized XMC to modify the instruction byte stream of a processor can see unexpected or unpredictable execution behavior from the processor that is executing the modified code.

有人猜测，如果 http://linux.kernel.narkive.com/FDc9TB0d/patch-linux-kernel-markers 处未使用序列化指令，为什么会出现意外的执行行为？ :

When the i-fetch has been done and the micro-ops are in the trace cache then there's no longer a direct correlation between the original machine instruction boundaries and the micro ops. This is due to optimization. For example (artificial one for illustrative purposes):

mov eax,ebx

mov memory,eax

mov eax,1

(using intel notation not ATT - force of habit)

In the trace cache there would be no micro ops to update eax with ebx.

Altering the "mov eax,ebx" to "mov ecx,ebx" on the fly invalidates the optimized trace cache, hence the onlhy recourse is a GPF. If the modification doens't invalidate the trace cache then no GPF. The question is: "can we predict th circumstances when the trace cache has not been invalidated", and the answer in general is no since the microarchtecture is not public. But one can guess that modifying the single byte opcode with in interrupting instruction - int3 - doesn't cause an inconsistency that can't be handled. And that's what Intel confirmed. Go ahead and store int3 without the need to synchronise (i.e. force the trace cache to be flushed).

还有更多信息，请访问 https://sourceware.org/ml/systemtap/2005-q3/msg00208.html :

When we became aware of this I had a long discussion with Intel's microarchitecture guys. It turns out that the reason for this erratum (which incidentally Intel does not intend to fix) is because the trace cache - the stream of micorops resulting from instruction interpretation - cannot guaranteed to be valid. Reading between the lines I assume this issue arises because of optimization done in the trace cache, where it is no longer possible to identify the original instruction boundaries. If the CPU discoverers that the trace cache has been invalidated because of unsynchronized cross-modification then instruction execution will be aborted with a GPF. Further discussion with Intel revealed that replacing the first opcode byte with an int3 would not be subject to this erratum.

除了我在这里发布的内容之外，我在互联网上看到的关于此问题的信息并不多。此外，我还没有发现任何公开的例子表明人们在 x86 和 x86-64 系统上使用交叉修改代码时因未能执行序列化指令而被咬。

我有一台运行 Intel Core 2 Duo E6600 处理器的计算机，该处理器被明确记录为容易出现此问题，但我无法能够编写触发此问题的代码。

编写代码来执行此操作对我来说是一种个人好奇心。在生产代码中，我只是遵循规则，但我认为在重现这个过程中我可能需要学习一些东西。

Answer 1

想象一个具有很长 instruction pipeline 的处理器其中寄存器和内存仅在最后一个流水线阶段修改。当您为此处理器编写自修改代码并修改内存中已存在于管道中的指令时，修改将无效。在这种情况下，程序的行为取决于处理器的管道有多长。

为了使具有更长管道的新处理器的行为与旧型号完全相同，英特尔处理器包含一种机制，可以在检测到这种情况时刷新(清空)管道。刷新后，修改后的代码将被提取到管道中，因此新处理器的行为与旧处理器完全相同。

序列化指令是刷新管道的另一种方法。当到达管道末尾时，管道将被刷新并在序列化指令之后再次开始获取。

因此，勘误表本质上是说，某些处理器模型不会检查来自其他处理器的写入是否会覆盖已在其管道中执行的指令。该检查仅适用于本地写入，不适用于外部写入。但是，如果插入序列化指令，则会强制处理器刷新管道，一切都会按预期运行。

要重现勘误表中描述的行为，您需要确保从一个处理器修改的代码位于另一个处理器的管道内。看一下分支预测(决定哪个代码路径位于管道内)和同步原语。