[DougN7]

Great explanation - thank you. One thing I don’t understand is how this can be exploited from javascript. Does it have timing primitives so fine it can tell the difference between a memory lookup served from memory va from cache?

[craigyk]

Yes it does because javascript execution has had to become very fast. Fast means you can run a very tight loop that updates a counter to create a fairly high-resolution clock.

[wvenable]

What I don't understand is how the branch predictor is even exploitable from JavaScript -- it doesn't have pointers. How can it "request" arbitrary memory locations and time the results?

[hyperion2010]

It has byte arrays and indexing on those which is equivalent to having pointers. See page 6 and 7 of the Spectre paper.

[usrusr]

So the mid-term fix for js jits should be to gimp indexed array access to the point where an out of bounds index value can never enter speculative execution, right? I'm no expert in these low-level things, but I imagine that speculative execution happens only from conditional jumps and that alternative bounds assurances (e.g. using base+idx%len as the eventually address or limiting it to a sandbox-owned region using a few bitmasks) should be possible that reliably stall the pipeline without allowing speculative access (obviously at considerable performance cost, but the jit should be able to whitelist certain safe access patterns and/or trusted code sources to not let this get out of hand). Am I missing something?

[alex_stoddard]

I believe they made their own "good enough" clock out of a loop in a webworker.