gecko-dev/browser/app/winlauncher/moz.build

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

56 строки
1.2 KiB
Plaintext
Исходник Обычный вид История

# -*- Mode: python; indent-tabs-mode: nil; tab-width: 40 -*-
# vim: set filetype=python:
# 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 http://mozilla.org/MPL/2.0/.
Library("winlauncher")
FORCE_STATIC_LIB = True
UNIFIED_SOURCES += [
"/ipc/mscom/COMWrappers.cpp",
"/ipc/mscom/ProcessRuntime.cpp",
"/toolkit/xre/WinTokenUtils.cpp",
"/widget/windows/WindowsConsole.cpp",
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
"DllBlocklistInit.cpp",
"ErrorHandler.cpp",
"LauncherProcessWin.cpp",
"LaunchUnelevated.cpp",
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
"NtLoaderAPI.cpp",
]
OS_LIBS += [
"oleaut32",
"ole32",
"rpcrt4",
"version",
]
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
DIRS += [
"freestanding",
]
USE_LIBS += [
"winlauncher-freestanding",
]
TEST_DIRS += [
"test",
]
if CONFIG["MOZ_LAUNCHER_PROCESS"]:
UNIFIED_SOURCES += [
"/toolkit/xre/LauncherRegistryInfo.cpp",
]
for var in ("MOZ_APP_BASENAME", "MOZ_APP_VENDOR", "MOZ_APP_DISPLAYNAME"):
DEFINES[var] = '"%s"' % CONFIG[var]
DisableStlWrapping()
with Files("**"):
BUG_COMPONENT = ("Firefox", "Launcher Process")
REQUIRES_UNIFIED_BUILD = True