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.
