Summary: SharedArrayBuffer (SAB) is a feature that allows high-performance applications using shared-memory multi-threading to run on the web. Shortly after releasing SAB, Firefox (and other browsers) disabled SAB as part of our initial Spectre mitigations (see https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/), because it provides a very high-resolution clock which makes Spectre attacks more effective.
Work is ongoing to enable these high-performance applications again. The plan is: 1. Prevent postMessage() of SAB by default (throw) so it cannot be used cross-thread. 2. Enable SAB by default as combined with number 1 above it’s no more effective than an ArrayBuffer. (Though there might be some benefits as it cannot ever be detached.) 3. Implement the Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP) headers that when combined will allow postMessage() of SAB cross-thread (within the same scope as before). See https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit for a high-level, but detailed, explanation of these headers. We’ll likely do COEP support (and thereby full SAB support) for shared/service workers as a follow-up. 4. Implement a way to sequentially execute threads that can have shared memory as a security backstop (follow https://bugzilla.mozilla.org/show_bug.cgi?id=1563335 for details). We might ship 1 and 2 on Nightly to see what kind of breakage that gives. A risky part of this plan is that folks will have to test for postMessage() rather than SAB support going forward. Product: Mike Conca. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1477743 (though see https://bugzilla.mozilla.org/showdependencytree.cgi?id=1477743 for a better overview of the full scope of the work). Standard: None of this is fully standardized, but the processing model is agreed upon with Google (and has had at least some review from Apple, more so for COOP) and described in great detail. There’s some difficult refactoring necessary of the HTML navigation algorithm to integrate the various changes: * COOP: https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e (and issue linked from there) * COEP: https://mikewest.github.io/corpp/ (and issues linked from there) * postMessage() with conditional SAB support: https://github.com/whatwg/html/pull/4734 Note that SharedArrayBuffer itself is already enabled by default as ECMAScript (JavaScript) was never changed. And that standard requires a host to allow cross-thread usage as while it describes infrastructure for threads (agents) it doesn’t provide access to them without a host. Platform coverage: Desktop. Until mobile has better multi-process support we cannot do number 3 of the plan above. Preference: browser.tabs.remote.useCrossOriginOpenerPolicy (for COOP), browser.tabs.remote.useCrossOriginEmbedderPolicy (COEP), and javascript.options.shared_memory (SAB). postMessage() conditional support for SAB depends on the first two being set. DevTools bug: N/A. Other browsers: Based on the standards discussion and other information we believe Chrome will end up with the same end state. Safari is holding off for now. web-platform-tests: html/cross-origin-opener-policy/, html/cross-origin-embedder-policy/, html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/, and 2dcontext/imagebitmap/ have lots of relevant tests. https://github.com/web-platform-tests/wpt/issues/18354 tracks remaining work. Secure contexts: COOP and COEP are gated on secure contexts and therefore the postMessage() support for SAB is as well. SAB itself is not, though without a secure context you can only use it in a single thread, as a non-detachable ArrayBuffer. Is this feature enabled by default in sandboxed iframes? Yes. How stable is the spec: Even though this is not fully standardized I believe that the processing model is stable, with a good mutual understanding between implementers. Security & Privacy Concerns: Even though we isolate high-resolution timers to an isolated process per site, an attacker might be able to learn things from such a process. This should lessen over time as we continue to make progress with Fission. In the event of a dangerous cross-process zero-day attack, we’ll have the option to “disable” this feature by sequentially executing threads. Developer use-cases: Google Earth wants to use this to speed up rendering per https://medium.com/google-earth/performance-of-web-assembly-a-thread-on-threading-54f62fd50cf7 (please excuse the Medium link). Example: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer has a basic SAB example, though no cross-thread usage yet unfortunately. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform