Nice. Reviewing the code, it is as the PDF said where they are just constantly incrementing a val in the shared buffer to get a fairly precise timer. But it seems to be using the timing to determine across 256 indices (99 tries to check) to check cache hits. So just removing this timer is not enough, it just increases the surface area of bytes you have to read and sift through to see if you have other mem? Anyone have a writeup on this?
Isn't the high-precision timer required to detect a cache hit or miss-- as in, the side channel being exploited here is in the timing of a cache hit or miss; there's no data leaked directly into Javascript?
That's not to say that removing SharedArrayBuffer (and high-precision performance timers, which were removed a couple years back to mitigate some other timing-related vulnerabilities) is enough to completely eliminate Spectre; there might be other methods that can time accurately enough to reveal information.
(I might be completely wrong here, but this is my current understanding of the situation, at least.)
Nice tool. Sadly, it reports that my browser (Chromium 63.0.3239.132 with strict site isolation (chrome://flags/#enable-site-per-process) enabled) is vulnerable to Spectre. Do you know if there are any other steps that I can take to secure myself aside from using Firefox?
I'm running the same version of Chrome(with site isolation enabled), its reporting "Your browser is NOT VULNERABLE to Spectre" for me. Also in incognito mode with extensions disabled.