1692842 - Flesh out IsSimdPrivilegedContext to allow wormhole to be used from experiments

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, enhancement, P1)

Description

[Lars T Hansen [:lth]]

We need to allow the wasm SIMD wormhole to be used from mozilla experiments until the functionality can be standardized, basically this amounts to adding code to wasm::IsSimdPrivilegedContext() so that it returns 'true' when called from an experiments context.

A less-good solution is to allow the wormhole to be used from any addon. This is "less-good" because it allows the use in more contexts, but it is reasonably safe, as no global prefs are involved, and no content (including add-ons) will stumble across the feature by accident - it must be triggered through the use of additional nonstandard parameters passed to the wasm compiler. And the feature itself is safe, modulo SIMD being unreleased.

From bug 1576254 we have cx->realm()->principals()->isSystemOrAddonPrincipal() which is used to enable wasm for some contexts even though the wasm pref is off. (The switch is also used by IsIonEnabled and IsBaselineJitEnabled to override disabled JITs in privileged contexts.) This is roughly right but, again, perhaps not as narrow as we would want in a perfect world?

So the question is, whether we can mimic that predicate with one that has an even narrower interpretation, ie, there would be another flag in WorkerPrincipal and a way to get that flag. Following this we end up in BasePrincipal::GetIsAddonOrExpandedAddonPrincipal(), for example. It's not obvious at first look that there is anything here separating an experiment from a regular addon.

Comment 1

[Lars T Hansen [:lth]]

On the JS side (in the extension code) we have this: https://searchfox.org/mozilla-central/source/toolkit/components/extensions/Extension.jsm#2142-2149. Perhaps we would like to mimic that in C++.

Comment 2

[Lars T Hansen [:lth]]

lgreco says on slack that "WebExtensionPolicy.webidl describes the addon and it is what we have access to from the C++ layer. It does also have an isPrivileged property: https://searchfox.org/mozilla-central/rev/8cb90829ccf18f95cd75d8419c84729c754a8e83/dom/chrome-webidl/WebExtensionPolicy.webidl#50".

This becomes the getter IsPrivileged https://searchfox.org/mozilla-central/source/toolkit/components/extensions/WebExtensionPolicy.h#62.

That getter is then referenced by BasePrincipal::IsL10nAllowed at https://searchfox.org/mozilla-central/source/caps/BasePrincipal.cpp#684.

Looking at https://searchfox.org/mozilla-central/source/caps/nsJSPrincipals.cpp#390 which defines isSystemOrAddonPrincipal, and https://searchfox.org/mozilla-central/source/caps/BasePrincipal.h#425 which defines IsSystemPrincipal, we could imagine a function calling AddonPolicy()->IsPrivileged() in the manner of https://searchfox.org/mozilla-central/source/caps/BasePrincipal.cpp#645.

The correct predicate name may then be isSystemOrPrivilegedAddonPrincipal(). Whether it's the right thing is another matter.

Comment 3

[Lars T Hansen [:lth]]

Attachment: Bug 1692842 - Stopgap solution for IsSimdPrivilegedContext. r?rhunt

This is the solution discussed in bug 1686652 - we use isSystemOrAddonPrincipal to
gate the interpretation of the nonstandard wasm compilation options bag in the
absence of a true value for javascript.options.wasm_simd_wormhole (since that
flag will not be available in late beta or later builds).

This is slightly more lenient than desirable as discussed on the present bug,
and if I can find a stricter check that works I will followup with that. In
the mean time, this check should be a reasonable and safe stopgap.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/79f9f998d815
Stopgap solution for IsSimdPrivilegedContext. r=rhunt

Comment 5

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/79f9f998d815