Open Bug 1435780 Opened 3 years ago Updated 1 year ago
[Meta] Firefox launcher process
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.
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.
Summary: [Meta] Firefox bootstrap process → [Meta] Firefox launcher process
1 year ago
Component: General → Launcher Process
You need to log in before you can comment on or make changes to this bug.