AutoVirtualProtect will be useful for following patches. This moves it out of
DllBlocklistWin.cpp and into WinHeaderOnlyUtils.h so it can be shared.
Differential Revision: https://phabricator.services.mozilla.com/D13197
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
Since we don't want to inadvertently expose some way for malware to disable the
launcher via command-line/environment, I opted to query Windows for the PID of
the process that launched us, and then compare its executable path against ours.
Strictly speaking, the PROCESS_BASIC_INFORMATION::InheritedFromUniqueProcessId
field is not necessarily the parent pid, but it will match any process that was
created via the normal CreateProcess machinery.
This version of the blocklist should be functionally comparable to the mozglue
based blocklist, except:
* We hook NtMapViewOfSection instead of LdrLoadDll: The former allows us to
easily obtain the module file name being used for the load. The latter
requires us to essentially emulate the loader's path searching, which is
a perf hit, potentially a correctness issue, and more work to do given the
limited native NT API set.
* Since the paths in native NT land are all unicode, and since this code is
critical to startup performance, this version of the blocklist uses unicode
strings instead of ASCII strings. My thoughts here are that we don't want to
be wasting time on every DLL load doing ASCII-to-unicode conversion every
time we want to do a blocklist string comparison.
* I am completely aware that this leaves us in a bizarre situation where we have
two copies of the blocklist in our binaries: one unicode version in firefox.exe,
and one ASCII version in mozglue.dll. Once we (hopefully) move to using the
launcher process by default, the ASCII copy can go away. In the meantime, we
need to be able to use either one depending on how Firefox was started. I am
happy to make the Native NT blocklist Nightly-only to assuage these concerns.
This version of the blocklist should be functionally comparable to the mozglue
based blocklist, except:
* We hook NtMapViewOfSection instead of LdrLoadDll: The former allows us to
easily obtain the module file name being used for the load. The latter
requires us to essentially emulate the loader's path searching, which is
a perf hit, potentially a correctness issue, and more work to do given the
limited native NT API set.
* Since the paths in native NT land are all unicode, and since this code is
critical to startup performance, this version of the blocklist uses unicode
strings instead of ASCII strings. My thoughts here are that we don't want to
be wasting time on every DLL load doing ASCII-to-unicode conversion every
time we want to do a blocklist string comparison.
* I am completely aware that this leaves us in a bizarre situation where we have
two copies of the blocklist in our binaries: one unicode version in firefox.exe,
and one ASCII version in mozglue.dll. Once we (hopefully) move to using the
launcher process by default, the ASCII copy can go away. In the meantime, we
need to be able to use either one depending on how Firefox was started. I am
happy to make the Native NT blocklist Nightly-only to assuage these concerns.
