This adds two entry points: MainProcessInit and ChildProcessInit.
This mimicks what we have on Android (although the main process entry
point has a different name there, and the entry points are in mozglue
rather than libxul).
This adds enough stub from the upcoming swift side to build
independently.
Differential Revision: https://phabricator.services.mozilla.com/D230203
Previously the handling for the IO thread was split between
BrowserProcessSubThread (a replication of the background thread infrastructure
used by Chromium during the IPC import, which is only used for the IO thread in
Gecko), and IOThreadChild (a wrapper around ChildThread, which was imported
from Chromium's source).
This meant that there was little code-sharing between the parent and child
processes, and that the lifecycle of the IO thread was perhaps less clear.
This refactors the code to centralize handling of these threads, and provide a
basic common interface. At the moment, actually hooking up async IO listeners
is still done using the Chromium interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D227739
This abstracts away specifics of the chromium message loop from callers of
XRE_GetIOMessageLoop, giving a standard nsISerialEventTarget interface instead.
This is intended to make space for non-chromium IO backends in the future, such
as the potential to use libdispatch for IO on macOS and/or iOS.
Differential Revision: https://phabricator.services.mozilla.com/D227738
Previously the handling for the IO thread was split between
BrowserProcessSubThread (a replication of the background thread infrastructure
used by Chromium during the IPC import, which is only used for the IO thread in
Gecko), and IOThreadChild (a wrapper around ChildThread, which was imported
from Chromium's source).
This meant that there was little code-sharing between the parent and child
processes, and that the lifecycle of the IO thread was perhaps less clear.
This refactors the code to centralize handling of these threads, and provide a
basic common interface. At the moment, actually hooking up async IO listeners
is still done using the Chromium interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D227739
This abstracts away specifics of the chromium message loop from callers of
XRE_GetIOMessageLoop, giving a standard nsISerialEventTarget interface instead.
This is intended to make space for non-chromium IO backends in the future, such
as the potential to use libdispatch for IO on macOS and/or iOS.
Differential Revision: https://phabricator.services.mozilla.com/D227738
This builds on the support from bug 1440207 to allow passing mach ports into
new content processes. This is done using the existing initial mach IPC already
used to transfer a mach task port to the parent process on child process
creation.
Differential Revision: https://phabricator.services.mozilla.com/D221708
After this change, the fork server no longer uses a Dup2Sequence to set
fixed FD offsets when starting child processes, instead using the new
geckoargs system.
Because this was pretty disruptive to thow the fork server works and was
previously integrated into LaunchApp, the forkserver code has generally been
moved out of the chromium codebase, and inlined into the ForkServer files.
As the linux chroot sandbox code needs to run the chroot server from a process
created during forking, it is now being sent down to the fork server
separately, though the child end of the pipe is still being passed using
GeckoArgs.
Finally, the primary IPC pipe used by the fork server is also changed to
be passed using geckoargs into the fork server, and the fork server
being used is made more explicit in GeckoChildProcessHost, as launching
using the fork server now requires different arguments than launching
normally (due to needing to pass down the ChildProcessArgs).
Differential Revision: https://phabricator.services.mozilla.com/D221380
The code which decodes the XPC bootstrap message hasn't landed into
mozilla-central yet, so only the serializing side in GeckoChildProcessHost is
updated here.
Differential Revision: https://phabricator.services.mozilla.com/D221379
This changes how file descriptors are passed to Android child processes to
support the new ChildProcessArgs model. Instead of explicit lists of FDs to pass
around, a single array of FDs is passed from the parent process into the child
service and then passed into GeckoArgs.
Differential Revision: https://phabricator.services.mozilla.com/D221378
This effectively mimics the old system using fixed FDs for passing the
arguments down.
An in-memory array of FDs is used to track which FD corresponds with
with file argument, which is initialized to the fixed offsets, in order
to allow platforms which cannot use fixed FDs in their child processes
to specify explicit files being passed down. This will be used in the
fork server, for Android, and for iOS.
Differential Revision: https://phabricator.services.mozilla.com/D221377
Windows is the simplest platform to support, as HANDLEs are inherited by
identity into the child process, and there's less variance between different
OSes.
This effectively re-implements the existing behaviour used for HANDLE
passing on Windows by passing the handle directly on the command line.
Differential Revision: https://phabricator.services.mozilla.com/D221376
Previously these arguments were initialized in places which would be
inconvenient to use geckoargs with. This patch changes them to both be
initialized during SandboxLaunch::Configure in the parent process, and
then be passed down to the process launching code either within the
LaunchOptions object, or in the ChildProcessArgs object.
Unfortunately, we need to read the command line arguments within
XRE_InitChildProcess, rather than SandboxEarlyInit, as the sandbox code
is not linked directly to libxul, where the file handle GeckoArgs
methods are defined.
One of the more significant functional changes here is that when using
the fork server, the chroot pipe will be created within the parent
process, with the server end of the pipe passed over IPC to the fork
server to be used to create the chroot server. This is a bit
unnecessary, but keeps things simpler for the fork server, as geckoargs
are transferred directly from the parent process to the forked child
processes over the forkserver exec pipe.
Differential Revision: https://phabricator.services.mozilla.com/D221375
The initial IPC pipe was previously the only argument passed as a chromium
command line flag. This changes it to instead be passed using geckoargs,
unifying the platforms, and removing the need for specific handling on every
platform.
Differential Revision: https://phabricator.services.mozilla.com/D221374
The crash reporter pipe was previously passed as a positional argument with
custom code for each platform. On some platforms it is implemented as a file
being passed, which is now directly supported by geckoargs.
Differential Revision: https://phabricator.services.mozilla.com/D221373
This helps unify some logic between platforms, and removes some positional
arguments from the command line, so it ended up in this patch stack, despite
not technically being required to pass FDs directly.
Differential Revision: https://phabricator.services.mozilla.com/D221372
This patch implements the majority of the public interface for the new IPC
handle passing design.
The rough design is an expansion of `geckoargs` to allow passing
`UniqueFileHandle` arguments to child processes. This replaces the existing
extra options array to make the list of files explicit.
This currently just replaces things which were already passed this way on the
command line from outside of GeckoChildProcessHost. Note that this does not
migrate callers which were not already passing file handles using geckoargs,
and does not implement the actual OS-level support for passing arguments this
way.
Differential Revision: https://phabricator.services.mozilla.com/D221371
After this change, the fork server no longer uses a Dup2Sequence to set
fixed FD offsets when starting child processes, instead using the new
geckoargs system.
Because this was pretty disruptive to thow the fork server works and was
previously integrated into LaunchApp, the forkserver code has generally been
moved out of the chromium codebase, and inlined into the ForkServer files.
As the linux chroot sandbox code needs to run the chroot server from a process
created during forking, it is now being sent down to the fork server
separately, though the child end of the pipe is still being passed using
GeckoArgs.
Finally, the primary IPC pipe used by the fork server is also changed to
be passed using geckoargs into the fork server, and the fork server
being used is made more explicit in GeckoChildProcessHost, as launching
using the fork server now requires different arguments than launching
normally (due to needing to pass down the ChildProcessArgs).
Differential Revision: https://phabricator.services.mozilla.com/D221380
The code which decodes the XPC bootstrap message hasn't landed into
mozilla-central yet, so only the serializing side in GeckoChildProcessHost is
updated here.
Differential Revision: https://phabricator.services.mozilla.com/D221379
This changes how file descriptors are passed to Android child processes to
support the new ChildProcessArgs model. Instead of explicit lists of FDs to pass
around, a single array of FDs is passed from the parent process into the child
service and then passed into GeckoArgs.
Differential Revision: https://phabricator.services.mozilla.com/D221378
This effectively mimics the old system using fixed FDs for passing the
arguments down.
An in-memory array of FDs is used to track which FD corresponds with
with file argument, which is initialized to the fixed offsets, in order
to allow platforms which cannot use fixed FDs in their child processes
to specify explicit files being passed down. This will be used in the
fork server, for Android, and for iOS.
Differential Revision: https://phabricator.services.mozilla.com/D221377
Windows is the simplest platform to support, as HANDLEs are inherited by
identity into the child process, and there's less variance between different
OSes.
This effectively re-implements the existing behaviour used for HANDLE
passing on Windows by passing the handle directly on the command line.
Differential Revision: https://phabricator.services.mozilla.com/D221376
Previously these arguments were initialized in places which would be
inconvenient to use geckoargs with. This patch changes them to both be
initialized during SandboxLaunch::Configure in the parent process, and
then be passed down to the process launching code either within the
LaunchOptions object, or in the ChildProcessArgs object.
Unfortunately, we need to read the command line arguments within
XRE_InitChildProcess, rather than SandboxEarlyInit, as the sandbox code
is not linked directly to libxul, where the file handle GeckoArgs
methods are defined.
One of the more significant functional changes here is that when using
the fork server, the chroot pipe will be created within the parent
process, with the server end of the pipe passed over IPC to the fork
server to be used to create the chroot server. This is a bit
unnecessary, but keeps things simpler for the fork server, as geckoargs
are transferred directly from the parent process to the forked child
processes over the forkserver exec pipe.
Differential Revision: https://phabricator.services.mozilla.com/D221375
The initial IPC pipe was previously the only argument passed as a chromium
command line flag. This changes it to instead be passed using geckoargs,
unifying the platforms, and removing the need for specific handling on every
platform.
Differential Revision: https://phabricator.services.mozilla.com/D221374
The crash reporter pipe was previously passed as a positional argument with
custom code for each platform. On some platforms it is implemented as a file
being passed, which is now directly supported by geckoargs.
Differential Revision: https://phabricator.services.mozilla.com/D221373
This helps unify some logic between platforms, and removes some positional
arguments from the command line, so it ended up in this patch stack, despite
not technically being required to pass FDs directly.
Differential Revision: https://phabricator.services.mozilla.com/D221372
This patch implements the majority of the public interface for the new IPC
handle passing design.
The rough design is an expansion of `geckoargs` to allow passing
`UniqueFileHandle` arguments to child processes. This replaces the existing
extra options array to make the list of files explicit.
This currently just replaces things which were already passed this way on the
command line from outside of GeckoChildProcessHost. Note that this does not
migrate callers which were not already passing file handles using geckoargs,
and does not implement the actual OS-level support for passing arguments this
way.
Differential Revision: https://phabricator.services.mozilla.com/D221371
The new GeckoChildID type introduced in this patch is inspired by the existing
ContentParentID type used by ContentParent, but is currently distinct. It is
supported by all process types at the GeckoChildProcessHost level and can be
read for the current process from anywhere.
As this type is similar in many ways to the process type, and should be
available as early as possible within child processes, this was added alongside
the GeckoProcessType value within mozglue to make that easier to do.
The type was chosen to be an int32_t to make it feel similar to a PID, which we
currently use for process identity comparisons across the codebase. The
intention is for GeckoChildID to be preferred for these within-gecko checks, as
these IDs will not be re-used and can be known earlier during child process
creation.
Differential Revision: https://phabricator.services.mozilla.com/D217117
As the intended use for LaunchError::mFunction is telemetry, avoid the
possibility of accidental exfiltration of PII by requiring that
LaunchError be constructed from `StaticString`.
Additionally, remove the Windows-specific constructor overloads in favor
of an explicit factory function, and explicitly document that `mError`
is a generic bag of bits rather than any kind of strict error type.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D209712
This uses BrowserEngineKit's ExtensionKit-based processes to start content
processes on iOS. These processes are started with an initial xpc connection,
which is then used to communicate a command line, initial file descriptors
and environment variables before invoking content_process_main.
The XPC connection is not used further after the bootstrap message, which seems
to roughly match how WebKit uses these APIs.
Differential Revision: https://phabricator.services.mozilla.com/D202525
