This patch adjusts the various places where we initialize content
processes to call SetGeckoProcessType as early as possible, and be more
consistent. After this change we should only ever set GeckoProcessType
and GeckoChildID once per-process (with the exception of the fork server
process).
In addition to this validation, some more checks around the fork server
were added, such as to prevent forking another forkserver, or forking a
non-content process.
As part of this change, there was some refactoring/cleanup done, such as
removing plugin-container.cpp and content_process_main, as compared to
the other duplicated code between the two call-sites, the duplication
was relatively small, and inlining it helped make things more readable.
Differential Revision: https://phabricator.services.mozilla.com/D218471
This requires quite a bit of piping to get the ChildID passed everywhere where
we currently pass the pid in IPC. This is done by adding a new struct type
(EndpointProcInfo), which is passed around instead of OtherPid in these places,
and contains the full pid.
In most cases, it was a fairly painless change to move over, however in some
cases, more complex changes were required, as the pid was being stored
previously in something like an Atomic<...>, and needed to be switched to using
a mutex-protected value.
In the future, it may be possible to remove OtherPid from IPDL actors once
everything is migrated to ChildID, but we're still a long way off from that, so
for now we unfortunately need to pass both around.
Differential Revision: https://phabricator.services.mozilla.com/D217118
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
There's no sufficiently robust way to identify POD types in C++, such
that we could rely on this kind of thing for serialization.
As one example, `bool` must be carefully handled on deserialize, in case
an attacker wants to exploit the UB of bool with value 2.
Additionally, generally it's not viable to tell whether all the members
of a struct are PODs as well, and we need that level of assurance
recursively!
So we instead lean on e.g. ParamTraits_TiedFields/_IsEnumCase for our
extreme robustness requirements.
Differential Revision: https://phabricator.services.mozilla.com/D217518
In more recent versions of C++, it is possible to declare a C union with
non-POD members, so long as there is an explicit destructor/constructor
responsible for managing the members.
This patch switches to using the variant types directly within the
union, rather than using AlignedStorage to store inline members. This
requires some tweaks to how the union is declared (specifically, it must
be an anonymous inline union so that it shares the main union type's
constructor/destructor, otherwise explicit ctors/dtors would need to be
declared for the bare union type).
Overall, this change should make no functional difference.
Differential Revision: https://phabricator.services.mozilla.com/D216329
File-picker telemetry shows that most failures to open the file dialog
remotely arise in `UtilityProcessHost::OnChannelClosed`. This ultimately
derives from `IProtocol::ActorDisconnected()`, which is called from many
points, mostly generated code.
Rather than jumping in and writing error-propagation code all the way
back up the stack, send what little information we can easily access up
to the file-picker failure telemetry; this should narrow down what
portion of the code we need to look at to determine the root cause of
these failures.
Differential Revision: https://phabricator.services.mozilla.com/D216350
Test that the file-picker-crashed notification appears when the
file-picker utility process is terminated with a file-picker dialog
active.
Differential Revision: https://phabricator.services.mozilla.com/D215980
Currently, PRemoteWorker is managed by PBackground, which should be the same as the manager of the corresponding PRemoteWorkerService. Since the PBackground is gotten from PRemoteWorkerService.
This patch makes PRemoteWorkerService directly manage the PRemoteWorker.
PRemoteWorker will handle the life-cycle-related operations of RemoteWorkers, it might be renamed in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D196946
This commit is a prerequisite for part 5 of this patch set
and introduces the `text directive user activation` flag
as well as the necessary boilerplate to transport the value
through process boundaries in `nsDocShellLoadState` and `LoadInfo`.
There is no changed behavior in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D212816
This enables the PRemoteWorkerService to be created by the parent process
instead of by the content process, which is useful as the parent process is the
party initiating remote worker actions.
Differential Revision: https://phabricator.services.mozilla.com/D213333
Previously the identity of the BackgroundParent thread was hidden to encourage
all communication with that thread, including communication within the parent
process, to go over PBackground. This has not born out as effective in
practice, however.
By exposing the thread's identity through a getter available on the background
or main thread, we can simplify the process of dispatching a runnable to the
background thread. This will be useful later in this bug as some actors are
migrated off of PBackground, but still need to run on that thread.
Differential Revision: https://phabricator.services.mozilla.com/D213311
This enables the PRemoteWorkerService to be created by the parent process
instead of by the content process, which is useful as the parent process is the
party initiating remote worker actions.
Differential Revision: https://phabricator.services.mozilla.com/D213333
Previously the identity of the BackgroundParent thread was hidden to encourage
all communication with that thread, including communication within the parent
process, to go over PBackground. This has not born out as effective in
practice, however.
By exposing the thread's identity through a getter available on the background
or main thread, we can simplify the process of dispatching a runnable to the
background thread. This will be useful later in this bug as some actors are
migrated off of PBackground, but still need to run on that thread.
Differential Revision: https://phabricator.services.mozilla.com/D213311
This commit is a prerequisite for part 5 of this patch set
and introduces the `text directive user activation` flag
as well as the necessary boilerplate to transport the value
through process boundaries in `nsDocShellLoadState` and `LoadInfo`.
There is no changed behavior in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D212816
This enables the PRemoteWorkerService to be created by the parent process
instead of by the content process, which is useful as the parent process is the
party initiating remote worker actions.
Differential Revision: https://phabricator.services.mozilla.com/D213333
Previously the identity of the BackgroundParent thread was hidden to encourage
all communication with that thread, including communication within the parent
process, to go over PBackground. This has not born out as effective in
practice, however.
By exposing the thread's identity through a getter available on the background
or main thread, we can simplify the process of dispatching a runnable to the
background thread. This will be useful later in this bug as some actors are
migrated off of PBackground, but still need to run on that thread.
Differential Revision: https://phabricator.services.mozilla.com/D213311
Previously the PVerifySSLServerCert protocol consisted of two functions: one to
call when certificate verification succeeded, and another to call upon failure.
This was unnecessary, as the code before and after this protocol didn't have
the same split. This patch unifies the protocol to better match the surrounding
code. It also takes the opportunity to make use of some IPC helpers to
serialize enums rather than manually casting to and from basic integer types.
Differential Revision: https://phabricator.services.mozilla.com/D212594
* Adjust UtilityProcess{Host,Manager} to propagate ipc::LaunchErrors for
their clients, or to create new ones where none previously existed.
* Adjust the various clients of the above to to handle the additional
information -- mostly by adding the additional failure-location data
to log messages.
* Fix an unrelated bug wherein the return type of `LaunchProcess` was
declared as exclusive, despite being cached and reused.
In particular, filedialog::Error objects should now contain -- and report
to telemetry without further adjustment -- the actual error code from
`ipc::LaunchError`s.
(Reporting the original failure location as well will occur in bug
1884221.)
Differential Revision: https://phabricator.services.mozilla.com/D209715
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
As we've added encryption scheme per content type in previous patches,
there is no need to keep this old encryption scheme.
Differential Revision: https://phabricator.services.mozilla.com/D211793
