On Thu, May 11, 2017 at 3:00 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:
> 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. > That's right. The window of opportunity for unshipping this somewhat painlessly is probably relatively small, on the order of a few months, perhaps. --lars > > >> --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
