This adds "hasSeccompBPF" for seccomp-bpf support; other "has" keys
will be added in the future (e.g., user namespaces).
This also adds "canSandboxContent" and "canSandboxMedia", which are
absent if the corresponding type of sandboxing isn't enabled at build
type (or is disabled with environment variables), and otherwise present
as a boolean indicating whether that type of sandboxing is supported.
Currently this is always the same as hasSeccompBPF, but that could change
in the future.
Some changes have been made to the "mozilla/Sandbox.h" interface to
support this; the idea is that the MOZ_DISABLE_*_SANDBOX environment
variables should be equivalent to disabling MOZ_*_SANDBOX at build time.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
This is mostly for ASAN builds, which --disable-crash-reporter, but also
fixes a related papercut: debug builds don't use the crash reporter
unless overridden with an environment variable.
Note: this is Linux-only, so NS_StackWalk is always part of the build;
see also bug 1063455.
This change also includes the content sandboxing code on Windows Nightly by defining MOZ_CONTENT_SANDBOX=1.
Whether the content sandbox is disabled, in warn only mode, or enabled is controlled by a new pref: browser.tabs.remote.sandbox=(off/warn/on)
This change also includes the content sandboxing code on Windows Nightly by defining MOZ_CONTENT_SANDBOX=1.
Whether the content sandbox is disabled, in warn only mode, or enabled is controlled by a new pref: browser.tabs.remote.sandbox=(off/warn/on)
MFBT_API is not the right macro for this; it changes the affected
definition/usage to a weak symbol, for reasons explained in the comments
on its definition.
This was causing the linker to drop the dependency from libmozglue
to libmozsandbox, in some cases (--as-needed, with a linker that
doesn't consider weak symbols "needed"), and thus load libxul with
gSandboxCrashFunc relocated to address 0 (the expected behavior of an
unresolved weak symbol), which caused crashes when writing to it on
startup.
--HG--
extra : amend_source : b99fded391ae90b1311f4cabaf40f15e6414f245
This creates libmozsandbox.so on builds that use sandboxing
(MOZ_CONTENT_SANDBOX or MOZ_GMP_SANDBOX).
The unavoidably libxul-dependent parts, for invoking the crash reporter
and printing the JS context, are separated into glue/SandboxCrash.cpp
and invoked via a callback.
