The bug itself being discussed here
https://bugs.chromium.org/p/project-zero/issues/detail?id=1528
>I noticed that Intel's Optimization Manual says in section 2.4.4.5 ("Memory Disambiguation"):
> - A load instruction micro-op may depend on a preceding store. Many microarchitectures block loads until all preceding store address
are known.
> - The memory disambiguator predicts which loads will not depend on any previous stores. When the disambiguator predicts that a load does not have such a dependency, the load takes its data from the L1 data cache.
> - Eventually, the prediction is verified. If an actual conflict is detected, the load and all succeeding instructions are re-executed.
>According to my experiments, this effect can be used to cause speculative execution to continue far enough to execute a Spectre-style gadget on a pointer read from a memory slot to which a store has been speculatively ignored. I have tested this behavior on the following processors from Intel and AMD:
> - Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz [Skylake laptop]
> - AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G [AMD desktop]
> - Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz [Haswell desktop]
> I haven't yet tested this on any ARM CPU.
>Interestingly, only on the Skylake laptop, it seems to work when interrupts and SMP are disabled while the test is running; on the other machines, it seems to only work when interrupts are enabled, maybe because the kernel code cause some noise that garbles some predictor state or so? Or just because they mess up timing somewhere...