This defines MOZ_CONTENT_TEMP_DIR to make it easier to track this in the code.
It also uses this to guard some Linux specific uses.
Differential Revision: https://phabricator.services.mozilla.com/D168596
This patch adds the ability for Windows on ARM to launch either x86 or
ARM Widevine plugins. It also adds the ability for Windows on x86 to
refuse ARM binaries in case, for example, a profile is transferred
between machines.
Overall this should be a non-functional change for users at the time of
landing. It does however allow us to ship the ARM Widevine plugin to
Windows ARM users to workaround a plugin crash with the x86 Widevine
plugin. This only affects Windows 10 users (Windows 11 works fine).
Differential Revision: https://phabricator.services.mozilla.com/D167634
ProcessWatcher takes ownership of the handle and may close it
immediately if the process has already exited, so that needs to
happen last; currently, because GetProcessId returns 0 for errors,
DeregisterChildCrashAnnotationFileDescriptor will be passed 0 in that
case, and will silently fail and leak resources.
Differential Revision: https://phabricator.services.mozilla.com/D160295
Previously the channel used by the ForkServer would be created using
IPC::Channel, and then stolen after the launch was successful. Unfortunately,
this required invoking IPC::Channel methods (such as `Close()`) from the wrong
thread, and so would be racy and hit assertions with the new checks being
added. This patch instead skips creating the IPC::Channel for the fork server,
and allows it to create and configure its own pipe as needed.
This may be used in the future to change out the IPC strategy for the fork
server to something more appropriate, which supports features like async
replies as forked processes die.
Differential Revision: https://phabricator.services.mozilla.com/D158161
This won't be used for any security or routing purposes, but can be useful for
debugging. It will be used in the future by the profiler to correlate sent and
received message events across processes.
Differential Revision: https://phabricator.services.mozilla.com/D153621
Previously this code read the atomic rather than the cached value (which
was unused). This is inherently racy as the atomic is updated on a
different thread than the read happened on.
Differential Revision: https://phabricator.services.mozilla.com/D153617
We were already turning off Mesa's shader cache in the RDD process,
because it's not useful given that we're only using video codec
acceleration and moving images around, and it does a few things related
to trying to access the cache that the sandbox would have to accomodate.
This patch does the equivalent thing for the nvidia proprietary driver;
we don't support it for media codec acceleration, but it can still be
loaded in that process (e.g., on multi-GPU systems) and it's trying to
call `statfs` on startup which may be related.
Differential Revision: https://phabricator.services.mozilla.com/D152932
Mesa 22.1.0 changed the env var name MESA_GLSL_CACHE_DISABLE to
MESA_SHADER_CACHE_DISABLE; it still accepts the old name, but prints a
deprecation warning. If we set both env vars, then we can support both
old and new Mesas correctly (the warning won't be printed if the new env
var is also set).
Differential Revision: https://phabricator.services.mozilla.com/D151094
Drop the com.apple.security.cs.allow-dyld-environment-variables entitlement to disallow use of dyld environment variables in signed production builds.
Leave the entitlement in for signed developer builds.
Firefox gtests depend on the use of DYLD_LIBRARY_PATH. However, testing infrastructure does not run gtests on signed builds and therefore gtests are not impacted by this change. gtests could be run on signed developer builds in the future which will still allow dyld environment variables after this change.
browser.production.entitlements.xml and plugin-container.production.entitlements.xml are not used, but being kept up to date.
Differential Revision: https://phabricator.services.mozilla.com/D148324
Change XUL and other dylibs to be built with an @rpath/<dylib> install name (LC_ID_DYLIB) instead of @executable_path/<dylib>.
Change executables to be built with an @rpath dyld search path set to @executable_path by default so that @rpath/<dylib> dylibs in the same directory can be resolved. For executables not in the same directory as @rpath dylibs, such as plugin-container, set a relative @rpath such as @executable_path/../../../.
Previously, dylib install names were set as @executable_path/<dylib> allowing them to be resolved by dyld for the loading executable if the executable resided in the same directory as the dylib. For executables not in the same directory as the dylibs, dyld resolved these dylibs using DYLD_LIBRARY_PATH set before launching the process by Firefox code. With this change, loading does not rely on DYLD environment variables. Instead, dylibs have an install name set as @rpath/<dylib> and each executable loading a dylib has its @rpath set at compile-time to refer to dylib directory.
Differential Revision: https://phabricator.services.mozilla.com/D147360
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
This patch mostly turns on the features set up by the earlier patches:
allow connecting to the X server and reading various related things
(.Xauthority, GPU device info in sysfs, etc.). It also turns off Mesa's
shader cache in the RDD process; that shouldn't be needed here, and
disabling it lets us avoid dealing with a few things in the sandbox
policy that we'd rather not (e.g., `getpwuid`).
Differential Revision: https://phabricator.services.mozilla.com/D146275
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
This patch mostly turns on the features set up by the earlier patches:
allow connecting to the X server and reading various related things
(.Xauthority, GPU device info in sysfs, etc.). It also turns off Mesa's
shader cache in the RDD process; that shouldn't be needed here, and
disabling it lets us avoid dealing with a few things in the sandbox
policy that we'd rather not (e.g., `getpwuid`).
Differential Revision: https://phabricator.services.mozilla.com/D146275
This makes passing around the type more consistent, and hopefully will make
changes to IPC::Message easier to work with in the future.
In addition, this should save us a few copies as we move the message type into
and out of UniquePtr, however I expect this won't make much of a difference.
Differential Revision: https://phabricator.services.mozilla.com/D145885
This makes passing around the type more consistent, and hopefully will make
changes to IPC::Message easier to work with in the future.
In addition, this should save us a few copies as we move the message type into
and out of UniquePtr, however I expect this won't make much of a difference.
Differential Revision: https://phabricator.services.mozilla.com/D145885
In future parts, TaskQueue will require extra initialization to be performed
which cannot happen in a constructor, as it takes references to the TaskQueue
object itself, which will require the introduction of a helper method. This
patch switches all callers of the TaskQueue constructor to use the new method.
Differential Revision: https://phabricator.services.mozilla.com/D142604
dom/media/ipc/RDDProcessManager.cpp(320,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
gpuProcessPid != -1 ? gpuProcessPid : base::GetCurrentProcId();
~~~~~~~~~~~~~ ^ ~~
dom/media/ipc/RDDProcessManager.cpp(332,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (gpuProcessPid != -1) {
~~~~~~~~~~~~~ ^ ~~
gfx/layers/ipc/SharedSurfacesParent.cpp(360,38): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (!gpm || gpm->GPUProcessPid() != -1) {
~~~~~~~~~~~~~~~~~~~~ ^ ~~
ipc/glue/MessageChannel.cpp(2145,13): error: comparison of integers of different signs: 'int32_t' (aka 'int') and 'const base::ProcessId' (aka 'const unsigned long') [-Werror,-Wsign-compare]
if (pid != base::kInvalidProcessId &&
~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
Differential Revision: https://phabricator.services.mozilla.com/D144688
