For the purposes of the proposed shared memory feature, this issue is tracked on that proposal's issue tracker: https://github.com/lars-t-hansen/ecmascript_sharedmem/issues/1. There's a demonstration attached to that bug of a timer with about a 4ns resolution on current hardware.
I don't mind discussing the matter on es-discuss but I hope nobody minds that I copy salient information to the issue tracker. (Presumably PNaCl exposes the same problem?) --lars On Tue, Sep 29, 2015 at 1:20 AM, Waldemar Horwat <walde...@google.com> wrote: > I was asked to share my concerns about how bad this can be. Here's a > paper demonstrating how one AWS virtual machine has been able to > practically break 2048-bit RSA by snooping into a different virtual machine > using the same kind of shared cache timing attack. These were both running > on unmodified public AWS, and much of the challenge was figuring out when > the attacker was co-located with the victim since AWS runs a lot of other > users' stuff. This attack would be far easier in shared-memory ECMAScript, > where you have a much better idea of what else is running on the browser > and the machine (at least in part because you can trigger it via other > APIs). > > https://eprint.iacr.org/2015/898.pdf > > Chrome currently mitigates this by limiting the resolution of timers to > 1µs. With any kind of shared memory multicore you can run busy-loops to > increase the attack timing surface by 3½ orders of magnitude to about > 0.3ns, making these attacks eminently practical. > > Waldemar > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
