2019-02-14 18:56:20 +00:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
|
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
|
|
|
|
|
#ifndef mozilla_mscom_ProcessRuntime_h
|
|
|
|
|
#define mozilla_mscom_ProcessRuntime_h
|
|
|
|
|
|
|
|
|
|
#include "mozilla/Attributes.h"
|
|
|
|
|
#include "mozilla/mscom/ApartmentRegion.h"
|
Bug 1707954: Part 1 - Change mscom::ProcessRuntime to ensure MTA creation during startup; r=Jamie
This patch does the following:
* General cleanup:
* More explicit restrictions of how/when the various constructors are available.
* `InitializeSecurity` is made `static`, since it doesn't really manipulate instance variables.
* We move some logic for resolving `CoInitializeEx` flags into `GetDesiredApartmentType`.
* Addition of `PostInit`:
* This doesn't do anything at the moment, but since I'm already making a bunch
of changes, I wanted to add this too. `PostInit` is a static method that
is invoked once the `ProcessRuntime` is finished initializing, and, when
present, the sandbox is fully enabled.
* We call `EnsureMTA`'s default constructor to eagerly bring up the MTA. This
causes all background threads to implicitly become members of the MTA, which
means that we can eliminate `CoInitializeEx` calls throughout our codebase,
since they're slow and most developers do not have a clear understanding of
what those functions actually do.
* This also simplifies the COM initialization in sandboxed content processes
with Win32K lockdown, since if our main thread is in the implicit MTA, we
can immediately initialize ourselves without needing to punt that work
over to the persistent MTA thread.
Differential Revision: https://phabricator.services.mozilla.com/D113560
2021-06-14 21:53:17 +00:00
|
|
|
#include "nsWindowsHelpers.h"
|
|
|
|
|
#if defined(MOZILLA_INTERNAL_API)
|
|
|
|
|
# include "nsXULAppAPI.h"
|
2021-06-17 11:00:22 +00:00
|
|
|
#endif // defined(MOZILLA_INTERNAL_API)
|
2019-02-14 18:56:20 +00:00
|
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
|
namespace mscom {
|
|
|
|
|
|
|
|
|
|
class MOZ_NON_TEMPORARY_CLASS ProcessRuntime final {
|
2019-08-16 16:06:45 +00:00
|
|
|
#if !defined(MOZILLA_INTERNAL_API)
|
|
|
|
|
public:
|
|
|
|
|
#endif // defined(MOZILLA_INTERNAL_API)
|
|
|
|
|
enum class ProcessCategory {
|
|
|
|
|
GeckoBrowserParent,
|
|
|
|
|
// We give Launcher its own process category, but internally to this class
|
|
|
|
|
// it should be treated identically to GeckoBrowserParent.
|
|
|
|
|
Launcher = GeckoBrowserParent,
|
|
|
|
|
GeckoChild,
|
|
|
|
|
Service,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// This constructor is only public when compiled outside of XUL
|
Bug 1707954: Part 1 - Change mscom::ProcessRuntime to ensure MTA creation during startup; r=Jamie
This patch does the following:
* General cleanup:
* More explicit restrictions of how/when the various constructors are available.
* `InitializeSecurity` is made `static`, since it doesn't really manipulate instance variables.
* We move some logic for resolving `CoInitializeEx` flags into `GetDesiredApartmentType`.
* Addition of `PostInit`:
* This doesn't do anything at the moment, but since I'm already making a bunch
of changes, I wanted to add this too. `PostInit` is a static method that
is invoked once the `ProcessRuntime` is finished initializing, and, when
present, the sandbox is fully enabled.
* We call `EnsureMTA`'s default constructor to eagerly bring up the MTA. This
causes all background threads to implicitly become members of the MTA, which
means that we can eliminate `CoInitializeEx` calls throughout our codebase,
since they're slow and most developers do not have a clear understanding of
what those functions actually do.
* This also simplifies the COM initialization in sandboxed content processes
with Win32K lockdown, since if our main thread is in the implicit MTA, we
can immediately initialize ourselves without needing to punt that work
over to the persistent MTA thread.
Differential Revision: https://phabricator.services.mozilla.com/D113560
2021-06-14 21:53:17 +00:00
|
|
|
explicit ProcessRuntime(const ProcessCategory aProcessCategory);
|
2019-08-16 16:06:45 +00:00
|
|
|
|
2019-02-14 18:56:20 +00:00
|
|
|
public:
|
|
|
|
|
#if defined(MOZILLA_INTERNAL_API)
|
Bug 1707954: Part 1 - Change mscom::ProcessRuntime to ensure MTA creation during startup; r=Jamie
This patch does the following:
* General cleanup:
* More explicit restrictions of how/when the various constructors are available.
* `InitializeSecurity` is made `static`, since it doesn't really manipulate instance variables.
* We move some logic for resolving `CoInitializeEx` flags into `GetDesiredApartmentType`.
* Addition of `PostInit`:
* This doesn't do anything at the moment, but since I'm already making a bunch
of changes, I wanted to add this too. `PostInit` is a static method that
is invoked once the `ProcessRuntime` is finished initializing, and, when
present, the sandbox is fully enabled.
* We call `EnsureMTA`'s default constructor to eagerly bring up the MTA. This
causes all background threads to implicitly become members of the MTA, which
means that we can eliminate `CoInitializeEx` calls throughout our codebase,
since they're slow and most developers do not have a clear understanding of
what those functions actually do.
* This also simplifies the COM initialization in sandboxed content processes
with Win32K lockdown, since if our main thread is in the implicit MTA, we
can immediately initialize ourselves without needing to punt that work
over to the persistent MTA thread.
Differential Revision: https://phabricator.services.mozilla.com/D113560
2021-06-14 21:53:17 +00:00
|
|
|
ProcessRuntime();
|
|
|
|
|
~ProcessRuntime();
|
|
|
|
|
#else
|
2021-06-10 06:13:45 +00:00
|
|
|
~ProcessRuntime() = default;
|
Bug 1707954: Part 1 - Change mscom::ProcessRuntime to ensure MTA creation during startup; r=Jamie
This patch does the following:
* General cleanup:
* More explicit restrictions of how/when the various constructors are available.
* `InitializeSecurity` is made `static`, since it doesn't really manipulate instance variables.
* We move some logic for resolving `CoInitializeEx` flags into `GetDesiredApartmentType`.
* Addition of `PostInit`:
* This doesn't do anything at the moment, but since I'm already making a bunch
of changes, I wanted to add this too. `PostInit` is a static method that
is invoked once the `ProcessRuntime` is finished initializing, and, when
present, the sandbox is fully enabled.
* We call `EnsureMTA`'s default constructor to eagerly bring up the MTA. This
causes all background threads to implicitly become members of the MTA, which
means that we can eliminate `CoInitializeEx` calls throughout our codebase,
since they're slow and most developers do not have a clear understanding of
what those functions actually do.
* This also simplifies the COM initialization in sandboxed content processes
with Win32K lockdown, since if our main thread is in the implicit MTA, we
can immediately initialize ourselves without needing to punt that work
over to the persistent MTA thread.
Differential Revision: https://phabricator.services.mozilla.com/D113560
2021-06-14 21:53:17 +00:00
|
|
|
#endif // defined(MOZILLA_INTERNAL_API)
|
2021-06-10 06:13:45 +00:00
|
|
|
|
2019-02-14 18:56:20 +00:00
|
|
|
explicit operator bool() const { return SUCCEEDED(mInitResult); }
|
2019-02-26 21:40:59 +00:00
|
|
|
HRESULT GetHResult() const { return mInitResult; }
|
2019-02-14 18:56:20 +00:00
|
|
|
|
Bug 1707954: Part 1 - Change mscom::ProcessRuntime to ensure MTA creation during startup; r=Jamie
This patch does the following:
* General cleanup:
* More explicit restrictions of how/when the various constructors are available.
* `InitializeSecurity` is made `static`, since it doesn't really manipulate instance variables.
* We move some logic for resolving `CoInitializeEx` flags into `GetDesiredApartmentType`.
* Addition of `PostInit`:
* This doesn't do anything at the moment, but since I'm already making a bunch
of changes, I wanted to add this too. `PostInit` is a static method that
is invoked once the `ProcessRuntime` is finished initializing, and, when
present, the sandbox is fully enabled.
* We call `EnsureMTA`'s default constructor to eagerly bring up the MTA. This
causes all background threads to implicitly become members of the MTA, which
means that we can eliminate `CoInitializeEx` calls throughout our codebase,
since they're slow and most developers do not have a clear understanding of
what those functions actually do.
* This also simplifies the COM initialization in sandboxed content processes
with Win32K lockdown, since if our main thread is in the implicit MTA, we
can immediately initialize ourselves without needing to punt that work
over to the persistent MTA thread.
Differential Revision: https://phabricator.services.mozilla.com/D113560
2021-06-14 21:53:17 +00:00
|
|
|
ProcessRuntime(const ProcessRuntime&) = delete;
|
2019-02-14 18:56:20 +00:00
|
|
|
ProcessRuntime(ProcessRuntime&&) = delete;
|
Bug 1707954: Part 1 - Change mscom::ProcessRuntime to ensure MTA creation during startup; r=Jamie
This patch does the following:
* General cleanup:
* More explicit restrictions of how/when the various constructors are available.
* `InitializeSecurity` is made `static`, since it doesn't really manipulate instance variables.
* We move some logic for resolving `CoInitializeEx` flags into `GetDesiredApartmentType`.
* Addition of `PostInit`:
* This doesn't do anything at the moment, but since I'm already making a bunch
of changes, I wanted to add this too. `PostInit` is a static method that
is invoked once the `ProcessRuntime` is finished initializing, and, when
present, the sandbox is fully enabled.
* We call `EnsureMTA`'s default constructor to eagerly bring up the MTA. This
causes all background threads to implicitly become members of the MTA, which
means that we can eliminate `CoInitializeEx` calls throughout our codebase,
since they're slow and most developers do not have a clear understanding of
what those functions actually do.
* This also simplifies the COM initialization in sandboxed content processes
with Win32K lockdown, since if our main thread is in the implicit MTA, we
can immediately initialize ourselves without needing to punt that work
over to the persistent MTA thread.
Differential Revision: https://phabricator.services.mozilla.com/D113560
2021-06-14 21:53:17 +00:00
|
|
|
ProcessRuntime& operator=(const ProcessRuntime&) = delete;
|
2019-02-14 18:56:20 +00:00
|
|
|
ProcessRuntime& operator=(ProcessRuntime&&) = delete;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @return 0 if call is in-process or resolving the calling thread failed,
|
|
|
|
|
* otherwise contains the thread id of the calling thread.
|
|
|
|
|
*/
|
|
|
|
|
static DWORD GetClientThreadId();
|
|
|
|
|
|
|
|
|
|
private:
|
Bug 1707954: Part 1 - Change mscom::ProcessRuntime to ensure MTA creation during startup; r=Jamie
This patch does the following:
* General cleanup:
* More explicit restrictions of how/when the various constructors are available.
* `InitializeSecurity` is made `static`, since it doesn't really manipulate instance variables.
* We move some logic for resolving `CoInitializeEx` flags into `GetDesiredApartmentType`.
* Addition of `PostInit`:
* This doesn't do anything at the moment, but since I'm already making a bunch
of changes, I wanted to add this too. `PostInit` is a static method that
is invoked once the `ProcessRuntime` is finished initializing, and, when
present, the sandbox is fully enabled.
* We call `EnsureMTA`'s default constructor to eagerly bring up the MTA. This
causes all background threads to implicitly become members of the MTA, which
means that we can eliminate `CoInitializeEx` calls throughout our codebase,
since they're slow and most developers do not have a clear understanding of
what those functions actually do.
* This also simplifies the COM initialization in sandboxed content processes
with Win32K lockdown, since if our main thread is in the implicit MTA, we
can immediately initialize ourselves without needing to punt that work
over to the persistent MTA thread.
Differential Revision: https://phabricator.services.mozilla.com/D113560
2021-06-14 21:53:17 +00:00
|
|
|
#if defined(MOZILLA_INTERNAL_API)
|
|
|
|
|
explicit ProcessRuntime(const GeckoProcessType aProcessType);
|
|
|
|
|
# if defined(MOZ_SANDBOX)
|
|
|
|
|
void InitUsingPersistentMTAThread(const nsAutoHandle& aCurThreadToken);
|
|
|
|
|
# endif // defined(MOZ_SANDBOX)
|
|
|
|
|
#endif // defined(MOZILLA_INTERNAL_API)
|
2019-02-14 18:56:20 +00:00
|
|
|
void InitInsideApartment();
|
|
|
|
|
|
Bug 1707954: Part 1 - Change mscom::ProcessRuntime to ensure MTA creation during startup; r=Jamie
This patch does the following:
* General cleanup:
* More explicit restrictions of how/when the various constructors are available.
* `InitializeSecurity` is made `static`, since it doesn't really manipulate instance variables.
* We move some logic for resolving `CoInitializeEx` flags into `GetDesiredApartmentType`.
* Addition of `PostInit`:
* This doesn't do anything at the moment, but since I'm already making a bunch
of changes, I wanted to add this too. `PostInit` is a static method that
is invoked once the `ProcessRuntime` is finished initializing, and, when
present, the sandbox is fully enabled.
* We call `EnsureMTA`'s default constructor to eagerly bring up the MTA. This
causes all background threads to implicitly become members of the MTA, which
means that we can eliminate `CoInitializeEx` calls throughout our codebase,
since they're slow and most developers do not have a clear understanding of
what those functions actually do.
* This also simplifies the COM initialization in sandboxed content processes
with Win32K lockdown, since if our main thread is in the implicit MTA, we
can immediately initialize ourselves without needing to punt that work
over to the persistent MTA thread.
Differential Revision: https://phabricator.services.mozilla.com/D113560
2021-06-14 21:53:17 +00:00
|
|
|
#if defined(MOZILLA_INTERNAL_API)
|
|
|
|
|
static void PostInit();
|
|
|
|
|
#endif // defined(MOZILLA_INTERNAL_API)
|
|
|
|
|
static HRESULT InitializeSecurity(const ProcessCategory aProcessCategory);
|
|
|
|
|
static COINIT GetDesiredApartmentType(const ProcessCategory aProcessCategory);
|
|
|
|
|
|
|
|
|
|
private:
|
2019-02-14 18:56:20 +00:00
|
|
|
HRESULT mInitResult;
|
2019-08-16 16:06:45 +00:00
|
|
|
const ProcessCategory mProcessCategory;
|
2019-02-14 18:56:20 +00:00
|
|
|
ApartmentRegion mAptRegion;
|
Bug 1707954: Part 1 - Change mscom::ProcessRuntime to ensure MTA creation during startup; r=Jamie
This patch does the following:
* General cleanup:
* More explicit restrictions of how/when the various constructors are available.
* `InitializeSecurity` is made `static`, since it doesn't really manipulate instance variables.
* We move some logic for resolving `CoInitializeEx` flags into `GetDesiredApartmentType`.
* Addition of `PostInit`:
* This doesn't do anything at the moment, but since I'm already making a bunch
of changes, I wanted to add this too. `PostInit` is a static method that
is invoked once the `ProcessRuntime` is finished initializing, and, when
present, the sandbox is fully enabled.
* We call `EnsureMTA`'s default constructor to eagerly bring up the MTA. This
causes all background threads to implicitly become members of the MTA, which
means that we can eliminate `CoInitializeEx` calls throughout our codebase,
since they're slow and most developers do not have a clear understanding of
what those functions actually do.
* This also simplifies the COM initialization in sandboxed content processes
with Win32K lockdown, since if our main thread is in the implicit MTA, we
can immediately initialize ourselves without needing to punt that work
over to the persistent MTA thread.
Differential Revision: https://phabricator.services.mozilla.com/D113560
2021-06-14 21:53:17 +00:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
#if defined(MOZILLA_INTERNAL_API)
|
|
|
|
|
static ProcessRuntime* sInstance;
|
|
|
|
|
#endif // defined(MOZILLA_INTERNAL_API)
|
2019-02-14 18:56:20 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
} // namespace mscom
|
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
|
|
#endif // mozilla_mscom_ProcessRuntime_h
|