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
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
Reserve the lower positions of the file descriptors to make sure
we don't reuse stdin/stdout/stderr in case they we closed
before launch.
Differential Revision: https://phabricator.services.mozilla.com/D175337
BCryptGenRandom can be broken, but the Rust stdlib and the getrandom
crate rely on it, and this is a source of crashes which are Rust
panics. This happens the most on Windows 7 after bcryptprimitives.dll
fails to load (see bug 1788004).
To mitigate these crashes, we hook BCryptGenRandom if we detect that it
is broken, and install a fallback based on RtlGenRandom. We only protect
calls that use BCRYPT_USE_SYSTEM_PREFERRED_RNG; so code that relies on
using BCryptOpenAlgorithmProvider and doesn't have its own fallback can
still fail.
We will hopefully remove this hook when the Rust stdlib and the
getrandom crate both have their own RtlGenRandom-based fallback.
Differential Revision: https://phabricator.services.mozilla.com/D170662
As with the socket process, we can't automated test that the block works in the GPU process, but I manually verified this. I did add an automated test that ensures blocking something in the GPU process doesn't block it in other processes.
Differential Revision: https://phabricator.services.mozilla.com/D167399
As with the socket process, we can't automated test that the block works in the GPU process, but I manually verified this. I did add an automated test that ensures blocking something in the GPU process doesn't block it in other processes.
Differential Revision: https://phabricator.services.mozilla.com/D167399
This is a refactoring that makes SharedSection::Reset() do the resolving of Kernel32ExportsSolver. This will allow us in a future patch to let the SharedSection attempt to resolve Kernel32ExportsSolver multiple times, as it will fail if kernel32.dll isn't loaded in the process yet, but we still want to initialize the dynamic blocklist in that case.
Differential Revision: https://phabricator.services.mozilla.com/D164486
This is a refactoring that makes SharedSection::Reset() do the resolving of Kernel32ExportsSolver. This will allow us in a future patch to let the SharedSection attempt to resolve Kernel32ExportsSolver multiple times, as it will fail if kernel32.dll isn't loaded in the process yet, but we still want to initialize the dynamic blocklist in that case.
Differential Revision: https://phabricator.services.mozilla.com/D164486
This is a refactoring that makes SharedSection::Reset() do the resolving of Kernel32ExportsSolver. This will allow us in a future patch to let the SharedSection attempt to resolve Kernel32ExportsSolver multiple times, as it will fail if kernel32.dll isn't loaded in the process yet, but we still want to initialize the dynamic blocklist in that case.
Differential Revision: https://phabricator.services.mozilla.com/D164486
Now that SetGeckoProcessType() is called earlier, we can use that to determine if we are a utility process instead of parsing command-line arguments
Differential Revision: https://phabricator.services.mozilla.com/D158811
Eliminate the need to keep Firefox's required-argument set in sync
across files by defining it only in a new header file.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D152543
`strimatch` attempts to perform a generic case-insensitive match.
However, it doesn't handle edge cases very well -- and, for deep Unicode
reasons, it can't reasonably do so without being far more complicated.
However, we also don't need it to. The `lowerstr` input of `strimatch`
is only ever a constant string naming a command-line option. These are
(and probably always should be) strictly composed of lowercase ASCII,
numerals, and hyphens. _That_ character set is one that a simple
function can properly handle.
Restricting `lowerstr` to be `const char *`, regardless of `CharT`, also
obviates the macro-machinery of `GetLiteral` and `DECLARE_FLAG_LITERAL`.
Strip it all out.
Additionally and relatedly:
* Add tests confirming that `strimatch` only matches things that it
should be testing against at all.
* Add a minor fix for a test which was discovered to crash rather than
report failure.
----
Although this commit involves significant internal functional changes,
most users will see no differences. (Some users operating in Turkish or
Azerbaijani locales may notice that "-PRİVATE-WINDOW" is no longer a
recognized command-line option.)
Differential Revision: https://phabricator.services.mozilla.com/D152321
This means we can include these files in other binaries when we need earlier
access to the process type and use consistent code.
Differential Revision: https://phabricator.services.mozilla.com/D152198
This could be a bit risky to enable in any widespread fashion, but the
goal here is just to land it behind an undocumented command line flag
so that we can do a bit of experimentation and dogfooding. The API
seems to work exactly as desired: firefox opens in the background
without a window or dock icon. Upon trying to launch firefox again, we
simply send a remote command to the existing instance to open a window,
and it does so and gets a dock icon.
Differential Revision: https://phabricator.services.mozilla.com/D126054
This will allow starting Firefox in the background, and on Windows will allow
closing the last browser window without killing the main process. There is no
plan for actually using this by default in Firefox proper, but it's needed for
some explorations.
There's more to this work that we'll need - this is just the first step. For
instance, we'll need a real way to actually kill firefox on Windows other than
through the task manager (we'll be putting something in the system tray to
allow this.)
The patch wasn't particularly large, so I didn't split out the rename of
MOZ_APP_SILENT_START to MOZ_APP_SILENT_RESTART - let me know if you'd like me
to do that though and I can.
Differential Revision: https://phabricator.services.mozilla.com/D124249
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 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
Currently, we set DPI awareness in the manifest files for firefox.exe.
Unfortunately, that causes DPI-related Win32k calls when user32.dll
is loaded.
This changes things to wait until we are sure we're not running in a
Win32k Lockdown Content Process before we attempt to initialize DPI scaling.
Differential Revision: https://phabricator.services.mozilla.com/D116433
Currently, we set DPI awareness in the manifest files for firefox.exe.
Unfortunately, that causes DPI-related Win32k calls when user32.dll
is loaded.
This changes things to wait until we are sure we're not running in a
Win32k Lockdown Content Process before we attempt to initialize DPI scaling.
Differential Revision: https://phabricator.services.mozilla.com/D116433
Currently, we set DPI awareness in the manifest files for firefox.exe.
Unfortunately, that causes DPI-related Win32k calls when user32.dll
is loaded.
This changes things to wait until we are sure we're not running in a
Win32k Lockdown Content Process before we attempt to initialize DPI scaling.
Differential Revision: https://phabricator.services.mozilla.com/D116433
We know that some GV installations (particularly but not exlcusively Focus) are
failing to load `libxul.so` during early Gecko bootstrapping. Unfortunately
a boolean pass/fail result is not giving us sufficient information to be able to
properly troubleshoot this problem.
This patch adds `mozilla::Result`-based return values to `XPCOMGlueLoad` and
`GetBootstrap` in an effort to produce more actionable information about these
failures.
We include either a `nsresult` or, if the failure is rooted in a dynamic linker
failure, appropriate platform-specific error information:
* On Unix-based platforms, a `UniqueFreePtr<char>` containing the string from `dlerror(3)`;
* On Windows, the Win32 `DWORD` error code from `GetLastError()`.
For non-Android platforms, I updated them to handle the new return type, but
otherwise did not make any further changes.
For Android, we include the error information in the message string that we pass
into the Java `Exception` that is subsequently thrown.
Differential Revision: https://phabricator.services.mozilla.com/D104263
This patch is to improve the way to detect an injected dependent module for
automatic DLL blocking (bug 1659438).
In the previous version, we created a list of dependent modules in the launcher
process and shared it with other processes via the shared section. However, it
was not compatible with third-party applications who tamper the Import Table and
revert it in the injected module's DllMain (bug 1682834) because we parsed the
Import Table in the launcher process after it was reverted.
With this patch, we check the Import Table in `patched_NtMapViewOfSection`,
so we can see tampering before it's reverted. More specifically, we create
a list of dependent modules in the browser process as below.
1. The launcher process creates a section object and initializes
the kernel32.dll's functions in it.
2. The launcher process transfers a writable handle of the shared
section to the browser process.
3. In the browser process, if an injected dependent module is being
mapped by `NtMapViewOfSection`, we add its NT path to the shared
section and block it with `REDIRECT_TO_NOOP_ENTRYPOINT`.
4. The `main` function of the browser process converts the writable
handle of the shared section into a readonly handle.
5. The browser process transfers a readonly handle of the shared
section to a sandbox process.
Since automatic DLL blocking may still cause a compat issue like bug 1682304,
we activate it only in Nightly for now.
Differential Revision: https://phabricator.services.mozilla.com/D101460
