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
This simplifies the logic around MessageTask's lifecycle to make
ownership as clear as possible and reduce the number of redundant
checks.
This new change no longer clears the mChannel member when the
MessageTask is disconnected, instead relying on isInList() to check
whether the MessageTask is still in the channel's mPending list. This is
already being automatically managed as the mPending list is modified,
and should avoid potential usage mistakes.
Differential Revision: https://phabricator.services.mozilla.com/D123140
This change instead recovers from unhandled special messages by reporting a
normal IPC error, which should be handled using the normal IPC error
mechanisms.
Depends on D123148
Differential Revision: https://phabricator.services.mozilla.com/D123149
When this change was first implemented, it ignored dead actors for all types of
messages, but for messages with replies they cannot be ignored, as a reply must
be sent. This should fix that oversight.
Differential Revision: https://phabricator.services.mozilla.com/D123148
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
rlbox_wasm2c_sandbox was adjusted to avoid using LoadLibraryA (rejected by
build/clang-plugin/LoadLibraryUsageChecker.cpp), so we adjust
GetSandboxedRLBoxPath (which is used to feed it) to return an UTF-16
string on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D123025
Memory for memfd files isn't subject to any file size limit, unlike
named files in /dev/shm, and is documented as being handled similarly
to anonymous mmap for accounting / resource management purposes.
Therefore, there isn't any need to pre-commit the memory with
posix_fallocate in that case.
Differential Revision: https://phabricator.services.mozilla.com/D121818
This merges the cases for posix_fallocate being unavailable at build
time and being rejected dynamically by the OS (some don't support
it with their implementation of POSIX shm), to make it simple to
dynamically opt out in the memfd case.
Differential Revision: https://phabricator.services.mozilla.com/D121817
This lets the idle scheduler know that we've initiated a GC that we didn't
ask its permission for. Eg the JS engine hit a threshold. It now uses this
info when scheduling GCs for other processes.
Differential Revision: https://phabricator.services.mozilla.com/D120831
This patch also:
* adds an assertion to KillGCRunner() to ensure it's never killed if
needed, now that there are more calls to KillGCRunner(), some calls have
been moved eg in nsJSEnvironment so as not to kill the runner a little
later and keep the assertions happy.
* IdleSchedulerChild will decline a request for a GC if there's already a
request in flight.
* CCGCScheduler will check if a GC is already in progress when handling the
parents' response to a GC request.
Differential Revision: https://phabricator.services.mozilla.com/D120830
`mscom::ProcessRuntime` supports multiple instances because Reasons (TM).
To make this happen, we store some information in `mozglue` that enforces
serialization between instances and also informs an instance as to whether
any other instances have successfully completed initialization.
Unfortunately it is possible for us to encounter situations where one instance
manages to *partially* but not *completely* finish initialization. Since our
shared information is currently a simple `bool`, we cannot really capture this
case.
Furthermore, APIs such as `CoInitializeSecurity` will actually fail if called
again after previous activity, so we should guard against multiple invocations
within the same process.
To improve this situation, I'd like to replace the shared `bool` with a typed
enum that can provide finer-grained information as to how far a previous
instance actually managed to get.
Differential Revision: https://phabricator.services.mozilla.com/D121672
This should make the logic around clearing a MessageChannel more obviously
correct by holding the mutex when accessing fields which are traditionally
guarded by the mutex. These lock calls shouldn't introduce performance issues
as the lock should be uncontended.
Differential Revision: https://phabricator.services.mozilla.com/D119354
This state was only used by the ProcessLink MessageLink implementation, and no
longer exists with the new PortLink implementation, so can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D119353
Now that PortLink is the only MessageLink implementation, it is no longer
necessary to support sharing a single `RefCountedMonitor` between multiple
MessageChannels, meaning that we can construct the monitor directly in the
`MessageChannel` constructor. The monitor still needs to be refcounted due to
being used by the PortLink as part of the listener implementation.
Differential Revision: https://phabricator.services.mozilla.com/D119350
This makes things generally more clear, and avoids a long list of initializers
in the MessageChannel constructor. In addition, some fields which are never
modified are marked as `const`.
Differential Revision: https://phabricator.services.mozilla.com/D119349
We will only run the processes in CET compatible modules only mode when not
using the JIT code. So marking xul.dll as compatible should be OK.
Differential Revision: https://phabricator.services.mozilla.com/D117551
We use the process handle returned from `CreateProcess` to derive
another handle with more permissions, but the original handle is never
closed. This bug appears to be fairly old: it existed before this code
was converted to use MozPromise.
Currently we provide the original handle to external consumers of the
launch promise; this patch resolves the promise with the privileged
handle instead and closes the original one. (One consumer uses the
handle only to obtain the pid, and the rest don't use it at all, so this
shouldn't change anything.)
As a related cleanup, `ProcessLaunchPromise` is now exclusive (because
it's resolved with resources which are consumed) and no longer declared
in the header file (because it's used only internally).
Differential Revision: https://phabricator.services.mozilla.com/D119820
After looking through the methods which have this assertion, I couldn't
find any examples of places where not having a specific "link thread"
sequence would cause any issues. I think these assertions can and should
be removed.
The main change required by this was to remove the `!NS_IsMainThread()`
assertion from the SchedulerGroup listener. Due to how callbacks work,
it would be possible for a vsync message to be detected by a
MessageChannel from the main thread if it was sent before the channel
was bound. I don't believe that this change should cause any issues.
Differential Revision: https://phabricator.services.mozilla.com/D119348
This change stores a generated nsID directly on the LoadInfo, rather
than the full SandboxedLoadingPrincipal. This allows for the sandboxed
principal to be constructed from GetChannelResultPrincipal using the
unsandboxed result principal as a precursor, rather than the loading
principal.
The nsID is reset by HttpChannelBase whenever a non-internal redirect
occurs to reduce the chance of multiple null result principals during a
redirect with the same nsID, but different precursors.
Depends on D119692
Differential Revision: https://phabricator.services.mozilla.com/D119693
If GetMainThreadIdleScheduler is called after IPC is destroyed it can
attempt to start it as if it's the first use, which crashes. Instead check
if we've already destroyed the scheduler once and if so then return early.
Differential Revision: https://phabricator.services.mozilla.com/D119251
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
mozilla-central has some imported files of build_config.h from Chromium.
Actually although they doesn't have riscv64 defines yet, I would like to
add it to build Firefox for riscv64.
Differential Revision: https://phabricator.services.mozilla.com/D119051
This patch launches content processes with the `MOZ_HEADLESS` env var set
if they're using GTK with an X11 display (and there's no other reason
they'd need GTK).
The goal is to avoid exhausting Xorg's default limit of 256 clients if
there are many content processes due to Fission. If these conditions
are met, the content process doesn't need to eagerly connect to the X
server. This does not affect the sandbox policy, and content processes
can still use X if needed for, e.g., WebGL.
The boolean pref `dom.ipc.avoid-gtk`, set by default, controls this
feature. In the future it could also be extended to minimize GTK use
with Wayland displays.
Note that disabling `widget.non-native-theme.enabled`, which is also
enabled by default, will restore the use of X11 in all content processes
even if this pref is set; the alternative is that widgets wouldn't render
in that case.
This change will also save some memory for now-unnecessary instances of
GTK's global state, and improve content process startup time.
Remove also the temp pref dom.ipc.remote-mozIcon because it cannot work
anymore with the content process being headless.
Differential Revision: https://phabricator.services.mozilla.com/D112197
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This removes the last form of unique link between two MessageChannels so that
all MessageChannels communicate using PortLink, as it is fairly straightforward
to use PortLink to communicate between two threads in-process.
Differential Revision: https://phabricator.services.mozilla.com/D116672
This adjusts how all actors created using `Endpoint` behave so that they now
use ports instead of creating a unique native channel connection between each
pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D116670
These port attachments are stored directly on the IPC::Message until the
message is ready to be routed to another process, at which point they will be
attached to the port in WillBeRoutedExternally. When the message is then
received on the other side, the ports will be re-extracted from the
UserMessageEvent before it is discarded and re-added to the IPC::Message so
that serializers only need to interact directly with the IPC::Message type.
Differential Revision: https://phabricator.services.mozilla.com/D116669
This is used because, unlike in Mojo, we cannot get from the IPC::Message
object to its enclosing UserMessageEvent object to attach more ports to it, and
this extra parameter makes that easy to do.
Differential Revision: https://phabricator.services.mozilla.com/D116668
This unfortunately requires a new method to be added to BufferList to
support truncating the buffer to a particular iterator.
Differential Revision: https://phabricator.services.mozilla.com/D116666
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
This also consumes the existing channel created when launching a process to
create the the conneciton required by NodeController for communicating between
processes. In part 12b, consumers of the broken APIs will be adjusted to use
the new interface.
The new routing approach is not used for the fork server process, as an IO
thread and the NodeController object cannot be initialized before the fork has
been performed, and the IPC requirements of that process are fairly minimal.
Differential Revision: https://phabricator.services.mozilla.com/D112776
The NodeController and NodeChannel types act as the backbone connecting the
existing IPC logic and driving the ports routing code. Individual NodeChannel
objects wrap and respond to messages from IPC::Channel, and the NodeController
orchestrates all messaging for a process.
The design of these types are inspired by the types with the same names from
Mojo but have been simplified and streamlined to only support features used by
Gecko.
Support for attaching ports or handles to messages hasn't been added yet, but
can be added in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D112775
These will be used to serialize extra event metadata into IPC messages when
they're sent over the ports infrastructure. In the future better integration
may be used to reduce the overhead of this if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D112773
