Bugzilla

Currently the untrusted modules ping is hooked in via the legacy blocklist code in `mozglue`. This means that the ping currently misses any DLL loads that take place between process creation and legacy blocklist initialization.

We should move the gathering of untrusted modules telemetry into the launcher process.

* Currently the launcher process hooks `NtMapViewOfSection` for DLL blocking, as this allows us to give the loader a chance to resolve the effective path of the binary being loaded. This gives us a perf optimization over the legacy implementation, where we were effectively doing 2 path searches (our own, plus the loader's). We want to leave this as-is.

* OTOH, we need to use `LdrLoadDll` as the hook if we want to be able to take any timing measurements for untrusted modules telemetry, so we should add this as a second hook that is set via the launcher process.

A couple of things to keep in mind:
* We need a way for Gecko to retrieve the untrusted module info from the launcher process without opening up any avenues for third-party tampering;
* I eventually want to remove the legacy blocklist code, so at the very least we'll want to rough-in the capability to do all of the profiler stuff that the existing `LdrLoadDll` hook can do, such that the profiler can register itself somehow during startup and allow us to suspend stackwalking, record markers, and so forth.

One other question that I've been thinking about is wondering how much of this needs to be bare-metal C++ with NTDLL, and how much of this can be more complicated. eg should we add tracking code in our loader hooks to determine when `kernel32` and the CRT are loaded, such that we can then delegate to higher-level code once we have the capability? Or do we just create a profiler interface that can be registered from elsewhere and, once registered, we just fire off events into the ether?

Anyway, lots to think about here, and I'll leave it in your capable hands!

Currently the untrusted modules ping is hooked in via the legacy blocklist code in `mozglue`. This means that the ping currently misses any DLL loads that take place between process creation and legacy blocklist initialization.

We should move the gathering of untrusted modules telemetry into the launcher process.

* Currently the launcher process hooks `NtMapViewOfSection` for DLL blocking, as this allows us to give the loader a chance to resolve the effective path of the binary being loaded. This gives us a perf optimization over the legacy implementation, where we were effectively doing 2 path searches (our own, plus the loader's). We want to leave this as-is.

* OTOH, we need to use `LdrLoadDll` as the hook if we want to be able to take any timing measurements for untrusted modules telemetry, so we should add this as a second hook that is set via the launcher process.

A couple of things to keep in mind:
* We need a way for Gecko to retrieve the untrusted module info from the new hook without opening up any avenues for third-party tampering;
* I eventually want to remove the legacy blocklist code, so at the very least we'll want to rough-in the capability to do all of the profiler stuff that the existing `LdrLoadDll` hook can do, such that the profiler can register itself somehow during startup and allow us to suspend stackwalking, record markers, and so forth.

One other question that I've been thinking about is wondering how much of this needs to be bare-metal C++ with NTDLL, and how much of this can be more complicated. eg should we add tracking code in our loader hooks to determine when `kernel32` and the CRT are loaded, such that we can then delegate to higher-level code once we have the capability? Or do we just create a profiler interface that can be registered from elsewhere and, once registered, we just fire off events into the ether?

Anyway, lots to think about here, and I'll leave it in your capable hands!

Currently the untrusted modules ping is hooked in via the legacy blocklist code in `mozglue`. This means that the ping currently misses any DLL loads that take place between process creation and legacy blocklist initialization.

We should move the gathering of untrusted modules telemetry into hooks set by launcher process, so that we can collect data during process startup.

* Currently the launcher process hooks `NtMapViewOfSection` for DLL blocking, as this allows us to give the loader a chance to resolve the effective path of the binary being loaded. This gives us a perf optimization over the legacy implementation, where we were effectively doing 2 path searches (our own, plus the loader's). We want to leave this as-is.

* OTOH, we need to use `LdrLoadDll` as the hook if we want to be able to take any timing measurements for untrusted modules telemetry, so we should add this as a second hook that is set via the launcher process.

A couple of things to keep in mind:
* We need a way for Gecko to retrieve the untrusted module info from the new hook without opening up any avenues for third-party tampering;
* I eventually want to remove the legacy blocklist code, so at the very least we'll want to rough-in the capability to do all of the profiler stuff that the existing `LdrLoadDll` hook can do, such that the profiler can register itself somehow during startup and allow us to suspend stackwalking, record markers, and so forth.

One other question that I've been thinking about is wondering how much of this needs to be bare-metal C++ with NTDLL, and how much of this can be more complicated. eg should we add tracking code in our loader hooks to determine when `kernel32` and the CRT are loaded, such that we can then delegate to higher-level code once we have the capability? Or do we just create a profiler interface that can be registered from elsewhere and, once registered, we just fire off events into the ether?

Anyway, lots to think about here, and I'll leave it in your capable hands!

Currently the untrusted modules ping is hooked in via the legacy blocklist code in `mozglue`. This means that the ping currently misses any DLL loads that take place between process creation and legacy blocklist initialization.

We should move the gathering of untrusted modules telemetry into hooks set by launcher process, so that we can collect data during process startup.

* Currently the launcher process hooks `NtMapViewOfSection` for DLL blocking, as this allows us to give the loader a chance to resolve the effective path of the binary being loaded. This gives us a perf optimization over the legacy implementation, where we were effectively doing 2 path searches (our own, plus the loader's). We want to leave this as-is.

* OTOH, we need to use `LdrLoadDll` as the hook if we want to be able to take any timing measurements for untrusted modules telemetry, so we should add this as a second hook that is set via the launcher process.

A couple of things to keep in mind:
* We need a way for Gecko to retrieve the untrusted module info from the new hook without opening up any avenues for third-party tampering;
* I eventually want to remove the legacy blocklist code, so at the very least we'll want to rough-in the capability to do all of the profiler stuff that the existing `LdrLoadDll` hook can do, such that the profiler can register itself somehow during startup and allow us to suspend stackwalking, record markers, and so forth.

One other question that I've been thinking about is wondering how much of this needs to be bare-metal C++ with NTDLL, and how much of this can be more complicated. eg should we add tracking code in our loader hooks to determine when `kernel32` and the CRT are loaded, such that we can then delegate to higher-level code once we have the capability? Or do we just create a profiler interface that can be registered from elsewhere and, once registered (presumably late enough in the process lifetime that we have a full runtime), we just fire off events into the ether?

Anyway, lots to think about here, and I'll leave it in your capable hands!

Currently the untrusted modules ping is hooked in via the legacy blocklist code in `mozglue`. This means that the ping currently misses any DLL loads that take place between process creation and legacy blocklist initialization.

We should move the gathering of untrusted modules telemetry into hooks set by launcher process, so that we can collect data during process startup.

* Currently the launcher process hooks `NtMapViewOfSection` for DLL blocking, as this allows us to give the loader a chance to resolve the effective path of the binary being loaded. This gives us a perf optimization over the legacy implementation, where we were effectively doing 2 path searches for each DLL load (our own, plus the loader's). We want to leave this as-is.

* OTOH, we need to use `LdrLoadDll` as the hook if we want to be able to take any timing measurements for untrusted modules telemetry, so we should add this as a second hook that is set via the launcher process.

A couple of things to keep in mind:
* We need a way for Gecko to retrieve the untrusted module info from the new hook without opening up any avenues for third-party tampering;
* I eventually want to remove the legacy blocklist code, so at the very least we'll want to rough-in the capability to do all of the profiler stuff that the existing `LdrLoadDll` hook can do, such that the profiler can register itself somehow during startup and allow us to suspend stackwalking, record markers, and so forth.

One other question that I've been thinking about is wondering how much of this needs to be bare-metal C++ with NTDLL, and how much of this can be more complicated. eg should we add tracking code in our loader hooks to determine when `kernel32` and the CRT are loaded, such that we can then delegate to higher-level code once we have the capability? Or do we just create a profiler interface that can be registered from elsewhere and, once registered (presumably late enough in the process lifetime that we have a full runtime), we just fire off events into the ether?

Anyway, lots to think about here, and I'll leave it in your capable hands!