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
