I'm not super familar with spectre, but i think the linked page is misinterpreting the vuln (hopefully someone will correct me if im totally out to lunch).
So the original js from the spectre paper was:
if (index < simpleByteArray.length) {
index = simpleByteArray[index | 0];
index = (((index * 4096)|0) & (32*1024*1024-1))|0;
localJunk ˆ= probeTable[index|0]|0;
}
The code looking a bit weird (all the |0) to ensure Chrome JITs it the correct way. My understanding of what happens, the loop goes a bunch of times while index is inside the simple byte array. After the last iteration, the processor speculatively executes the loop one more time than it should (branch misprediction). It eventually figures out the loop should end and undos the speculative execution. However that only happens after the loop has already started executing (where its not supposed to). During this improper execution, index is after the end of SimpleByteArray. index = simpleByteArray[index | 0] is then executed. index is now set to the value of some memory in the current process that the current JS is not supposed to access.
index = (((index * 4096)|0) & (3210241024-1))|0; is executed to spread the memory value out (we need all possible values to be in a separate cache line in probeTable later). We now execute localJunk ˆ= probeTable[index|0]|0;. localJunk is just there to prevent dead code elimination optimization. Since we are now indexing into probeTable at 4096 byte intervals, we have to fetch that value from memory. It then gets cached by processor. This all gets undone by the processor when it realizes that the branch was incorrect, except the cache changes are not undone. If we access anything else in the same 4096 bytes later on, the access is a tiny bit quicker.
The exploit is, that after all that setup, we try accessing each 4096 byte region of probeTable, to see which one is fastest. We can than conclude that was the value of index during the branch misprediction and thus the value of that byte of memory we aren't supposed to see.
If we do this a lot, we can read the rest of the process's memory. The hope is we will be able to find cookies related to other websites currently open, and then do evil things with them.
This attack no longer works because browsers disabled SharedArrayBuffer, which provided the really precise timer. The timing difference is very small so you need a very fine grained timer to make it work. It should also be noted that this variant of spectre is in-process only. Some versions of meltdown/spectre allow accessing memory of other processes, but as far as i understand this version is in process only.
I hope that made sense, and i hope i didnt screw that up.
So the original js from the spectre paper was:
The code looking a bit weird (all the |0) to ensure Chrome JITs it the correct way. My understanding of what happens, the loop goes a bunch of times while index is inside the simple byte array. After the last iteration, the processor speculatively executes the loop one more time than it should (branch misprediction). It eventually figures out the loop should end and undos the speculative execution. However that only happens after the loop has already started executing (where its not supposed to). During this improper execution, index is after the end of SimpleByteArray. index = simpleByteArray[index | 0] is then executed. index is now set to the value of some memory in the current process that the current JS is not supposed to access. index = (((index * 4096)|0) & (3210241024-1))|0; is executed to spread the memory value out (we need all possible values to be in a separate cache line in probeTable later). We now execute localJunk ˆ= probeTable[index|0]|0;. localJunk is just there to prevent dead code elimination optimization. Since we are now indexing into probeTable at 4096 byte intervals, we have to fetch that value from memory. It then gets cached by processor. This all gets undone by the processor when it realizes that the branch was incorrect, except the cache changes are not undone. If we access anything else in the same 4096 bytes later on, the access is a tiny bit quicker.The exploit is, that after all that setup, we try accessing each 4096 byte region of probeTable, to see which one is fastest. We can than conclude that was the value of index during the branch misprediction and thus the value of that byte of memory we aren't supposed to see.
If we do this a lot, we can read the rest of the process's memory. The hope is we will be able to find cookies related to other websites currently open, and then do evil things with them.
This attack no longer works because browsers disabled SharedArrayBuffer, which provided the really precise timer. The timing difference is very small so you need a very fine grained timer to make it work. It should also be noted that this variant of spectre is in-process only. Some versions of meltdown/spectre allow accessing memory of other processes, but as far as i understand this version is in process only.
I hope that made sense, and i hope i didnt screw that up.