1435780 - [Meta] Firefox launcher process

Status: NEW

(Firefox :: Launcher Process, enhancement)

Description

[(No longer employed by Mozilla) Aaron Klotz]

Initially we need to treat this as a prototype to determine performance implications.

The idea is to modify firefox.exe such that its initial invocation is a bootstrap process that creates the "real" browser process in such a way that its injection blocking capabilities are readied before the browser's main thread ever starts.

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

Some details on things that I want to see from this process:

1. It must pass its environment and command line through to the browser process verbatim (exception: strip out --bootstrap if we go that route (see item 5)).
2. It must provide a process/thread attribute list when creating the browser process, such that we can supply a list of OS-level mitigations to be enabled.
3. It must initially create the browser process in a suspended state, then provide a way to invoke any post-creation initialization on that child process (passing in the new hProcess and hThread so that we can manipulate the child). Once that initialization code has run, we must then resume the initial thread.
4. We should strive to make this as lightweight as possible: let's avoid loading and/or initializing anything that we don't absolutely need.
4a. (This is a follow-up requirement if our initial implementation is costly): We may need to make changes to the existing firefox.exe implementation to further reduce the cost. eg move to run-time dynamic linking of firefox.exe dependencies, readahead, etc.
5. Since we are prototyping, I propose that we make a configure setting to determine whether or not the bootstrap process should be enabled by default. If not by default, we should have some kind of command line switch (--bootstrap or something) to enable our code path.
6. It must have awareness of whether or not we are launching in safe mode.