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
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
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 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
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
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
This both helps IDE integration and will help avoid build issues which would've
otherwise cropped up when adding new files to the directory for bug 1706374.
Differential Revision: https://phabricator.services.mozilla.com/D112764
Removes Windows NPAPI process sandboxing code, including the code to establish a viable temp directory that was accessible by the sandboxed process.
Differential Revision: https://phabricator.services.mozilla.com/D108688
Removes the mac plugin_interposer (and the related NSCursorInfo behavior), as part of removing all of NPAPI plugin support, since it has no other clients.
Differential Revision: https://phabricator.services.mozilla.com/D107142
Removes Windows NPAPI process sandboxing code, including the code to establish a viable temp directory that was accessible by the sandboxed process.
Differential Revision: https://phabricator.services.mozilla.com/D108688
Removes the mac plugin_interposer (and the related NSCursorInfo behavior), as part of removing all of NPAPI plugin support, since it has no other clients.
Differential Revision: https://phabricator.services.mozilla.com/D107142
The Chromium-derived IPC code was, as far as I can tell, originally
designed for Windows and assumed that channels would be named pipes,
managed and connected to via `std::wstring` paths. The port to Unix,
however, used unnamed `socketpair()` and passed them directly from
process to process, so it has no use for these channel IDs... but it
still computes and propagates them, even though they're not used, using
deprecated wide-string APIs.
This patch introduces a typedef for an abstract channel ID, which is a
`wstring` on Windows and an empty struct on Unix, to allow removing the
string code where it's not needed without needing to completely redesign
the channel abstraction.
Differential Revision: https://phabricator.services.mozilla.com/D72260
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75371
Currently, there is an outstanding issue where enabling the GPU sandbox breaks
scrolling using the the mouse wheel on laptops with Intel GPUs.
This will enable the GPU sandbox on Nightly for non-Intel GPUs to prevent any
sandbox regressions while we try and figure out what the scrolling issue is.
See Bug 1630860 for more info
Differential Revision: https://phabricator.services.mozilla.com/D73923
When the browser process starts a sandbox process, we copy the executable's IAT
for ntdll.dll into the new process to prevent DLL injection via IAT tampering as
the launcher process does. However, if IAT has been modified by a module injected
via `SetWindowHookEx`, the browser process cannot copy IAT because a modified IAT
is invalid in a different process, failing to start any sandbox processes.
The proposed fix is to cache IAT before COM initialization which may load
modules via `SetWindowHookEx` for the first time in the process.
Differential Revision: https://phabricator.services.mozilla.com/D73303
It seems that all the warnings caused by the GPU sandbox have been fixed, and
the transparent window issue was resolved in D61370.
Hopefully there are no further complications and this can stay landed.
Differential Revision: https://phabricator.services.mozilla.com/D18876
When the GPU sandbox is enabled, access to most of the filesystem is blocked.
The GPU process uses a directory, "%profiledir%/shader-cache", to cache
compiled shared for performance reasons. Not allowing access to that directory
results in a HUGE performance backslide when the sandbox is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D67893
Previously, we only called AddTargetPeer() in
GeckoChildProcessHost::PerformAsyncLaunch() if the target process was not
sandboxed.
In the refactoring, the "else" clause was missed due to confusing CPP macros,
and now AddTargetPeer() is always called for non-plugin children.
This patch restores the old behavior of only calling AddTargetPeer() for non-
sandboxed processes.
Differential Revision: https://phabricator.services.mozilla.com/D67136
Remove old content sandbox code paths that allowed the sandbox to be started
later during content process startup when the SetProcessSandbox() message was
received from the parent process. This older way of starting the sandbox was
still in the tree to support WebReplay which is now being removed. With this
fix, content processes always use the "earlyinit" sandbox startup like the
RDD and GMP processes.
Differential Revision: https://phabricator.services.mozilla.com/D64968
