Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Lars Hansen]

I hope I didn't suggest that people should stop discussing it; all I wanted
to do was to lay out the background for the debate and the evidence that
has been presented so far, in particular given Richard's strong assertions
about what this attack is able to do in JS, in a browser - which in truth
is "not much yet".

I don't think I'll be able to convince the people who are concerned about
this.  The facts are pretty clear - shared memory can be used to build a
high-precision clock, and some attacks, whether existing or hypothesized,
will only work with such a clock.  I think it's important that this is not
a weakness that is unique to this particular spec since such clocks can be
built in other ways, using both aging and emerging technologies (Flash,
WebAssembly).

To the extent I want to convince anyone at all, it is to convince the
people who will ultimately make the decision to enable the feature,
balancing a possible information leak problem against the evolution of the
web platform.

--lars

On Fri, Mar 4, 2016 at 1:08 PM, Eric Rescorla  wrote:

>
>
> On Thu, Mar 3, 2016 at 11:39 PM, Lars Hansen  wrote:
>
>> On Fri, Mar 4, 2016 at 1:41 AM, Richard Barnes 
>> wrote:
>>
>> > Another good reason for blocking this for now is that it lets Javascript
>> > circumvent the 5usec granularity of performance.now() and do things like
>> > stealing private keys.
>> >
>> > https://www.w3.org/TR/hr-time/#privacy-security
>> > http://iss.oy.ne.ro/SpyInTheSandbox.pdf
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1252035#c9
>> >
>> > We must not turn this on by default in any branch other than Nightly
>> until
>> > we can assure that the 5usec boundary will be maintained.
>> >
>>
>> ​I think your conclusion is bold, given the available facts:
>>
>> The papers that have been published so far have not shown any evidence of
>> doing "things like stealing private keys" in JS.  The papers that have
>> made
>> use of JS have so far demonstrated the ability to discern user activity
>> (the spy in the sandbox paper) and the ability to flip a bit in memory
>> without making use of that capability for anything specific (the
>> rowhammer.js paper).  Of course we must expect these attacks to improve,
>> but so far they are not doing anything akin to stealing private keys from
>> JS.
>>
>> The 5us timer may itself not hinder these attacks and should not be
>> treated
>> as some kind of "safe" limit.  The spy in the sandbox paper states that a
>> 1us resolution is enough for that attack; I have made an argument, with
>> code (https://github.com/tc39/ecmascript_sharedmem/issues/1), that a 1us
>> timer can be constructed from a 5us timer without the use of shared
>> memory,
>> the Tor project has reached a similar conclusion (
>> https://trac.torproject.org/projects/tor/ticket/16110).  The rowhammer.js
>> authors have stated (in a talk) that the 5us timer is not a hindrance for
>> their attack.
>>
>> As I have written about elsewhere (
>>
>> https://github.com/tc39/ecmascript_sharedmem/blob/master/issues/TimingAttack.md
>> )
>> there is every reason to believe that high-resolution timers can already
>> be
>> constructed by various kinds of content in web browsers.
>>
>
> I'll have more to say about this soon, but I don't think this argument is
> dispositive,
> given that essentially all of the technologies that provide these
> capabilities
> (Flash, Java, ActiveX, ...) are ones we are trying to eliminate.
>
>
> It is reasonable to be concerned for this capability but it has been
>> debated at some length; Chrome's security team is on the record (at the
>> last Ecma TC39 meeting) as being able to live with it (I'm paraphrasing,
>> as
>> I don't have the text of their statement);
>>
>
> I realize it's been debated at length, but it's not my sense that you've
> actually
> convinced the people who are concerned about this. Also, surely you're not
> suggesting that the Chrome security team's analysis is dispositive and that
> the Firefox security team (in this case, Richard) shouldn't make their own
> analysis.
>
> -Ekr
>
>
>
> (We've found no good mitigations for the issue, and there's no reason to
>> believe that any will be found.  Thread pinning might work in some
>> high-security environment, on platforms where that has teeth.  User opt-in
>> seems tricky and opt-in doesn't work well anyhow - most users enable all
>> plugins everywhere, for example.)
>>
>> Your request to "not turn this on ... until we can assure that the 5usec
>> boundary will be maintained" is a request not to turn this on, period.
>>
>> --lars
>>
>>
>> >
>> > --Richard
>> >
>> >
>> > On Fri, Jan 15, 2016 at 12:10 AM, Lars Hansen 
>> wrote:
>> >
>> >> It's not enabled by default because the API is probably not fully baked
>> >> yet; until the spec reaches Stage 3 at TC39 we should expect things to
>> be
>> >> fluid.  I don't expect that milestone to be reached until this summer.
>> >>

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Eric Rescorla]

On Thu, Mar 3, 2016 at 11:39 PM, Lars Hansen  wrote:

> On Fri, Mar 4, 2016 at 1:41 AM, Richard Barnes 
> wrote:
>
> > Another good reason for blocking this for now is that it lets Javascript
> > circumvent the 5usec granularity of performance.now() and do things like
> > stealing private keys.
> >
> > https://www.w3.org/TR/hr-time/#privacy-security
> > http://iss.oy.ne.ro/SpyInTheSandbox.pdf
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1252035#c9
> >
> > We must not turn this on by default in any branch other than Nightly
> until
> > we can assure that the 5usec boundary will be maintained.
> >
>
> ​I think your conclusion is bold, given the available facts:
>
> The papers that have been published so far have not shown any evidence of
> doing "things like stealing private keys" in JS.  The papers that have made
> use of JS have so far demonstrated the ability to discern user activity
> (the spy in the sandbox paper) and the ability to flip a bit in memory
> without making use of that capability for anything specific (the
> rowhammer.js paper).  Of course we must expect these attacks to improve,
> but so far they are not doing anything akin to stealing private keys from
> JS.
>
> The 5us timer may itself not hinder these attacks and should not be treated
> as some kind of "safe" limit.  The spy in the sandbox paper states that a
> 1us resolution is enough for that attack; I have made an argument, with
> code (https://github.com/tc39/ecmascript_sharedmem/issues/1), that a 1us
> timer can be constructed from a 5us timer without the use of shared memory,
> the Tor project has reached a similar conclusion (
> https://trac.torproject.org/projects/tor/ticket/16110).  The rowhammer.js
> authors have stated (in a talk) that the 5us timer is not a hindrance for
> their attack.
>
> As I have written about elsewhere (
>
> https://github.com/tc39/ecmascript_sharedmem/blob/master/issues/TimingAttack.md
> )
> there is every reason to believe that high-resolution timers can already be
> constructed by various kinds of content in web browsers.
>

I'll have more to say about this soon, but I don't think this argument is
dispositive,
given that essentially all of the technologies that provide these
capabilities
(Flash, Java, ActiveX, ...) are ones we are trying to eliminate.


It is reasonable to be concerned for this capability but it has been
> debated at some length; Chrome's security team is on the record (at the
> last Ecma TC39 meeting) as being able to live with it (I'm paraphrasing, as
> I don't have the text of their statement);
>

I realize it's been debated at length, but it's not my sense that you've
actually
convinced the people who are concerned about this. Also, surely you're not
suggesting that the Chrome security team's analysis is dispositive and that
the Firefox security team (in this case, Richard) shouldn't make their own
analysis.

-Ekr



(We've found no good mitigations for the issue, and there's no reason to
> believe that any will be found.  Thread pinning might work in some
> high-security environment, on platforms where that has teeth.  User opt-in
> seems tricky and opt-in doesn't work well anyhow - most users enable all
> plugins everywhere, for example.)
>
> Your request to "not turn this on ... until we can assure that the 5usec
> boundary will be maintained" is a request not to turn this on, period.
>
> --lars
>
>
> >
> > --Richard
> >
> >
> > On Fri, Jan 15, 2016 at 12:10 AM, Lars Hansen 
> wrote:
> >
> >> It's not enabled by default because the API is probably not fully baked
> >> yet; until the spec reaches Stage 3 at TC39 we should expect things to
> be
> >> fluid.  I don't expect that milestone to be reached until this summer.
> >>
> >> We've discussed enabling by default on Aurora, DevEd, and Beta once we
> >> reach Stage 2 at TC39, but I don't own that decision, can't guarantee
> it,
> >> and might even argue that it would be better to wait a couple of months
> >> after reaching Stage 2, which is when the spec gets serious attention
> from
> >> the committee.
> >>
> >> Google has what I understand to be a compatible implementation of the
> >> current spec, also available behind a pref (actually behind two of them
> >> last I heard).
> >>
> >> --lars
> >>
> >>
> >> On Thu, Jan 14, 2016 at 10:24 PM, Robert O'Callahan <
> rob...@ocallahan.org
> >> >
> >> wrote:
> >>
> >> > Sounds good to me too. What's blocking us from enabling by default?
> >> >
> >> > Rob
> >> > --
> >> > lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe
> >> uresyf
> >> > toD
> >> > selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> >> > rdsme,aoreseoouoto
> >> > o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> >> > lurpr
> >> > .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt
> >> sstvr
> >> > esn
> >> >
> >> ___
> >> dev-platform 

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Lars Hansen]

On Fri, Mar 4, 2016 at 1:41 AM, Richard Barnes  wrote:

> Another good reason for blocking this for now is that it lets Javascript
> circumvent the 5usec granularity of performance.now() and do things like
> stealing private keys.
>
> https://www.w3.org/TR/hr-time/#privacy-security
> http://iss.oy.ne.ro/SpyInTheSandbox.pdf
> https://bugzilla.mozilla.org/show_bug.cgi?id=1252035#c9
>
> We must not turn this on by default in any branch other than Nightly until
> we can assure that the 5usec boundary will be maintained.
>

​I think your conclusion is bold, given the available facts:

The papers that have been published so far have not shown any evidence of
doing "things like stealing private keys" in JS.  The papers that have made
use of JS have so far demonstrated the ability to discern user activity
(the spy in the sandbox paper) and the ability to flip a bit in memory
without making use of that capability for anything specific (the
rowhammer.js paper).  Of course we must expect these attacks to improve,
but so far they are not doing anything akin to stealing private keys from
JS.

The 5us timer may itself not hinder these attacks and should not be treated
as some kind of "safe" limit.  The spy in the sandbox paper states that a
1us resolution is enough for that attack; I have made an argument, with
code (https://github.com/tc39/ecmascript_sharedmem/issues/1), that a 1us
timer can be constructed from a 5us timer without the use of shared memory,
the Tor project has reached a similar conclusion (
https://trac.torproject.org/projects/tor/ticket/16110).  The rowhammer.js
authors have stated (in a talk) that the 5us timer is not a hindrance for
their attack.

As I have written about elsewhere (
https://github.com/tc39/ecmascript_sharedmem/blob/master/issues/TimingAttack.md)
there is every reason to believe that high-resolution timers can already be
constructed by various kinds of content in web browsers.

WebAssembly, to be more than a diverting experiment, will also need to
adopt shared memory and will run into the same problem in the future (as
has PNaCl in the past).

It is reasonable to be concerned for this capability but it has been
debated at some length; Chrome's security team is on the record (at the
last Ecma TC39 meeting) as being able to live with it (I'm paraphrasing, as
I don't have the text of their statement); and it is hard to see how the
web will evolve as a software platform without a shared memory and
multicore capability as part of its standard toolbox.

(We've found no good mitigations for the issue, and there's no reason to
believe that any will be found.  Thread pinning might work in some
high-security environment, on platforms where that has teeth.  User opt-in
seems tricky and opt-in doesn't work well anyhow - most users enable all
plugins everywhere, for example.)

Your request to "not turn this on ... until we can assure that the 5usec
boundary will be maintained" is a request not to turn this on, period.

--lars


>
> --Richard
>
>
> On Fri, Jan 15, 2016 at 12:10 AM, Lars Hansen  wrote:
>
>> It's not enabled by default because the API is probably not fully baked
>> yet; until the spec reaches Stage 3 at TC39 we should expect things to be
>> fluid.  I don't expect that milestone to be reached until this summer.
>>
>> We've discussed enabling by default on Aurora, DevEd, and Beta once we
>> reach Stage 2 at TC39, but I don't own that decision, can't guarantee it,
>> and might even argue that it would be better to wait a couple of months
>> after reaching Stage 2, which is when the spec gets serious attention from
>> the committee.
>>
>> Google has what I understand to be a compatible implementation of the
>> current spec, also available behind a pref (actually behind two of them
>> last I heard).
>>
>> --lars
>>
>>
>> On Thu, Jan 14, 2016 at 10:24 PM, Robert O'Callahan > >
>> wrote:
>>
>> > Sounds good to me too. What's blocking us from enabling by default?
>> >
>> > Rob
>> > --
>> > lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe
>> uresyf
>> > toD
>> > selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
>> > rdsme,aoreseoouoto
>> > o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
>> > lurpr
>> > .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt
>> sstvr
>> > esn
>> >
>> ___
>> 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

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Richard Barnes]

Another good reason for blocking this for now is that it lets Javascript
circumvent the 5usec granularity of performance.now() and do things like
stealing private keys.

https://www.w3.org/TR/hr-time/#privacy-security
http://iss.oy.ne.ro/SpyInTheSandbox.pdf
https://bugzilla.mozilla.org/show_bug.cgi?id=1252035#c9

We must not turn this on by default in any branch other than Nightly until
we can assure that the 5usec boundary will be maintained.

--Richard


On Fri, Jan 15, 2016 at 12:10 AM, Lars Hansen  wrote:

> It's not enabled by default because the API is probably not fully baked
> yet; until the spec reaches Stage 3 at TC39 we should expect things to be
> fluid.  I don't expect that milestone to be reached until this summer.
>
> We've discussed enabling by default on Aurora, DevEd, and Beta once we
> reach Stage 2 at TC39, but I don't own that decision, can't guarantee it,
> and might even argue that it would be better to wait a couple of months
> after reaching Stage 2, which is when the spec gets serious attention from
> the committee.
>
> Google has what I understand to be a compatible implementation of the
> current spec, also available behind a pref (actually behind two of them
> last I heard).
>
> --lars
>
>
> On Thu, Jan 14, 2016 at 10:24 PM, Robert O'Callahan 
> wrote:
>
> > Sounds good to me too. What's blocking us from enabling by default?
> >
> > Rob
> > --
> > lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe
> uresyf
> > toD
> > selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> > rdsme,aoreseoouoto
> > o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> > lurpr
> > .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> > esn
> >
> ___
> 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

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Lars Hansen]

It's not enabled by default because the API is probably not fully baked
yet; until the spec reaches Stage 3 at TC39 we should expect things to be
fluid.  I don't expect that milestone to be reached until this summer.

We've discussed enabling by default on Aurora, DevEd, and Beta once we
reach Stage 2 at TC39, but I don't own that decision, can't guarantee it,
and might even argue that it would be better to wait a couple of months
after reaching Stage 2, which is when the spec gets serious attention from
the committee.

Google has what I understand to be a compatible implementation of the
current spec, also available behind a pref (actually behind two of them
last I heard).

--lars


On Thu, Jan 14, 2016 at 10:24 PM, Robert O'Callahan 
wrote:

> Sounds good to me too. What's blocking us from enabling by default?
>
> Rob
> --
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

SharedArrayBuffer and Atomics will ride the trains behind a pref

[Lars Hansen]

Until now the new SharedArrayBuffer constructor and the new Atomics global
object [1] have been enabled on Nightly only.  Starting with Firefox 46,
those bindings will still be enabled by default on Nightly but they will
also be available on Aurora, DevEd, Beta, and Release by flipping the value
of javascript.options.shared_memory to true in about:config.

--lars

[1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Thomas Zimmermann]

Hi,

I saw the lightning talk you gave in Orlando in this topic. I was
wondering if you considered implementing Transactional Memory for
SharedArrayBuffer. JS seems like the perfect environment for TM. Are
there reasons for 'only' providing atomic ops? Just asking out of
curiosity...

Best regards
Thomas


Am 14.01.2016 um 14:16 schrieb Lars Hansen:
> Until now the new SharedArrayBuffer constructor and the new Atomics global
> object [1] have been enabled on Nightly only.  Starting with Firefox 46,
> those bindings will still be enabled by default on Nightly but they will
> also be available on Aurora, DevEd, Beta, and Release by flipping the value
> of javascript.options.shared_memory to true in about:config.
>
> --lars
>
> [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
> ___
> 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

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Thomas Zimmermann]

Thanks!

Am 14.01.2016 um 15:08 schrieb Lars Hansen:
> On Thu, Jan 14, 2016 at 2:49 PM, Thomas Zimmermann 
> wrote:
>
>> Hi,
>>
>> I saw the lightning talk you gave in Orlando in this topic. I was
>> wondering if you considered implementing Transactional Memory for
>> SharedArrayBuffer.
>
> ​I have not (or, not in earnest).
> ​
>
>
>> JS seems like the perfect environment for TM. Are
>> there reasons for 'only' providing atomic ops? Just asking out of
>> curiosity...
>>
> ​The use cases that drive this work are access to multicore performance
> from JS as well as asm.js as a compilation target for conventional
> multithreaded C++; actually the asm.js case is the more important one at
> this time.  Hence the focus for this first version of the spec has been on
> (very) low level mechanisms that can serve those use cases in
> straightforward ways.
>
> Personally I'd like to see us add additional higher-level mechanisms that
> are a better fit for straight JS programming.  I'm hoping that we can use
> the current low level mechanisms to prototype higher level ones, and
> eventually standardize some of them.  I don't know how well we can
> prototype TM like that - but it's early days still.
>
> --lars
>
>
>> Best regards
>> Thomas
>>
>>
>> Am 14.01.2016 um 14:16 schrieb Lars Hansen:
>>> Until now the new SharedArrayBuffer constructor and the new Atomics
>> global
>>> object [1] have been enabled on Nightly only.  Starting with Firefox 46,
>>> those bindings will still be enabled by default on Nightly but they will
>>> also be available on Aurora, DevEd, Beta, and Release by flipping the
>> value
>>> of javascript.options.shared_memory to true in about:config.
>>>
>>> --lars
>>>
>>> [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
>>> ___
>>> 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

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Lars Hansen]

On Thu, Jan 14, 2016 at 2:49 PM, Thomas Zimmermann 
wrote:

> Hi,
>
> I saw the lightning talk you gave in Orlando in this topic. I was
> wondering if you considered implementing Transactional Memory for
> SharedArrayBuffer.


​I have not (or, not in earnest).
​


> JS seems like the perfect environment for TM. Are
> there reasons for 'only' providing atomic ops? Just asking out of
> curiosity...
>

​The use cases that drive this work are access to multicore performance
from JS as well as asm.js as a compilation target for conventional
multithreaded C++; actually the asm.js case is the more important one at
this time.  Hence the focus for this first version of the spec has been on
(very) low level mechanisms that can serve those use cases in
straightforward ways.

Personally I'd like to see us add additional higher-level mechanisms that
are a better fit for straight JS programming.  I'm hoping that we can use
the current low level mechanisms to prototype higher level ones, and
eventually standardize some of them.  I don't know how well we can
prototype TM like that - but it's early days still.

--lars


> Best regards
> Thomas
>
>
> Am 14.01.2016 um 14:16 schrieb Lars Hansen:
> > Until now the new SharedArrayBuffer constructor and the new Atomics
> global
> > object [1] have been enabled on Nightly only.  Starting with Firefox 46,
> > those bindings will still be enabled by default on Nightly but they will
> > also be available on Aurora, DevEd, Beta, and Release by flipping the
> value
> > of javascript.options.shared_memory to true in about:config.
> >
> > --lars
> >
> > [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
> > ___
> > 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

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Lars Hansen]

Yes, disabled by default on all branches, enabled by default on Nightly.
(It's also supported on ARM, so it should be possible to test it on
Android, again by flipping the pref.)

--lars

On Thu, Jan 14, 2016 at 9:14 PM, Jonas Sicking  wrote:

> Hi Lars,
>
> So if I understand correctly, this will still remain disabled by
> default on all branches. However it will now be possible to test out
> on all branches by flipping a pref?
>
> If so that sounds great to me.
>
> / Jonas
>
> On Thu, Jan 14, 2016 at 5:16 AM, Lars Hansen  wrote:
> > Until now the new SharedArrayBuffer constructor and the new Atomics
> global
> > object [1] have been enabled on Nightly only.  Starting with Firefox 46,
> > those bindings will still be enabled by default on Nightly but they will
> > also be available on Aurora, DevEd, Beta, and Release by flipping the
> value
> > of javascript.options.shared_memory to true in about:config.
> >
> > --lars
> >
> > [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
> > ___
> > 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

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Robert O'Callahan]

Sounds good to me too. What's blocking us from enabling by default?

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Jonas Sicking]

Hi Lars,

So if I understand correctly, this will still remain disabled by
default on all branches. However it will now be possible to test out
on all branches by flipping a pref?

If so that sounds great to me.

/ Jonas

On Thu, Jan 14, 2016 at 5:16 AM, Lars Hansen  wrote:
> Until now the new SharedArrayBuffer constructor and the new Atomics global
> object [1] have been enabled on Nightly only.  Starting with Firefox 46,
> those bindings will still be enabled by default on Nightly but they will
> also be available on Aurora, DevEd, Beta, and Release by flipping the value
> of javascript.options.shared_memory to true in about:config.
>
> --lars
>
> [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
> ___
> 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

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Luke Wagner]

For additional rationale, you might be interested to read:
  
https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/

On Thu, Jan 14, 2016 at 8:11 AM, Thomas Zimmermann
 wrote:
> Thanks!
>
> Am 14.01.2016 um 15:08 schrieb Lars Hansen:
>> On Thu, Jan 14, 2016 at 2:49 PM, Thomas Zimmermann 
>> wrote:
>>
>>> Hi,
>>>
>>> I saw the lightning talk you gave in Orlando in this topic. I was
>>> wondering if you considered implementing Transactional Memory for
>>> SharedArrayBuffer.
>>
>> I have not (or, not in earnest).
>>
>>
>>
>>> JS seems like the perfect environment for TM. Are
>>> there reasons for 'only' providing atomic ops? Just asking out of
>>> curiosity...
>>>
>> The use cases that drive this work are access to multicore performance
>> from JS as well as asm.js as a compilation target for conventional
>> multithreaded C++; actually the asm.js case is the more important one at
>> this time.  Hence the focus for this first version of the spec has been on
>> (very) low level mechanisms that can serve those use cases in
>> straightforward ways.
>>
>> Personally I'd like to see us add additional higher-level mechanisms that
>> are a better fit for straight JS programming.  I'm hoping that we can use
>> the current low level mechanisms to prototype higher level ones, and
>> eventually standardize some of them.  I don't know how well we can
>> prototype TM like that - but it's early days still.
>>
>> --lars
>>
>>
>>> Best regards
>>> Thomas
>>>
>>>
>>> Am 14.01.2016 um 14:16 schrieb Lars Hansen:
 Until now the new SharedArrayBuffer constructor and the new Atomics
>>> global
 object [1] have been enabled on Nightly only.  Starting with Firefox 46,
 those bindings will still be enabled by default on Nightly but they will
 also be available on Aurora, DevEd, Beta, and Release by flipping the
>>> value
 of javascript.options.shared_memory to true in about:config.

 --lars

 [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
 ___
 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform