Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
Currently the Android implementation of process launch signals failure by
returning pid 0 through an out-parameter; we don't check for that, so we
report success and then the bad pid spreads through IPC until it sets off
an assertion somewhere else. This patch adds the missing check and
strengthens an assertion that would have caught the problem more directly.
Differential Revision: https://phabricator.services.mozilla.com/D32875
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
Start the RDD process earlier by changing RDDProcessHost to pass the necessary command line arguments for enabling the sandbox.
Per lsmp output on 10.14.3, starting the RDD process sandbox removes access to WindowServer, coreservicesd, lsd and distnoted.
Add a pref (defaulting to on) to control enabling starting the RDD process earlier.
Differential Revision: https://phabricator.services.mozilla.com/D23460
GMP shouldn't need them anyway, and this reduces the dependencies from the x86
build we need to package in the "i686" subdir.
Differential Revision: https://phabricator.services.mozilla.com/D19902
This patch assumes that "the build" places plugin-container.exe, xul.dll, and
their dependencies in the "i686" subdirectory of the aarch64 firefox package
directory.
Differential Revision: https://phabricator.services.mozilla.com/D19898
Launching processes takes enough time that we should avoid blocking the
parent process's IPC I/O thread for it; it's less bad for responsiveness
than blocking the main thread, but it's not good.
On Windows we need to use a dedicated thread, because the sandbox isn't
thread-safe and it asserts that the same thread is used for every
launch. Otherwise, a thread pool is used. (Or, in the Web Replay
middleman process, where there isn't enough of XPCOM for any of this,
launching the actual content processes remains on the I/O thread.)
Depends on D18011
Differential Revision: https://phabricator.services.mozilla.com/D8946
In order to enable asynchronous launch, destruction of
GeckoChildProcessHost (and its subclasses) has to be delayed until after
launching (or anything else that might be made asynchronous in the
future) has completed, to prevent use-after-free. However, there are
other dependencies on process hosts always being destroyed on the I/O
thread, so refcounting would be difficult to use.
Instead, GeckoChildProcessHost now may not be destroyed directly, but
must go through a method that handles the scheduling.
There are also some minor cleanups to the affected headers (removed
duplicate access modifiers, and made PluginProcessParent final).
Depends on D18010
Differential Revision: https://phabricator.services.mozilla.com/D18011
Avoiding handle duplication for certain kinds of processes and allowing
it for everything else seems to be what we're already doing, so let's
make it easier to add new process types with that scheme in mind.
The command-line parameter used by nsEmbedFunctions.cpp is turned into
an nsIFile, and then said nsIFile is never used. Its last use was
deleted in bug 1407693, where we reworked how extra annotations were
done.
Launching processes takes enough time that we should avoid blocking the
parent process's IPC I/O thread for it; it's less bad for responsiveness
than blocking the main thread, but it's not good.
On Windows we need to use a dedicated thread, because the sandbox isn't
thread-safe and it asserts that the same thread is used for every
launch. Otherwise, a thread pool is used. (Or, in the Web Replay
middleman process, where there isn't enough of XPCOM for any of this,
launching the actual content processes remains on the I/O thread.)
Depends on D15886
Differential Revision: https://phabricator.services.mozilla.com/D8946
We can directly set environment variables for the child process on
all platforms now, instead of changing the parent's environment and
inheriting the changes. This simplifies memory management, but more
importantly it's necessary for thread safety to allow launching
processes from a thread pool.
Depends on D8944
Differential Revision: https://phabricator.services.mozilla.com/D8945
This patch adds some telemetry histograms:
* CONTENT_PROCESS_LAUNCH_IS_SYNC - boolean, true if the content process
was launched synchronously (blocking the main thread)
* CONTENT_PROCESS_SYNC_LAUNCH_MS - the time consumed by sync launch;
the main thread will be busy or blocked for this entire time
* CONTENT_PROCESS_LAUNCH_TOTAL_MS - the total time elapsed from the
start of async content process launch until the launch promise is
resolved and the ContentParent can be sent IPDL messages
* CONTENT_PROCESS_LAUNCH_MAINTHREAD_MS - the time consumed on the parent
process main thread during async content process launch; typically this
is due to ContentParent::Init.
* CHILD_PROCESS_LAUNCH_MS - for any kind of Gecko child process
(including plugins, GPU, etc.), the time taken in the common process
launch code (which is run off-main-thread)
The probes restricted to async content process launch don't have "async"
in the name because that will eventually become the only kind of content
process launch.
Depends on D8943
Differential Revision: https://phabricator.services.mozilla.com/D8944
There are several layers to this patch:
1. GeckoChildProcessHost now exposes a promise that's resolved when
the process handle is available (or rejected if launch failed), as a
nonblocking alternative to LaunchAndWaitForProcessHandle.
2. ContentParent builds on this with the private method
LaunchSubprocessAsync and the public method PreallocateProcessAsync;
synchronous launch continues to exist for the regular on-demand launch
path, for the time being.
3. PreallocatedProcessManager now uses async launch, and handles the new
"launch in progress" state appropriately.
Depends on D8942
Differential Revision: https://phabricator.services.mozilla.com/D8943
The first attempt at async launch tried to hide the asynchrony inside
IPC, by making the process seem to be launched enough to construct new
channels and send it messages, and lazily blocking on the pid/handle.
Unfortunately, in practice we wind up needing the pid/handle immediately,
and this requirement is too deeply embedded in IPC for that to be viable.
(The alternative that will be used instead -- exposing process launch via
an explicitly asynchronous promise interface -- is made simpler by
Project Fission's upcoming rewrite of how the DOM requests new content
processes.)
Depends on D8941
Differential Revision: https://phabricator.services.mozilla.com/D8942
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
Launching processes takes enough time that we should avoid blocking the
parent process's IPC I/O thread for it; it's less bad for responsiveness
than blocking the main thread, but it's not good.
On Windows we need to use a dedicated thread, because the sandbox isn't
thread-safe and it asserts that the same thread is used for every
launch. Otherwise, a thread pool is used.
Depends on D8945
Differential Revision: https://phabricator.services.mozilla.com/D8946
We can directly set environment variables for the child process on
all platforms now, instead of changing the parent's environment and
inheriting the changes. This simplifies memory management, but more
importantly it's necessary for thread safety to allow launching
processes from a thread pool.
Depends on D8944
Differential Revision: https://phabricator.services.mozilla.com/D8945
This patch adds some telemetry histograms:
* CONTENT_PROCESS_LAUNCH_IS_SYNC - boolean, true if the content process
was launched synchronously (blocking the main thread)
* CONTENT_PROCESS_SYNC_LAUNCH_MS - the time consumed by sync launch;
the main thread will be busy or blocked for this entire time
* CONTENT_PROCESS_LAUNCH_TOTAL_MS - the total time elapsed from the
start of async content process launch until the launch promise is
resolved and the ContentParent can be sent IPDL messages
* CONTENT_PROCESS_LAUNCH_MAINTHREAD_MS - the time consumed on the parent
process main thread during async content process launch; typically this
is due to ContentParent::Init.
* CHILD_PROCESS_LAUNCH_MS - for any kind of Gecko child process
(including plugins, GPU, etc.), the time taken in the common process
launch code (which is run off-main-thread)
The probes restricted to async content process launch don't have "async"
in the name because that will eventually become the only kind of content
process launch.
Depends on D8943
Differential Revision: https://phabricator.services.mozilla.com/D8944
There are several layers to this patch:
1. GeckoChildProcessHost now exposes a promise that's resolved when
the process handle is available (or rejected if launch failed), as a
nonblocking alternative to LaunchAndWaitForProcessHandle.
2. ContentParent builds on this with the private method
LaunchSubprocessAsync and the public method PreallocateProcessAsync;
synchronous launch continues to exist for the regular on-demand launch
path, for the time being.
3. PreallocatedProcessManager now uses async launch, and handles the new
"launch in progress" state appropriately.
Depends on D8942
Differential Revision: https://phabricator.services.mozilla.com/D8943
The first attempt at async launch tried to hide the asynchrony inside
IPC, by making the process seem to be launched enough to construct new
channels and send it messages, and lazily blocking on the pid/handle.
Unfortunately, in practice we wind up needing the pid/handle immediately,
and this requirement is too deeply embedded in IPC for that to be viable.
(The alternative that will be used instead -- exposing process launch via
an explicitly asynchronous promise interface -- is made simpler by
Project Fission's upcoming rewrite of how the DOM requests new content
processes.)
Depends on D8941
Differential Revision: https://phabricator.services.mozilla.com/D8942
