(Chrome/Blink) Intent to Ship: SharedArrayBuffer

Contact emails

binji@chromium.org, aseemgarg@chromium.org, bradnelson@chromium.org, seththompson@chromium.org

Spec

Merged into ECMAscript spec:

https://tc39.github.io/ecma262/

(Sections referencing Atomics / SharedArrayBuffer)

Last separate draft:

https://tc39.github.io/ecmascript_sharedmem/shmem.html

TAG review submitted here: https://github.com/w3ctag/spec-reviews/issues/165

Summary

Gives JavaScript access to shared memory, atomics, and futex.

Adds a new JavaScript type SharedArrayBuffer mirroring ArrayBuffer, which can be posted to Web Workers without disconnecting the buffer from the sending side.
Re-uses Int8Array etc, to provide views into memory.
Adds a new top level Atomics object, containing atomic and futex operations.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/d-0ibJwCS24

Link to Origin Trial feedback summary

N/A

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo links

https://flagxor.github.io/sab-demo/convolve-multicore/convolve.html

https://browsix.org/latex-demo-sync/

(You must enable under about:flags)

Debuggability

Leverages existing debugging support for Web Workers.

Interoperability and Compatibility Risk

There is a low interoperability risk as implementations exist from all major browsers, and a test suite has been added to the standard ECMAscript test suite test262. The specification has been designed with affordances for efficient implementation on multiple architectures present and future.

Edge: Implemented, plan to ship in a future version

Firefox: Implement, launched in Nightly, expected to ship soon

Safari: Shipped (Safari 10.1)

Web developers: Positive (regularly asked when it will be available)

Security Note

Shipping a web browser involves both exposing new capabilities for developers to build useful applications and protecting users against ways in which those capabilities could be used maliciously. SharedArrayBuffers provide a useful primitive for efficient communication between web workers, and in turn dramatic performance benefits for web applications that rely on synchronizing multi-threaded behavior. Adding communication primitives between threads or workers has the inherent side-effect of exposing a mechanism to manually construct high-resolution timers. Such timers (also exposed via Flash, PNaCl, and some performance.now implementations) are a prerequisite for a class of side-channel attacks that observe cache accesses by measuring the time it takes to perform various computations. Historically, Chrome has significantly reduced the resolution of performance.now and added timing jitter where doing so doesn’t impede otherwise useful web capabilities. However, in practice, the existence of high-resolution timers has not been sufficient to demonstrate general exploits on non-quiescent machines. Moreover, from past experience, real-world attackers tend to attempt to exploit more straightforward, reliable, and powerful attacks than those that high-resolution timers abet. Ultimately, avoiding exposing high-resolution timers indefinitely is unlikely to be a practical long-term solution to preventing observation of information leaks–the real solution to this class of attack vectors is mitigations at the hardware and OS levels and/or mitigations in high-layer designs that avoid information leaks in the first place. The Chrome team believes that SharedArrayBuffers pose many more benefits than risks, and that SABs are not uniquely risky from a security perspective.

Of all the tests for web-exposed behavior, are any not in web-platform-tests? Please explain and link to bugs.

Tests of the feature are included as part of test262, ECMAscript's primary compliance suite:

https://github.com/tc39/test262/tree/master/test/built-ins/SharedArrayBuffer

https://github.com/tc39/test262/tree/master/test/built-ins/Atomics

Chrome's implementation passes 100% of these.

OWP launch tracking bug

https://crbug.com/709179

Entry on the feature dashboard

https://www.chromestatus.com/features/4570991992766464

Implementation Status Note

Note two remaining CLs need to make the branch for M59. These are expected to land shortly.

Limit the feature to WebGL: