This patch does several things. Because Workers aren't on the main thread,
many of the things done are in the name of off main thread access.
1) Changes a parameter in IsEvalAllowed from a nsIPrincipal to a bool.
We only used the principal to determined if it was the System Principal.
Principals aren't thread safe and can only be accessed on Main Thread, so
if we passed a Principal in, we would be in error. Instead only pass in
the bool which - for workers - comes from a thread-safe location.
2) Separates out the Telemetry Event Recording and sending a message to the
console into a new function nsContentSecurityUtils::NotifyEvalUsage. (And
creates a runnable that calls it.)
We do this because we will need to only call this method on the main thread.
Telemetry Event Recording has only ever been called on the Main Thread.
While I possibly-successfully cut it over to happen Off Main Thread (OMT)
by porting preferences to StaticPrefs, I don't know if there were other
threading assumptions in the Telemetry Code. So it would be much safer to
just continue recording Event Telemetry on the main thread.
Sending a message to the console requires calling GetStringBundleService()
which requires main thread. I didn't investigate if this could be made
thread-safe, I just threw it onto the main thread too.
If, in IsEvalAllowed, we are on the main thread - we call NotifyEvalUsage
directly. If we are not, we create a runnable which will then call
NotifyEvalUsage for us on the main thread.
3) Ports allow_eval_with_system_principal and allow_eval_in_parent_process
from bools to RelaxedAtomicBool - because we now check these prefs OMT.
4) In RuntimeService.cpp, adds the call to IsEvalAllowed.
5) Add resource://gre/modules/workers/require.js to the allowlist of eval
usage. This was the script that identified this gap in the first place.
It uses eval (twice) for structural reasons (scope and line number
massaging.) The contents of the eval are the result of a request to a
uri (which may be internal, like resource://). The whole point of this
is to implement a CommonJS require() api.
This usage of eval is safe because the only way an attacker can inject
into it is by either controlling the response of the uri request or
controlling (or appending to) the argument. If they can do that, they
are able to inject script into Firefox even if we cut this usage of eval
over to some other type of safe(r) script loader.
Bug 1584564 tracks making sure calls to require.js are safe.
6) Adds cld-worker.js to the allowlist. Bug 1584605 is for refactoring that
eval usage, which is decidedly non-trivial.
7) Does _not_ enforce the eval restrictions for workers. While I've gotten
try to be green and not throw up any instances of eval-usage by workers,
it is much safer to deploy this is Telemetry-only mode for Workers for
a little bit to see if anything pops up from the Nightly population.
Bug 1584602 is for enforcing the checks.
Differential Revision: https://phabricator.services.mozilla.com/D47480
--HG--
extra : moz-landing-system : lando
Unlike WorkletPrincipal, a WorkerPrincipal had been a simple static object shared by
all Workers. We never needed to consult it about an individual Worker before. Now we
do. So we cut it over from a static object to individual objects for each Worker.
We have an off main thread access problem for the Principal however, WorkerPrivate
has a method UsesSystemPrincipal that returns a bool that was initialized from the
Principal on the main thread. We copy that pattern and add a
UsesAddonOrExpandedAddonPrincipal method that will be called by the
isSystemOrAddonPrincipal method we must implement so we can inheirt from JSPrincipal.
Differential Revision: https://phabricator.services.mozilla.com/D47476
--HG--
extra : moz-landing-system : lando
In a future commit we will tie this boolean to its own preference value, but here we
initialize it with the same value as the wasm boolean.
We also update wasm::HasSupport to check the to-be-added isSystemOrAddonPrincipal()
method on JSPrincipals to determine which member (wasm or wasmForTrustedPrinciples)
to consult.
Differential Revision: https://phabricator.services.mozilla.com/D47472
--HG--
extra : moz-landing-system : lando
They're infallible in practice and always `NS_OK`. (This stems from
`AddVarCacheNoAssignment()` always returning `NS_OK`.)
As a result, the commit removes lots of unnecessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D39804
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
to make AutoJSAPI error reporting safe for worklets.
Parameter order matches xpc::ErrorReport::Init().
Depends on D34477
Differential Revision: https://phabricator.services.mozilla.com/D34478
--HG--
extra : moz-landing-system : lando
Using process-wide prefs is consistent with the other JIT options and is simpler
to work with (one place to initialize for all runtimes).
Differential Revision: https://phabricator.services.mozilla.com/D37385
--HG--
extra : moz-landing-system : lando
Update the memory pressure observers for main thread and workers to call the new JS API to set/clear the low memory state.
Differential Revision: https://phabricator.services.mozilla.com/D35682
This does the following:
- It introduces a controlling ifdef ENABLE_WASM_REFTYPES that enables
exactly those features that are in the reftypes proposal, excluding
those in the gc proposal. Any remaining features (namely, ref.eq,
(ref T) types, struct types) are still under ENABLE_WASM_GC control.
ENABLE_WASM_GC requires ENABLE_WASM_REFTYPES and this is checked.
- It introduces a new TestingFunctions predicate, wasmReftypesEnabled,
that distinguishes reftype-proposal support from gc-proposal
support. We keep wasmGcEnabled to test for gc-proposal support.
- It segregates test cases so that gc-proposal relevant tests are in
their own files, and tests relevant to the reftypes-proposal are now
guarded by wasmReftypesEnabled.
- It renames the predicate HasGcSupport() as HasReftypesSupport(),
since that is what the predicate tests for.
- It has a drive-by fix for the DEBUG-only function wasm::Classify()
to properly put ref.null and ref.is_null under ifdef control.
Reftypes will soon be enabled unconditionally in Nightly (once we can
trace pointers from Ion frames) while gc-types will remain conditional
until Ion supports all the new instructions for struct types. Therefore:
- The command line switch and about:config option are still called
--wasm-gc and j.o.wasm_gc, respectively, which is fine since they will
fairly soon control only gc-proposal features.
- Internal names still use "Gc" rather than "Reftypes", eg,
HasGcTypes, wasmGc_, and so on. This is most appropriate since it
reduces the scope of the patch and these names will pertain mainly
to the gc feature in the future.
--HG--
extra : rebase_source : 51cf3bfe67da594e89195472e4ce1ccfa36c146d
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.