We intend to enable the ECMAScript 2017 APIs *SharedArrayBuffer* and *Atomics* by default in Firefox. The target release is* Firefox 55*, which is set to ship on* 8 August, 2017*. The feature has been developed behind the *javascript.options.shared_memory* flag.
The feature is also in Safari (version 10.1, shipped in March 2017 [1]) and Chrome (version 60, will ship in early August 2017 [2][3]); it has also been implemented in Edge [24], but no ship date has been announced. The feature has already been enabled by default in Firefox Nightly, Aurora, and Beta for many months. (For the last several release cycles, we have disabled the feature by default in Beta just prior to branching for Release, and we plan to do so for Firefox 54 as well.) Due to its long history and experimental nature there was never an Intent-to-implement for the feature, but there was a discussion when an announcement was made to make the feature available beyond Nightly [4]. Relevant intent-to-implement information is included at the end of this message. Relevant bug No bug - no additional work is required to enable the feature upon release; it is already enabled in Beta. Specifications The new SharedArrayBuffer and Atomics APIs are described in the ECMAScript spec [5]. Several changes were made to HTML to accommodate structured cloning of SharedArrayBuffer, blocking waits, and worker semantics. The ECMAScript spec formalisms "Agent" and "Agent cluster" have been instantiated within HTML; the matter of which agents can block in Atomics.wait has been pinned down; postMessage() can now transmit a SharedArrayBuffer from an agent to some (but not all) other agents; and workers can no longer be discretionarily killed by the UA or easily made to share execution threads. The specific changes can be viewed at [6][7][8][9], and links off those. For safety and correctness reasons having to do with concurrent updates to memory, a Web API must always be modified to make it accept SharedArrayBuffer memory in addition to non-shared ArrayBuffer memory. WebIDL has therefore been extended so as to allow the easy expression of Web APIs that can take both shared and non-shared memory [10]. Work is ongoing to standardize browser APIs that can accept shared memory, the central coordinating point for this is [11]. Notably we want some WebGL APIs to accept shared memory [12][13] but in the longer term we wish for most APIs that accept ArrayBuffer also to accept SharedArrayBuffer. Security implications SharedArrayBuffers and Atomics can be used to improve the responsiveness of high-performance web applications like games, image or video editing. However, the feature permits building a high-resolution timer, enabling a class of attacks that could be used to extract protected or private information. Researchers have written about exploits, eg [20][21][22][23], and have demonstrated proof of concept attacks under ideal conditions. Mozilla has not observed nor heard of these attacks performed in-the-wild. Addressing the potential of each feature which enables a high-resolution timer is difficult without adversely affecting browser performance and usability. But it shouldn’t be considered impossible. We do think there are architectural improvements that hardware manufacturers, operating systems, and browsers can make [19], and we intend to investigate them. We believe this approach is the correct one: rather than trying to mitigate each timer built out of unrelated features we should address the problem as a whole. We believe the value and capabilities provided by SharedArrayBuffers and Atomics outweigh the risks. Other browser makers have reached similar conclusions, and are also implementing and shipping the feature. We are continually monitoring and looking for evidence of real world cache attacks. Users will always have the option of disabling SharedArrayBuffers and Atomics using the about:config interface, and if we believe that users are not served by the feature as it exists today, we may re-evaluate how it is exposed to the web. Implementation status in Firefox On the positive side: - We support the entire feature as described in the ECMAScript 2017 specification. - We support sharing memory between a document and its dedicated workers (recursively) by means of direct postMessage() calls. - We support shared memory for the subset of WebGL 1.0 APIs that are required by the draft spec [14]. We do not yet support any WebGL 2.0 APIs. On the negative side: - We disallow blocking waits in SharedWorker instances even though HTML requires them to be allowed [15]. - We do not yet allow SharedArrayBuffer objects to be transmitted over MessageChannels and BroadcastChannels at all [16]. - We do not yet implement the new MessageError event that is to be fired in the recipient when an attempt is made to receive a SharedArrayBuffer that was sent by an agent that is not allowed to share memory with the recipient [17]. - There may be other corner cases, TBD [18]. The shortcomings are in the process of being addressed and are not seen as blocking the release. Additional information (relevant to the intent-to-implement that was never sent) Main implementation bug: https://bugzil.la/1054841 Enabled by default in sandboxed iframes: Yes DevTools: https://bugzil.la/1152856 (ongoing work, not blocking release) Tests: JS shell tests are in js/src/tests/shell and js/src/jit-test/test/{atomics,sharedbuf}. There are also many test cases in the ECMAScript spec's test262 repository, and web platform tests are included with the upcoming HTML changes. References [1] https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_1.html [2] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/dnzvgTswfbc [3] https://www.chromium.org/developers/calendar [4] https://groups.google.com/forum/#!topic/mozilla.dev.platform/HodzgJRbly8 [5] https://tc39.github.io/ecma262 [6] https://github.com/whatwg/html/issues/2260 [7] https://github.com/whatwg/html/pull/2520 [8] https://github.com/whatwg/html/pull/2521 [9] https://github.com/w3c/ServiceWorker/issues/1115 [10] https://github.com/heycam/webidl/pull/286 [11] https://github.com/heycam/webidl/pull/353 [12] https://github.com/tc39/ecmascript_sharedmem/issues/38 [13] https://github.com/tc39/ecmascript_sharedmem/issues/168 [14] https://tc39.github.io/ecmascript_sharedmem/dom_shmem.html#webgl. [15] https://bugzil.la/1359745 [16] https://bugzil.la/1360190 [17] https://bugzil.la/1359017 [18] https://bugzil.la/1360434 [19] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kohlbrenner [20] http://arxiv.org/abs/1502.07373 [21] https://eprint.iacr.org/2015/898.pdf [22] http://arxiv.org/abs/1511.04594 [23] http://arxiv.org/abs/1511.04897 [24] https://github.com/Microsoft/ChakraCore/wiki/Release-Notes#v140 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
