gecko-dev/toolkit/xre/UntrustedModulesProcessor.h

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

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

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
/* -*- 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_UntrustedModulesProcessor_h
#define mozilla_UntrustedModulesProcessor_h
#include "mozilla/Atomics.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/DebugOnly.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/glue/WindowsDllServices.h"
#include "mozilla/LazyIdleThread.h"
#include "mozilla/Maybe.h"
#include "mozilla/MozPromise.h"
#include "mozilla/RefPtr.h"
#include "mozilla/UntrustedModulesData.h"
#include "mozilla/Vector.h"
#include "mozilla/WinHeaderOnlyUtils.h"
#include "nsCOMPtr.h"
#include "nsIObserver.h"
#include "nsIRunnable.h"
#include "nsISupportsImpl.h"
#include "nsString.h"
namespace mozilla {
class ModuleEvaluator;
using UntrustedModulesPromise =
MozPromise<Maybe<UntrustedModulesData>, nsresult, true>;
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
using ModulesTrustPromise = MozPromise<ModulesMapResult, nsresult, true>;
using GetModulesTrustIpcPromise =
MozPromise<Maybe<ModulesMapResult>, ipc::ResponseRejectReason, 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 UntrustedModulesProcessor final : public nsIObserver {
public:
static RefPtr<UntrustedModulesProcessor> Create();
NS_DECL_THREADSAFE_ISUPPORTS
NS_DECL_NSIOBSERVER
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
// Called by DLL Services to explicitly begin shutting down
void Disable();
// Called by DLL Services to submit module load data to the processor
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 Enqueue(glue::EnhancedModuleLoadInfo&& aModLoadInfo);
void Enqueue(ModuleLoadInfoVec&& aEvents);
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
// Called by telemetry to retrieve the processed data
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> GetProcessedData();
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
// Called by IPC actors in the parent process to evaluate module trust
// on behalf of child processes
RefPtr<ModulesTrustPromise> GetModulesTrust(ModulePaths&& aModPaths,
bool aRunAtNormalPriority);
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
UntrustedModulesProcessor(const UntrustedModulesProcessor&) = delete;
UntrustedModulesProcessor(UntrustedModulesProcessor&&) = delete;
UntrustedModulesProcessor& operator=(const UntrustedModulesProcessor&) =
delete;
UntrustedModulesProcessor& operator=(UntrustedModulesProcessor&&) = delete;
private:
~UntrustedModulesProcessor() = default;
UntrustedModulesProcessor();
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
static bool IsSupportedProcessType();
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 AddObservers();
void RemoveObservers();
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 ScheduleNonEmptyQueueProcessing(const MutexAutoLock& aProofOfLock);
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 CancelScheduledProcessing(const MutexAutoLock& aProofOfLock);
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 DispatchBackgroundProcessing();
void BackgroundProcessModuleLoadQueue();
void ProcessModuleLoadQueue();
using LoadsVec = Vector<glue::EnhancedModuleLoadInfo>;
class ModulesMapResultWithLoads final {
public:
ModulesMapResultWithLoads(Maybe<ModulesMapResult>&& aModMapResult,
LoadsVec&& aLoads)
: mModMapResult(std::move(aModMapResult)), mLoads(std::move(aLoads)) {}
Maybe<ModulesMapResult> mModMapResult;
LoadsVec mLoads;
};
using GetModulesTrustPromise =
MozPromise<Maybe<ModulesMapResultWithLoads>, nsresult, true>;
enum class Priority { Default, Background };
RefPtr<GetModulesTrustPromise> ProcessModuleLoadQueueChildProcess(
Priority aPriority);
void BackgroundProcessModuleLoadQueueChildProcess();
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 AssertRunningOnLazyIdleThread();
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
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> GetProcessedDataInternal();
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<UntrustedModulesPromise> GetProcessedDataInternalChildProcess();
RefPtr<ModulesTrustPromise> GetModulesTrustInternal(
ModulePaths&& aModPaths, bool aRunAtNormalPriority);
RefPtr<ModulesTrustPromise> GetModulesTrustInternal(ModulePaths&& aModPaths);
// These two functions are only called by the parent process
RefPtr<ModuleRecord> GetOrAddModuleRecord(
ModulesMap& aModules, const ModuleEvaluator& aModEval,
const glue::EnhancedModuleLoadInfo& aModLoadInfo);
RefPtr<ModuleRecord> GetOrAddModuleRecord(ModulesMap& aModules,
const ModuleEvaluator& aModEval,
const nsAString& aResolvedNtPath);
// Only called by child processes
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<ModuleRecord> GetModuleRecord(
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
const ModulesMap& aModules,
const glue::EnhancedModuleLoadInfo& aModuleLoadInfo);
RefPtr<GetModulesTrustIpcPromise> SendGetModulesTrust(ModulePaths&& aModules,
Priority aPriority);
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
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 CompleteProcessing(ModulesMapResultWithLoads&& aModulesAndLoads);
RefPtr<UntrustedModulesPromise> GetAllProcessedData(const char* aSource);
private:
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<LazyIdleThread> mThread;
Mutex mUnprocessedMutex;
// The members in this group are protected by mUnprocessedMutex
Vector<glue::EnhancedModuleLoadInfo> mUnprocessedModuleLoads;
nsCOMPtr<nsIRunnable> mIdleRunnable;
// This member must only be touched on mThread
UntrustedModulesData mProcessedModuleLoads;
// This member may be touched by any thread
Atomic<bool> mAllowProcessing;
};
} // namespace mozilla
#endif // mozilla_UntrustedModulesProcessor_h