On Thu, May 11, 2017 at 2:48 PM, Lars Hansen <lhan...@mozilla.com> wrote:
> 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. > Well, only until some top-500 website starts using it for a critical piece of functionality, right? I'd love to unship plenty of warts in the DOM for security reasons, but we can't break the web. > --lars > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
