mozilla
/
gecko-dev
зеркало из https://github.com/mozilla/gecko-dev.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
gecko-dev/mozglue/dllservices/NtLoaderAPI.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

24 строки
717 B
C
Исходник Обычный вид История

Bug 1445025: Part 5 - Implement a Native NT version of the DLL blocklist; r=mhowell 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.
2018-06-06 00:21:19 +03:00
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at https://mozilla.org/MPL/2.0/. */
Bug 1542830: Part 2 - Modify launcher process blocklist to collect information about untrusted module loads; r=mhowell * 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 --HG-- rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/DllBlocklistInit.cpp rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/DllBlocklistInit.h rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/freestanding/DllBlocklist.cpp rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/freestanding/DllBlocklist.h rename : browser/app/winlauncher/moz.build => browser/app/winlauncher/freestanding/moz.build extra : moz-landing-system : lando
2019-09-23 23:17:10 +03:00
#ifndef mozilla_NtLoaderAPI_h
#define mozilla_NtLoaderAPI_h
Bug 1445025: Part 5 - Implement a Native NT version of the DLL blocklist; r=mhowell 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.
2018-06-06 00:21:19 +03:00
Bug 1542830: Part 2 - Modify launcher process blocklist to collect information about untrusted module loads; r=mhowell * 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 --HG-- rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/DllBlocklistInit.cpp rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/DllBlocklistInit.h rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/freestanding/DllBlocklist.cpp rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/freestanding/DllBlocklist.h rename : browser/app/winlauncher/moz.build => browser/app/winlauncher/freestanding/moz.build extra : moz-landing-system : lando
2019-09-23 23:17:10 +03:00
#include "mozilla/LoaderAPIInterfaces.h"
Bug 1445025: Part 5 - Implement a Native NT version of the DLL blocklist; r=mhowell 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.
2018-06-06 00:21:19 +03:00
Bug 1542830: Part 2 - Modify launcher process blocklist to collect information about untrusted module loads; r=mhowell * 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 --HG-- rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/DllBlocklistInit.cpp rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/DllBlocklistInit.h rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/freestanding/DllBlocklist.cpp rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/freestanding/DllBlocklist.h rename : browser/app/winlauncher/moz.build => browser/app/winlauncher/freestanding/moz.build extra : moz-landing-system : lando
2019-09-23 23:17:10 +03:00
#if !defined(IMPL_MFBT)
# error "This should only be included from mozglue!"
#endif // !defined(IMPL_MFBT)
Bug 1508468: Convert launcher process to use mozilla::Result for error propagation; r=mhowell 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 --HG-- extra : moz-landing-system : lando
2018-11-21 02:49:36 +03:00
Bug 1445025: Part 5 - Implement a Native NT version of the DLL blocklist; r=mhowell 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.
2018-06-06 00:21:19 +03:00
namespace mozilla {
Bug 1542830: Part 2 - Modify launcher process blocklist to collect information about untrusted module loads; r=mhowell * 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 --HG-- rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/DllBlocklistInit.cpp rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/DllBlocklistInit.h rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/freestanding/DllBlocklist.cpp rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/freestanding/DllBlocklist.h rename : browser/app/winlauncher/moz.build => browser/app/winlauncher/freestanding/moz.build extra : moz-landing-system : lando
2019-09-23 23:17:10 +03:00
extern "C" MOZ_IMPORT_API nt::LoaderAPI* GetNtLoaderAPI(
nt::LoaderObserver* aNewObserver);
Bug 1445025: Part 5 - Implement a Native NT version of the DLL blocklist; r=mhowell 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.
2018-06-06 00:21:19 +03:00
} // namespace mozilla
Bug 1542830: Part 2 - Modify launcher process blocklist to collect information about untrusted module loads; r=mhowell * 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 --HG-- rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/DllBlocklistInit.cpp rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/DllBlocklistInit.h rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/freestanding/DllBlocklist.cpp rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/freestanding/DllBlocklist.h rename : browser/app/winlauncher/moz.build => browser/app/winlauncher/freestanding/moz.build extra : moz-landing-system : lando
2019-09-23 23:17:10 +03:00
#endif // mozilla_NtLoaderAPI_h