This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
Aaron Klotz
Dorel Luca