gecko-dev/toolkit/xre/WinDllServices.h

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

57 строки
1.6 KiB
C
Исходник Обычный вид История

/* -*- 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/. */
#ifndef mozilla_WinDllServices_h
#define mozilla_WinDllServices_h
#include "mozilla/glue/WindowsDllServices.h"
Bug 1522830: Part 8 - Update UntrustedModulesProcessor to support processing child processes; r=mhowell This patch contains the core changes to make this all work across e10s: * We clarify the naming of path variables to be more specific as to whether they are NT paths or DOS paths; * We add IPC `ParamTraits` that are necessary for `UntrustedModulesData` types; * We implement `ProcessModuleLoadQueue` for child processes. Because of sandboxing, we need to split this sequence into multiple async operations: ** Initial queue processing; ** Sending the list of modules to the parent process to determine trustworthiness (via `GetModulesTrust`); ** Receiving the results from the parent process and producing a final result (via `CompleteProcessing`). * We implement the `GetModulesTrust` function for the parent process, which evaluates the trust of child process modules; * We change all hash tables to be keyed using NT paths. Because resolving DOS paths may not be permitted in sandboxed processes, we need to standardize on NT paths as the "universal path" across processes. * We add `WinDllServices::StartUntrustedModulesProcessor` to separate untrusted modules startup from `WinDllServices` construction: ** While we now start `WinDllServices` across all child process types, only specific process types will support untrusted modules. ** Furthermore, untrusted modules must be started at a very specific point that is dependent on the type of child process. ** We add those calls to `StartUntrustedModulesProcessor` in subsequent patches. Differential Revision: https://phabricator.services.mozilla.com/D53680 --HG-- extra : moz-landing-system : lando
2019-12-07 01:06:26 +03:00
#include "mozilla/Maybe.h"
#include "mozilla/MozPromise.h"
Bug 1542830: Part 6 - Rewrite the untrusted modules processor in toolkit/xre; r=mhowell * Significant cleanup to `ModuleEvaluator` * `UntrustedModuleData` holds all of the accumulated untrusted module info for a single process. * `ProcessedModuleLoadEvent` holds information about an individual untrusted module load in a Gecko-friendly, sanitized, format. * Since multiple `ProcessModuleLoadEvent` objects may reference the same module, we store module metadata in a shared `ModuleInfo` structure. * The `UntrustedModulesProcessor` receives the events from `mozglue` and processes them on a background thread: ** It does not start background processing until the main thread has gone idle. The idea here is that we do not want to add any more background work until we are reasonably confident that Gecko is no longer starting up or doing other intense activity. ** Background processing runs at a background priority level, *except* when results are requested by telemetry itself. ** Telemetry requests the data via `UntrustedModulesProcessor::GetProcessedData` which runs at normal priority and returns a promise to the caller. Depends on D43159 Differential Revision: https://phabricator.services.mozilla.com/D43160 --HG-- rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.cpp rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.h rename : toolkit/xre/ModuleVersionInfo_windows.cpp => toolkit/xre/ModuleVersionInfo.cpp rename : toolkit/xre/ModuleVersionInfo_windows.h => toolkit/xre/ModuleVersionInfo.h rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesData.cpp rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesData.h rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesProcessor.cpp rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesProcessor.h extra : moz-landing-system : lando
2019-09-23 23:19:17 +03:00
#include "mozilla/RefPtr.h"
namespace mozilla {
Bug 1522830: Part 8 - Update UntrustedModulesProcessor to support processing child processes; r=mhowell This patch contains the core changes to make this all work across e10s: * We clarify the naming of path variables to be more specific as to whether they are NT paths or DOS paths; * We add IPC `ParamTraits` that are necessary for `UntrustedModulesData` types; * We implement `ProcessModuleLoadQueue` for child processes. Because of sandboxing, we need to split this sequence into multiple async operations: ** Initial queue processing; ** Sending the list of modules to the parent process to determine trustworthiness (via `GetModulesTrust`); ** Receiving the results from the parent process and producing a final result (via `CompleteProcessing`). * We implement the `GetModulesTrust` function for the parent process, which evaluates the trust of child process modules; * We change all hash tables to be keyed using NT paths. Because resolving DOS paths may not be permitted in sandboxed processes, we need to standardize on NT paths as the "universal path" across processes. * We add `WinDllServices::StartUntrustedModulesProcessor` to separate untrusted modules startup from `WinDllServices` construction: ** While we now start `WinDllServices` across all child process types, only specific process types will support untrusted modules. ** Furthermore, untrusted modules must be started at a very specific point that is dependent on the type of child process. ** We add those calls to `StartUntrustedModulesProcessor` in subsequent patches. Differential Revision: https://phabricator.services.mozilla.com/D53680 --HG-- extra : moz-landing-system : lando
2019-12-07 01:06:26 +03:00
class UntrustedModulesData;
class UntrustedModulesProcessor;
using UntrustedModulesPromise =
MozPromise<Maybe<UntrustedModulesData>, nsresult, true>;
struct ModulePaths;
class ModulesMapResult;
using ModulesTrustPromise = MozPromise<ModulesMapResult, nsresult, true>;
Bug 1542830: Part 6 - Rewrite the untrusted modules processor in toolkit/xre; r=mhowell * Significant cleanup to `ModuleEvaluator` * `UntrustedModuleData` holds all of the accumulated untrusted module info for a single process. * `ProcessedModuleLoadEvent` holds information about an individual untrusted module load in a Gecko-friendly, sanitized, format. * Since multiple `ProcessModuleLoadEvent` objects may reference the same module, we store module metadata in a shared `ModuleInfo` structure. * The `UntrustedModulesProcessor` receives the events from `mozglue` and processes them on a background thread: ** It does not start background processing until the main thread has gone idle. The idea here is that we do not want to add any more background work until we are reasonably confident that Gecko is no longer starting up or doing other intense activity. ** Background processing runs at a background priority level, *except* when results are requested by telemetry itself. ** Telemetry requests the data via `UntrustedModulesProcessor::GetProcessedData` which runs at normal priority and returns a promise to the caller. Depends on D43159 Differential Revision: https://phabricator.services.mozilla.com/D43160 --HG-- rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.cpp rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.h rename : toolkit/xre/ModuleVersionInfo_windows.cpp => toolkit/xre/ModuleVersionInfo.cpp rename : toolkit/xre/ModuleVersionInfo_windows.h => toolkit/xre/ModuleVersionInfo.h rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesData.cpp rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesData.h rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesProcessor.cpp rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesProcessor.h extra : moz-landing-system : lando
2019-09-23 23:19:17 +03:00
class DllServices : public glue::DllServices {
public:
static DllServices* Get();
Bug 1522830: Part 8 - Update UntrustedModulesProcessor to support processing child processes; r=mhowell This patch contains the core changes to make this all work across e10s: * We clarify the naming of path variables to be more specific as to whether they are NT paths or DOS paths; * We add IPC `ParamTraits` that are necessary for `UntrustedModulesData` types; * We implement `ProcessModuleLoadQueue` for child processes. Because of sandboxing, we need to split this sequence into multiple async operations: ** Initial queue processing; ** Sending the list of modules to the parent process to determine trustworthiness (via `GetModulesTrust`); ** Receiving the results from the parent process and producing a final result (via `CompleteProcessing`). * We implement the `GetModulesTrust` function for the parent process, which evaluates the trust of child process modules; * We change all hash tables to be keyed using NT paths. Because resolving DOS paths may not be permitted in sandboxed processes, we need to standardize on NT paths as the "universal path" across processes. * We add `WinDllServices::StartUntrustedModulesProcessor` to separate untrusted modules startup from `WinDllServices` construction: ** While we now start `WinDllServices` across all child process types, only specific process types will support untrusted modules. ** Furthermore, untrusted modules must be started at a very specific point that is dependent on the type of child process. ** We add those calls to `StartUntrustedModulesProcessor` in subsequent patches. Differential Revision: https://phabricator.services.mozilla.com/D53680 --HG-- extra : moz-landing-system : lando
2019-12-07 01:06:26 +03:00
virtual void DisableFull() override;
static const char* kTopicDllLoadedMainThread;
static const char* kTopicDllLoadedNonMainThread;
Bug 1522830: Part 8 - Update UntrustedModulesProcessor to support processing child processes; r=mhowell This patch contains the core changes to make this all work across e10s: * We clarify the naming of path variables to be more specific as to whether they are NT paths or DOS paths; * We add IPC `ParamTraits` that are necessary for `UntrustedModulesData` types; * We implement `ProcessModuleLoadQueue` for child processes. Because of sandboxing, we need to split this sequence into multiple async operations: ** Initial queue processing; ** Sending the list of modules to the parent process to determine trustworthiness (via `GetModulesTrust`); ** Receiving the results from the parent process and producing a final result (via `CompleteProcessing`). * We implement the `GetModulesTrust` function for the parent process, which evaluates the trust of child process modules; * We change all hash tables to be keyed using NT paths. Because resolving DOS paths may not be permitted in sandboxed processes, we need to standardize on NT paths as the "universal path" across processes. * We add `WinDllServices::StartUntrustedModulesProcessor` to separate untrusted modules startup from `WinDllServices` construction: ** While we now start `WinDllServices` across all child process types, only specific process types will support untrusted modules. ** Furthermore, untrusted modules must be started at a very specific point that is dependent on the type of child process. ** We add those calls to `StartUntrustedModulesProcessor` in subsequent patches. Differential Revision: https://phabricator.services.mozilla.com/D53680 --HG-- extra : moz-landing-system : lando
2019-12-07 01:06:26 +03:00
void StartUntrustedModulesProcessor();
Bug 1542830: Part 6 - Rewrite the untrusted modules processor in toolkit/xre; r=mhowell * Significant cleanup to `ModuleEvaluator` * `UntrustedModuleData` holds all of the accumulated untrusted module info for a single process. * `ProcessedModuleLoadEvent` holds information about an individual untrusted module load in a Gecko-friendly, sanitized, format. * Since multiple `ProcessModuleLoadEvent` objects may reference the same module, we store module metadata in a shared `ModuleInfo` structure. * The `UntrustedModulesProcessor` receives the events from `mozglue` and processes them on a background thread: ** It does not start background processing until the main thread has gone idle. The idea here is that we do not want to add any more background work until we are reasonably confident that Gecko is no longer starting up or doing other intense activity. ** Background processing runs at a background priority level, *except* when results are requested by telemetry itself. ** Telemetry requests the data via `UntrustedModulesProcessor::GetProcessedData` which runs at normal priority and returns a promise to the caller. Depends on D43159 Differential Revision: https://phabricator.services.mozilla.com/D43160 --HG-- rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.cpp rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.h rename : toolkit/xre/ModuleVersionInfo_windows.cpp => toolkit/xre/ModuleVersionInfo.cpp rename : toolkit/xre/ModuleVersionInfo_windows.h => toolkit/xre/ModuleVersionInfo.h rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesData.cpp rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesData.h rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesProcessor.cpp rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesProcessor.h extra : moz-landing-system : lando
2019-09-23 23:19:17 +03:00
RefPtr<UntrustedModulesPromise> GetUntrustedModulesData();
Bug 1522830: Part 8 - Update UntrustedModulesProcessor to support processing child processes; r=mhowell This patch contains the core changes to make this all work across e10s: * We clarify the naming of path variables to be more specific as to whether they are NT paths or DOS paths; * We add IPC `ParamTraits` that are necessary for `UntrustedModulesData` types; * We implement `ProcessModuleLoadQueue` for child processes. Because of sandboxing, we need to split this sequence into multiple async operations: ** Initial queue processing; ** Sending the list of modules to the parent process to determine trustworthiness (via `GetModulesTrust`); ** Receiving the results from the parent process and producing a final result (via `CompleteProcessing`). * We implement the `GetModulesTrust` function for the parent process, which evaluates the trust of child process modules; * We change all hash tables to be keyed using NT paths. Because resolving DOS paths may not be permitted in sandboxed processes, we need to standardize on NT paths as the "universal path" across processes. * We add `WinDllServices::StartUntrustedModulesProcessor` to separate untrusted modules startup from `WinDllServices` construction: ** While we now start `WinDllServices` across all child process types, only specific process types will support untrusted modules. ** Furthermore, untrusted modules must be started at a very specific point that is dependent on the type of child process. ** We add those calls to `StartUntrustedModulesProcessor` in subsequent patches. Differential Revision: https://phabricator.services.mozilla.com/D53680 --HG-- extra : moz-landing-system : lando
2019-12-07 01:06:26 +03:00
RefPtr<ModulesTrustPromise> GetModulesTrust(ModulePaths&& aModPaths,
bool aRunAtNormalPriority);
private:
Bug 1522830: Part 8 - Update UntrustedModulesProcessor to support processing child processes; r=mhowell This patch contains the core changes to make this all work across e10s: * We clarify the naming of path variables to be more specific as to whether they are NT paths or DOS paths; * We add IPC `ParamTraits` that are necessary for `UntrustedModulesData` types; * We implement `ProcessModuleLoadQueue` for child processes. Because of sandboxing, we need to split this sequence into multiple async operations: ** Initial queue processing; ** Sending the list of modules to the parent process to determine trustworthiness (via `GetModulesTrust`); ** Receiving the results from the parent process and producing a final result (via `CompleteProcessing`). * We implement the `GetModulesTrust` function for the parent process, which evaluates the trust of child process modules; * We change all hash tables to be keyed using NT paths. Because resolving DOS paths may not be permitted in sandboxed processes, we need to standardize on NT paths as the "universal path" across processes. * We add `WinDllServices::StartUntrustedModulesProcessor` to separate untrusted modules startup from `WinDllServices` construction: ** While we now start `WinDllServices` across all child process types, only specific process types will support untrusted modules. ** Furthermore, untrusted modules must be started at a very specific point that is dependent on the type of child process. ** We add those calls to `StartUntrustedModulesProcessor` in subsequent patches. Differential Revision: https://phabricator.services.mozilla.com/D53680 --HG-- extra : moz-landing-system : lando
2019-12-07 01:06:26 +03:00
DllServices() = default;
~DllServices() = default;
Bug 1542830: Part 6 - Rewrite the untrusted modules processor in toolkit/xre; r=mhowell * Significant cleanup to `ModuleEvaluator` * `UntrustedModuleData` holds all of the accumulated untrusted module info for a single process. * `ProcessedModuleLoadEvent` holds information about an individual untrusted module load in a Gecko-friendly, sanitized, format. * Since multiple `ProcessModuleLoadEvent` objects may reference the same module, we store module metadata in a shared `ModuleInfo` structure. * The `UntrustedModulesProcessor` receives the events from `mozglue` and processes them on a background thread: ** It does not start background processing until the main thread has gone idle. The idea here is that we do not want to add any more background work until we are reasonably confident that Gecko is no longer starting up or doing other intense activity. ** Background processing runs at a background priority level, *except* when results are requested by telemetry itself. ** Telemetry requests the data via `UntrustedModulesProcessor::GetProcessedData` which runs at normal priority and returns a promise to the caller. Depends on D43159 Differential Revision: https://phabricator.services.mozilla.com/D43160 --HG-- rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.cpp rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.h rename : toolkit/xre/ModuleVersionInfo_windows.cpp => toolkit/xre/ModuleVersionInfo.cpp rename : toolkit/xre/ModuleVersionInfo_windows.h => toolkit/xre/ModuleVersionInfo.h rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesData.cpp rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesData.h rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesProcessor.cpp rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesProcessor.h extra : moz-landing-system : lando
2019-09-23 23:19:17 +03:00
void NotifyDllLoad(glue::EnhancedModuleLoadInfo&& aModLoadInfo) override;
void NotifyModuleLoadBacklog(ModuleLoadInfoVec&& aEvents) override;
Bug 1542830: Part 6 - Rewrite the untrusted modules processor in toolkit/xre; r=mhowell * Significant cleanup to `ModuleEvaluator` * `UntrustedModuleData` holds all of the accumulated untrusted module info for a single process. * `ProcessedModuleLoadEvent` holds information about an individual untrusted module load in a Gecko-friendly, sanitized, format. * Since multiple `ProcessModuleLoadEvent` objects may reference the same module, we store module metadata in a shared `ModuleInfo` structure. * The `UntrustedModulesProcessor` receives the events from `mozglue` and processes them on a background thread: ** It does not start background processing until the main thread has gone idle. The idea here is that we do not want to add any more background work until we are reasonably confident that Gecko is no longer starting up or doing other intense activity. ** Background processing runs at a background priority level, *except* when results are requested by telemetry itself. ** Telemetry requests the data via `UntrustedModulesProcessor::GetProcessedData` which runs at normal priority and returns a promise to the caller. Depends on D43159 Differential Revision: https://phabricator.services.mozilla.com/D43160 --HG-- rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.cpp rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.h rename : toolkit/xre/ModuleVersionInfo_windows.cpp => toolkit/xre/ModuleVersionInfo.cpp rename : toolkit/xre/ModuleVersionInfo_windows.h => toolkit/xre/ModuleVersionInfo.h rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesData.cpp rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesData.h rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesProcessor.cpp rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesProcessor.h extra : moz-landing-system : lando
2019-09-23 23:19:17 +03:00
RefPtr<UntrustedModulesProcessor> mUntrustedModulesProcessor;
};
} // namespace mozilla
#endif // mozilla_WinDllServices_h