Haven't all the browser engines already implemented their own mitigations for Spectre/Meltdown for JavaScript code?

I can't speak to their existing mitigations directly, but more generally Spectre will be an ongoing saga for years to come.

I seriously doubt the mitigations in place, whatever they are, are comprehensive even for existing proven Spectre channels. The engines haven't even solved RowHammer. It's a very difficult problem domain, particularly for an application JIT'ing random, untrusted code from the Internet. In many respects they're (IMHO) quietly punting because there just aren't satisfactory solutions. Browsers are really stuck between a rock and a hard place, more so than VM providers like AWS EC2.

One of the more general solutions is simply to stop trusting the browser, if not your entire operating system. Keep your most sensitive secrets inaccessible to software to the greatest degree possible. Use smartcards and other hardware tokens for authentication, for example.

RowHammer is particularly frustrating because it's a combination of hardware/firmware/OS/software vulnerabilities; you need multiple levels of protection and it's hard to count on having them all.

I remember having a discussion about rowhammer on the v8 team when the original paper first came out - most of us thought it wouldn't be possible to exploit in JS but I suspected it would. Unfortunately I was right :/

I suspect at some point we'll discover WebGL can be used for rowhammering somehow too.

My point is you can't say "oh this approach may have poor behavior once Spectre mitigations are put in place", because the browser has already implemented Spectre mitigations.

There's more than one mitigation, and not all at the browser level. The kernel may also flush the branch cache on syscall entry, which is going to hurt performance if you depend on predictions being fast. Though as far as I know pretty much nobody uses that mitigation precisely because it's too slow.

Direct threading and indirect threading both rely heavily on the indirect predictor. You might even say that direct threading relies more heavily on indirect predictor state and in particular the contents of the IBTB because it has so many more branches and so more opportunity to store per-location history for particular instructions and hence more to lose if the IBTB is flushed.

Indirect threading relies more on strong and deep history pattern matching at a single location, and probably uses less state overall.

They’ve tried a bunch of things and basically landed on “we’ll do process isolation for Spectre but for Meltdown/Fallout/ZombieLoad/Other MDS vulnerabilities we’re basically fucked, so it’s on lower levels”