If the process was elevated due to AppCompatFlags, we should not
use LaunchUnelevated to launch the browser process because it starts
an infinite loop of process launch.
The fix is to make GetElevationState return a new elevation state
if RUNASADMIN is set in AppCompatFlags. With that state, we use
CreateProcessAsUser to launch the browser process.
Differential Revision: https://phabricator.services.mozilla.com/D80114
Bug 1522830 added the call to `InitializeDllBlocklistOOP` in `SandboxBroker::LaunchApp`
to enable the new dll blocklist and telemetry in sandbox processes. If the browser
process fails to bootstrap a process for some reason, firefox starts without any crash
nor any content processes because of that change.
What is worse is that this problem persists even after the launcher process was disabled.
To mitigate it, this patch stops an attempt to bootstrap a child process if the launcher
process already failed to do it. With this, if something bad happens in the first launch,
the launcher process is automatically disabled via registry and next time firefox will work
normally. So a user will see the launching problem only once.
We will follow up the bootstrap issue.
Differential Revision: https://phabricator.services.mozilla.com/D62636
We have the `LauncherRegistryInfo` class to check the launcher process was
launched successfully on Windows by comparing the timestamps in the registry
when each process was launched.
The problem was when the process is launched from an elevated process, we
relaunch a new launcher process via shell after we updated the launcher's
timestamp. As a result, `LauncherRegistryInfo` unexpectedly disabled the
launcher process even though there was nothing wrong.
A proposed fix is to introduce delay-write to the `LauncherRegistryInfo`. With
this, `LauncherRegistryInfo::Check` modifies only the image timestamp. To update
the launcher/browser timestamps, we need to call `LauncherRegistryInfo::Commit`.
When we ask shell to relaunch a new process, we hold back commit, delegating it
to the new process.
There is another consideration needed. If something fails during `LauncherMain`,
we call `DisableDueToFailure()` to disable the launcher until the image timestamp
is changed. In such a case, we should not change the stored timestamps even
though commit is attempted. The problem is we use a different instance to call
`DisableDueToFailure()` in `HandleLauncherError`. To deal with this design,
`LauncherRegistryInfo` has a static boolean to indicate disablement happens or not.
Differential Revision: https://phabricator.services.mozilla.com/D44928
* We refactor the blocklist code. Code that may possibly run before
initialization of the Win32 subsystem and the CRT is contained within the
`freestanding` library.
* The `freestanding` library's static initializers are placed in their own
section so that they may be manually invoked separately from the remaining
initializers in the binary.
* `CheckBlockInfo` and `IsDllAllowed` are modified to return a `BlockAction`
enum instead of a `bool`. This will be used more extensively in the future for
LSP blocking.
* The launcher process now hooks `LdrLoadDll` in addition to
`NtMapViewOfSection`. This is necessary so that we can collect timing
information.
* Telemetry recorders must implement the `LoaderObserver` interface.
* `ModuleLoadFrame` is a RAII class that collects the information about the
DLL load and dispatches the information to `LoaderObserver`s.
* The launcher process exposes an implementation of the `LoaderAPI` interface
that may be called by either the launcher process blocklist or the legacy
blocklist in `mozglue`.
* During startup, the launcher process implements its own `LoaderObserver`.
Once mozglue is running, it connects its `LoaderObserver` to the launcher
process, receives a vector containing the module load events, and then
stores and forwards them into XUL.
Depends on D43155
Differential Revision: https://phabricator.services.mozilla.com/D43156
We compare two file ids to check the current process is launched from the same
executable. However, our telemetry showed a number of Win7 users failed to open
a file handle of the parent process with STATUS_OBJECT_PATH_NOT_FOUND even
though we opened a process handle and retrieved a module path of the parent
process successfully. We don't have data to explain how this happens or why
this happens only on Win7, Win10 10240, and 10586.
To mitigate this situation, this patch introduces a logic to compare NT path
strings. The benefit from doing this is 1) we don't have to open a file handle
of a parent process executable and 2) when we get an NT path, a network drive
or a symbolic link is already solved.
This new logic is much faster, but we still compare file ids on the first
attempt to minimize the impact. We fall back to the new logic only if we
detect the STATUS_OBJECT_PATH_NOT_FOUND failure.
Differential Revision: https://phabricator.services.mozilla.com/D45476
* We refactor the blocklist code. Code that may possibly run before
initialization of the Win32 subsystem and the CRT is contained within the
`freestanding` library.
* The `freestanding` library's static initializers are placed in their own
section so that they may be manually invoked separately from the remaining
initializers in the binary.
* `CheckBlockInfo` and `IsDllAllowed` are modified to return a `BlockAction`
enum instead of a `bool`. This will be used more extensively in the future for
LSP blocking.
* The launcher process now hooks `LdrLoadDll` in addition to
`NtMapViewOfSection`. This is necessary so that we can collect timing
information.
* Telemetry recorders must implement the `LoaderObserver` interface.
* `ModuleLoadFrame` is a RAII class that collects the information about the
DLL load and dispatches the information to `LoaderObserver`s.
* The launcher process exposes an implementation of the `LoaderAPI` interface
that may be called by either the launcher process blocklist or the legacy
blocklist in `mozglue`.
* During startup, the launcher process implements its own `LoaderObserver`.
Once mozglue is running, it connects its `LoaderObserver` to the launcher
process, receives a vector containing the module load events, and then
stores and forwards them into XUL.
Differential Revision: https://phabricator.services.mozilla.com/D43156
* We refactor the blocklist code. Code that may possibly run before
initialization of the Win32 subsystem and the CRT is contained within the
`freestanding` library.
* The `freestanding` library's static initializers are placed in their own
section so that they may be manually invoked separately from the remaining
initializers in the binary.
* `CheckBlockInfo` and `IsDllAllowed` are modified to return a `BlockAction`
enum instead of a `bool`. This will be used more extensively in the future for
LSP blocking.
* The launcher process now hooks `LdrLoadDll` in addition to
`NtMapViewOfSection`. This is necessary so that we can collect timing
information.
* Telemetry recorders must implement the `LoaderObserver` interface.
* `ModuleLoadFrame` is a RAII class that collects the information about the
DLL load and dispatches the information to `LoaderObserver`s.
* The launcher process exposes an implementation of the `LoaderAPI` interface
that may be called by either the launcher process blocklist or the legacy
blocklist in `mozglue`.
* During startup, the launcher process implements its own `LoaderObserver`.
Once mozglue is running, it connects its `LoaderObserver` to the launcher
process, receives a vector containing the module load events, and then
stores and forwards them into XUL.
Differential Revision: https://phabricator.services.mozilla.com/D43156
* We refactor the blocklist code. Code that may possibly run before
initialization of the Win32 subsystem and the CRT is contained within the
`freestanding` library.
* The `freestanding` library's static initializers are placed in their own
section so that they may be manually invoked separately from the remaining
initializers in the binary.
* `CheckBlockInfo` and `IsDllAllowed` are modified to return a `BlockAction`
enum instead of a `bool`. This will be used more extensively in the future for
LSP blocking.
* The launcher process now hooks `LdrLoadDll` in addition to
`NtMapViewOfSection`. This is necessary so that we can collect timing
information.
* Telemetry recorders must implement the `LoaderObserver` interface.
* `ModuleLoadFrame` is a RAII class that collects the information about the
DLL load and dispatches the information to `LoaderObserver`s.
* The launcher process exposes an implementation of the `LoaderAPI` interface
that may be called by either the launcher process blocklist or the legacy
blocklist in `mozglue`.
* During startup, the launcher process implements its own `LoaderObserver`.
Once mozglue is running, it connects its `LoaderObserver` to the launcher
process, receives a vector containing the module load events, and then
stores and forwards them into XUL.
Differential Revision: https://phabricator.services.mozilla.com/D43156
`WindowsErrorResult` is a class to hold either a value or a Windows error
code based on the `Result` template. We also have `LauncherResult` for the
same purpose, which was introduced as a part of the launcher process feature
afterward. The difference is `LauncherResult` holds a filename and line
number along with an error code.
This patch integrates LauncherResult.h into WinHeaderOnlyUtils.h so that we
can use `LauncherResult` more broadly.
Differential Revision: https://phabricator.services.mozilla.com/D44512
There's a bug in ole32.dll on arm64 versions of Windows prior to 1809, that crashes our content processes if we enable CFG. We've reported the issue, but even if it gets fixed, we can't assume users will have the update.
This patch uses process mitigation policy flags to disable CFG on arm64 before 1809. Based on testing, we only need to do this in the sandbox for child processes, and it's not strictly necessary for the launcher stub to set the flag on the main process. But I've included that anyway as a guard against some yet-undiscovered scenario that might hit the issue and make the browser unusable.
The effects of this patch won't be visible until we actually enable CFG in a subsequent landing.
Differential Revision: https://phabricator.services.mozilla.com/D29474
There's a bug in ole32.dll on arm64 versions of Windows prior to 1809, that crashes our content processes if we enable CFG. We've reported the issue, but even if it gets fixed, we can't assume users will have the update.
This patch uses process mitigation policy flags to disable CFG on arm64 before 1809. Based on testing, we only need to do this in the sandbox for child processes, and it's not strictly necessary for the launcher stub to set the flag on the main process. But I've included that anyway as a guard against some yet-undiscovered scenario that might hit the issue and make the browser unusable.
The effects of this patch won't be visible until we actually enable CFG in a subsequent landing.
Differential Revision: https://phabricator.services.mozilla.com/D29474
This patch replaces the quick-n-dirty implementation of -force-launcher with
one that makes LauncherRegistryInfo aware of that state, thus correctly setting
the affected registry values.
Differential Revision: https://phabricator.services.mozilla.com/D29545
In the tree we have two copies of printf_stderr() with the comment,
"Ideally this should be shared". This moves the function to a new exported
header which can be the basis for other similar debugging utility functions.
To include it,
#include "mozilla/glue/Debug.h"
A small concern with this is that printf_stderr() is in the global namespace,
and could conflict if it's inadvertently included along with, for example,
nsDebug.h which also defines this function. The warning in the comment at the
top of the file attempts to mitigate this.
Differential Revision: https://phabricator.services.mozilla.com/D13196
This patch does a few things:
* Fleshes out the launcher process failure ping;
* Sends that ping via pingsender;
* If there is any failure in doing so, we fall back to the Windows event log;
* Any launcher process failures will result in us falling back to the normal
startup code path, ensuring that users will still see a browser.
A sample ping will be attached to the bug.
Differential Revision: https://phabricator.services.mozilla.com/D19697
This patch does a few things:
* Fleshes out the launcher process failure ping;
* Sends that ping via pingsender;
* If there is any failure in doing so, we fall back to the Windows event log;
* Any launcher process failures will result in us falling back to the normal
startup code path, ensuring that users will still see a browser.
A sample ping will be attached to the bug.
***
Format cleanup
Differential Revision: https://phabricator.services.mozilla.com/D19697
