On Thu, May 11, 2017 at 10:55 AM, Martin Thomson <m...@mozilla.com> wrote:
> On Thu, May 11, 2017 at 5:57 PM, Lars Hansen <lhan...@mozilla.com> wrote: > > We do think there are > > architectural improvements that hardware manufacturers, operating > systems, > > and browsers can make [19], and we intend to investigate them. > > I think that the work you cite is promising. However, listening to > this presentation, there's a little soundbite that seems relevant to > this point. Forgive any transcription errors, but I think that David > (the author of the paper) says: > > "For example, Javascript is currently considering adding shared > memory. That would destroy this entire model." -- start at 27:00 for > the question and this answer. > They make much the same point in their paper, section 4.5. Do you have a strategy for dealing with this problem? The UCSD paper > doesn't provide any suggestions from what I can see. > We do not have an overarching strategy for this - indeed, being able to construct a precise "non-exiting" clock seems to be an inevitable consequence of the low level APIs that are exposed through shared memory with racy access and true parallelism. On the technical side, on some platforms, in heightened-security contexts, short of disabling the feature one could probably pin the threads that share memory to the same core, thus removing parallelism (and the resulting clock) while allowing the feature to function. But this is not portable and I don't know for a fact that it is completely practical. A major issue here is that once we ship a feature like this, it's very > difficult to un-ship if we find that we need to change things to deal > with issues. Given that we know those issues, having a framework for > dealing with those issues ahead of time would allow us to gain some > confidence that we aren't setting ourselves up for some serious pain. > Our only mitigation measure at the moment is that if the feature should be used as an attack vector in the wild we can disable it again (eg, ship a dot-release or other hotfix). As my original message notes, it will also remain possible to disable this feature for all tabs in about:config. --lars _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
