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
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
* 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
* 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.
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
* 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.
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
* 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.
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
In order to help unify DLL timings across machines with different performance
characteristics, this change collects the load duration of xul.dll.
Because xul.dll is always loaded, it can serve as a control value for DLL load
times.
Differential Revision: https://phabricator.services.mozilla.com/D16012
--HG--
extra : moz-landing-system : lando
Bug 1435827 part 5/9: Add untrusted DLLs evaluation and processing;r=aklotz
This adds the module trustworthiness calculation code and WinDllServices
handling which prepares data to be consumed by telemetry.
This effectively closes the gap between UntrustedDllsHandler and the upcoming
untrusted modules telemetry ping. At this point nothing is going to invoke most
of this code yet; that comes in following patches that add the untrusted
modules telemetry ping.
Differential Revision: https://phabricator.services.mozilla.com/D6241
--HG--
extra : moz-landing-system : lando
We now record DLL load events along with stack trace and other data so we can
later determine trustworthiness and report the DLL via telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D7175
--HG--
extra : moz-landing-system : lando
Aaron Klotz
shindli
Brindusan Cristian
Ciure Andrei
Andreea Pavel
Carl Corcoran
Sylvestre Ledru
Dorel Luca
Gurzau Raul