If the limit is small, then the fuzzers hit crashes in various places when
passing in large data structures to DOM APIs, so increase the limit.
Differential Revision: https://phabricator.services.mozilla.com/D130890
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
If the limit is small, then the fuzzers hit crashes in various places when
passing in large data structures to DOM APIs, so increase the limit.
Differential Revision: https://phabricator.services.mozilla.com/D130890
Handles which are directly attached to IPC messages will be transferred by the
parent process. This is handled either directly by the parent process (if it is
one of the participants), or by relaying the message via the parent process if
it is not. Ordering issues are avoided here thanks to support in the mojo ports
code for messages being delivered out-of-order.
The actual handle values are encoded in the message after the message payload,
and removed from the message before handing it off to existing code, so it
should be fully transparent.
In addition, a new flag is added to the message header to support marking a
message as a "relay" message, as well as support for deserializing these
messages with an extra NodeName (the real target/source) in the message footer.
Differential Revision: https://phabricator.services.mozilla.com/D126565
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
In part 2 of this patch, a large number of messages are being converted to
contain move-only types, both as direct arguments and within compound data
structures. This revealed some limitations in IPDL's handling of moveonly
types, which this patch hopes to rectify. This also required changes to allow
distinguishing between types which require move to send vs. them not having a
move constructor.
This does not fully fix the underlying issues, but attempts to preserve
existing behaviour while improving support for the new types being added. There
should be further cleanup in the future.
Differential Revision: https://phabricator.services.mozilla.com/D126563
We could do this in HKLM using registry.dat, but that file is difficult to manage.
Instead, we register in HKCU at runtime.
Also, RegCreateKeyTransacted doesn't work in MSIX containers, so we must use RegCreateKeyEx.
Differential Revision: https://phabricator.services.mozilla.com/D129950
Handles which are directly attached to IPC messages will be transferred by the
parent process. This is handled either directly by the parent process (if it is
one of the participants), or by relaying the message via the parent process if
it is not. Ordering issues are avoided here thanks to support in the mojo ports
code for messages being delivered out-of-order.
The actual handle values are encoded in the message after the message payload,
and removed from the message before handing it off to existing code, so it
should be fully transparent.
In addition, a new flag is added to the message header to support marking a
message as a "relay" message, as well as support for deserializing these
messages with an extra NodeName (the real target/source) in the message footer.
Differential Revision: https://phabricator.services.mozilla.com/D126565
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
In part 2 of this patch, a large number of messages are being converted to
contain move-only types, both as direct arguments and within compound data
structures. This revealed some limitations in IPDL's handling of moveonly
types, which this patch hopes to rectify. This also required changes to allow
distinguishing between types which require move to send vs. them not having a
move constructor.
This does not fully fix the underlying issues, but attempts to preserve
existing behaviour while improving support for the new types being added. There
should be further cleanup in the future.
Differential Revision: https://phabricator.services.mozilla.com/D126563
This patch adds support for ManagedEndpoint instances to be dropped &
gracefully destroyed. Before this change, a ManagedEndpoint which was
dropped without being bound would not clean up its' peer actor, meaning
that messages to and from that actor would be discarded.
This is done by adding a new actor destroy reason for dropping a
ManagedEndpoint.
Differential Revision: https://phabricator.services.mozilla.com/D128776
We still rely on dynamic loading to find the symbols, but since we get
them from libxul, we don't need to load the library before activating
the process sandbox anymore.
Differential Revision: https://phabricator.services.mozilla.com/D128333
Handle crash with the old way if the fork server is prefed out, and waitpid() for all available stat changes of children processes in the forkserver.
Differential Revision: https://phabricator.services.mozilla.com/D110507
Handle crash with the old way if the fork server is prefed out, and waitpid() for all available stat changes of children processes in the forkserver.
Differential Revision: https://phabricator.services.mozilla.com/D110507
Previously we were staring `PBackground` in content processes in
response to receiving the `SetXPCOMProcessAttributes` IPC message, which
is sent immediately after the process is launched. Meanwhile, the
idle scheduler tries to use PBackground when the main thread considers
itself idle. But if thread scheduling is such that the content process
main thread becomes idle before the IPC I/O thread has received and
dispatched that message, then we have a problem (signaled by an assertion
failure).
This patch moves content process `PBackground` startup earlier, to the
end of `ContentProcess::Init`; that point is after enough of IPC and
XPCOM is started for it to work, but before we start spinning the main
thread event loop.
Differential Revision: https://phabricator.services.mozilla.com/D126144
Previously we were staring `PBackground` in content processes in
response to receiving the `SetXPCOMProcessAttributes` IPC message, which
is sent immediately after the process is launched. Meanwhile, the
idle scheduler tries to use PBackground when the main thread considers
itself idle. But if thread scheduling is such that the content process
main thread becomes idle before the IPC I/O thread has received and
dispatched that message, then we have a problem (signaled by an assertion
failure).
This patch moves content process `PBackground` startup earlier, to the
end of `ContentProcess::Init`; that point is after enough of IPC and
XPCOM is started for it to work, but before we start spinning the main
thread event loop.
Differential Revision: https://phabricator.services.mozilla.com/D126144
ipc/chromium/src/chrome/common/ipc_channel_win.cc(133,8): error: variable 'waited' set but not used [-Werror,-Wunused-but-set-variable]
bool waited = false;
^
ipc/mscom/InterceptorLog.cpp(183,12): error: variable 'rv' set but not used [-Werror,-Wunused-but-set-variable]
nsresult rv = mThread->Dispatch(
^
Differential Revision: https://phabricator.services.mozilla.com/D126455
To differentiate the storage permission is granted by either the
permission or the allowList, we need to change the hasStoragePermission
to an enum to represent the storage permission state.
This patch also changes the name of the attribute to make it reasonable
with respect to this change.
Differential Revision: https://phabricator.services.mozilla.com/D126276
