Re:A New Bytecode Format for JavaScriptCore
by kevingadd on Friday June 21, 2019 @09:58PM
(#20247571)
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.
Re:A New Bytecode Format for JavaScriptCore
by tedunangst on Friday June 21, 2019 @07:07PM
(#20246984)
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.
Re:A New Bytecode Format for JavaScriptCore
by BeeOnRope on Saturday June 22, 2019 @01:20AM
(#20248166)
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.
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.