This extends the previous support for `-greomni` and `-appomni` to the
fork server, so that it can pre-open the jar files and thus continue
using the correct versions in forked child processes even if the files on
disk are replaced by an update or deleted.
Differential Revision: https://phabricator.services.mozilla.com/D185331
Currently, each content process re-derives the path(s) of the omnijar
file(s). We used to pass it down as a command-line argument, but
those args were also accepted by the parent process and there were
issues with that (CVE-2020-6799) such that they were completely removed
(bug 1531475). However, content processes can generally trust their
arguments; note that they currently accept `-appDir`.
We were already using `-gredir` for this on Android (it has a unified
omnijar, so there's no `-appdir` in that case); this patch subsumes the
content-process case of that, but not the parent process (which consumes
basically a fake argv constructed in Java code).
Note that only the parent process and content processes use the
omnijars; every other process type uses either minimal XPCOM, which
doesn't include them, or no XPCOM at all (e.g., GMP before bug 1845946).
The end goal of this patch series is to use those flags with the fork
server (so that it can preload the files without needing any XPCOM), but
this patch changes only the case of content processes.
Differential Revision: https://phabricator.services.mozilla.com/D182510
The `-appomni` flag isn't currently used, but the next patch will bring
it back and change how both flags are processed in child processes.
Differential Revision: https://phabricator.services.mozilla.com/D185330
This improves the quality of the logging from IPC::Channel, and also
adds extra assertions to ensure that it's aligned with the values
sent/received in the HELLO message.
This patch also makes the other_pid type more consistent, using
base::ProcessId instead of int32_t in IPC::Channel.
Differential Revision: https://phabricator.services.mozilla.com/D183410
Now that we've simplified the startup process somewhat, it is easier to clean
up IPC channel creation for NodeChannel connections. This stops having
GeckoChildProcessHost inherit from IPC::Channel::Listener, as it would never
receive most of the relevant callbacks, and instead implements the one callback
it would receive directly as a method on that type.
Differential Revision: https://phabricator.services.mozilla.com/D181282
This allows simplifying how IPC::Channel is created and passed between
processes, as all platforms now inherit the initial handle/fd into the content
process in a similar way. To keep things simple for now, I've continued to use
the base::CommandLine class to pass the HANDLE's identity on Windows, however
we may want to change this to make it a bit easier to follow, perhaps treating
it more like how we handle the IPC fd on Android.
Differential Revision: https://phabricator.services.mozilla.com/D181281
Use a new executable for the GMP process named "<App Name> Media Plugin Helper" so that the content processes (using the plugin-container executable) and the GMP process can be signed with different entitlements allowing for the use of more secure entitlements.
In order for the new executable to load the Widevine plugin, a change is needed in the codesigning infrastructure repo to generate the .sig file for the new executable.
To get the security benefits of using a new executable for GMP, additional changes are needed in the codesigning infrastructure repo to enable signing plugin-container and the new executable with a reduced set of entitlements.
The executable is a copy of plugin-container renamed as "<App Name> Media Plugin Helper" so it appears with a user friendly name in Activity Monitor. For example, "Firefox Media Plugin Helper". (The GMP process runs with limited privileges preventing it from setting its own "nice" process name.)
Pref off the change until the .sig file change lands and media playback has been validated on production builds.
Differential Revision: https://phabricator.services.mozilla.com/D175796
Use a new executable for the GMP process named "<App Name> Media Plugin Helper" so that the content processes (using the plugin-container executable) and the GMP process can be signed with different entitlements allowing for the use of more secure entitlements.
To get the benefits of using a new executable for GMP, additional changes are needed in the codesigning infrastructure repo to enable signing plugin-container and the new executable with a reduced set of entitlements.
The executable is built as media-plugin-helper and then renamed to "<App Name> Media Plugin Helper" so it appears with a user friendly name in Activity Monitor. For example, "Firefox Media Plugin Helper". (The GMP process runs with limited privileges preventing it from setting its own "nice" process name.)
Limit the change to Nightly at this time to allow validation of using a new executable and then enabling the strong entitlements.
Differential Revision: https://phabricator.services.mozilla.com/D175796
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
