Speculative Store Bypass (Spectre V4)

Question

Does anyone know if there is a place that I can learn more about the Spectre V4 (Speculative Store Bypass) vulnerability? I already know the V1-V3 and also the Foreshadow. I found Intel's description is a bit confusing, especially their sample code (I copied it here)

X = &K;      // Attacker manages to get variable with address of K stored into pointer X
<at some later point>
X = &M;      // Does a store of address of M to pointer X
Y = Array[*X & 0xFFFF]; // Dereferences address of M which is in pointer X in order to
      // load from array at index specified by M[15:0]

How could the processor execute the last load speculatively since there is true dependency between the last two instructions. (I think Out-of-Order execution should still respect true dependency, right?)

Answer 1

The answer to this question is in the linked intel post, in particular this paragraph:

Speculative store bypass takes advantage of the memory disambiguation predictors feature in many high-performance processors that allows loads to speculatively execute even if the address of the preceding, potentially overlapping store is unknown. If the processor predicts the load address will not overlap with the unknown address, the load may execute speculatively. If there was indeed an overlap, then the load may speculatively read stale data.

In the example code the processor predicts that the load *X (from variable X) does not overlap with the store to variable X in line 2. The example given by intel is a little bit confusing because in most cases, both instances of X there would be accessed by the same name. A better example would be something like this (assume this is some pseudo-c that is compiled with a non-optimizing compiler)

X = &K;
Z1 = &X;
Z2 = &X;
*Z1 = Z1;
Y = Array[*Z2 & 0xFFFF]; 

Here we have two pointers (Z1 and Z2) that refer to the same location. But the CPU might predict that they don't overlap and thus "*Z2" could read the wrong value speculatively.

The explanation at https://blogs.technet.microsoft.com/srd/2018/05/21/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/ has some assembler code that perhaps illustrates this a little better.