Граф коммитов

32 Коммитов

Автор SHA1 Сообщение Дата
Bob Owen 647c996376 Bug 1755979: Pass accessibilty resource ID down from the parent. r=Jamie,nika
This is being done because the way the ID is determined causes issue with the
sandbox and the ID is required very early in process start up.

Differential Revision: https://phabricator.services.mozilla.com/D139649
2022-03-02 11:06:33 +00:00
Marian-Vasile Laza 9b19135d0c Backed out changeset 540d7dd134db (bug 1755979) for causing xpcshell failures on ContentParent.cpp. CLOSED TREE 2022-02-28 11:56:41 -08:00
Bob Owen 2ccbc7a61d Bug 1755979: Pass accessibilty resource ID down from the parent. r=Jamie,nika
This is being done because the way the ID is determined causes issue with the
sandbox and the ID is required very early in process start up.

Differential Revision: https://phabricator.services.mozilla.com/D139649
2022-02-28 17:31:57 +00:00
Andi-Bogdan Postelnicu 2fc4f70e9b Bug 1725145 - Preparation for the hybrid build env. r=necko-reviewers,firefox-build-system-reviewers,valentin,glandium
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.

This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.

Differential Revision: https://phabricator.services.mozilla.com/D122345
2021-08-25 10:46:17 +00:00
Aaron Klotz 5df7df28c5 Bug 1723837: Improve mscom::ProcessRuntime idempotency; r=Jamie,handyman
`mscom::ProcessRuntime` supports multiple instances because Reasons (TM).
To make this happen, we store some information in `mozglue` that enforces
serialization between instances and also informs an instance as to whether
any other instances have successfully completed initialization.

Unfortunately it is possible for us to encounter situations where one instance
manages to *partially* but not *completely* finish initialization. Since our
shared information is currently a simple `bool`, we cannot really capture this
case.

Furthermore, APIs such as `CoInitializeSecurity` will actually fail if called
again after previous activity, so we should guard against multiple invocations
within the same process.

To improve this situation, I'd like to replace the shared `bool` with a typed
enum that can provide finer-grained information as to how far a previous
instance actually managed to get.

Differential Revision: https://phabricator.services.mozilla.com/D121672
2021-08-04 18:02:30 +00:00
Doug Thayer b5f7314e3e Bug 1714212 - Ensure COM initialized prior to showing skeleton UI r=Jamie,aklotz,tkikuchi
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.

Differential Revision: https://phabricator.services.mozilla.com/D117663
2021-07-07 22:37:14 +00:00
Narcis Beleuzu 1ff027d763 Backed out changeset acf2d74efbbc (bug 1714212) for SM bustages on NativeNt.h 2021-07-07 23:13:42 +03:00
Doug Thayer dc9c284076 Bug 1714212 - Ensure COM initialized prior to showing skeleton UI r=Jamie,aklotz,tkikuchi
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.

Differential Revision: https://phabricator.services.mozilla.com/D117663
2021-07-07 18:17:36 +00:00
Dorel Luca bc6f2486e2 Backed out changeset 11d1710e481f (bug 1714212) for Browser-chrome failures in toolkit/xre/test/browser_checkdllblockliststate.js. CLOSED TREE 2021-06-26 09:45:29 +03:00
Doug Thayer c3702a9447 Bug 1714212 - Ensure COM initialized prior to showing skeleton UI r=Jamie,aklotz,tkikuchi
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.

Differential Revision: https://phabricator.services.mozilla.com/D117663
2021-06-26 04:10:50 +00:00
Aaron Klotz 0785438543 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
Marian-Vasile Laza 5c483b46df Backed out 4 changesets (bug 1707954) for causing bc failures in ClearOnShutdown.cpp.
CLOSED TREE

Backed out changeset 7cb0db27236c (bug 1707954)
Backed out changeset fd52d202d10b (bug 1707954)
Backed out changeset 55586d8f7bf4 (bug 1707954)
Backed out changeset 49406bdac5ec (bug 1707954)
2021-06-10 09:13:45 +03:00
Aaron Klotz 6ff70a37d9 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-09 21:38:14 +00:00
Noemi Erli 90b8bc9a03 Backed out 4 changesets (bug 1707954) for causing bustages in rules.mk CLOSED TREE
Backed out changeset fa23f9293250 (bug 1707954)
Backed out changeset e1b37839487b (bug 1707954)
Backed out changeset f72b810472fd (bug 1707954)
Backed out changeset fb4829011104 (bug 1707954)
2021-06-10 00:29:29 +03:00
Aaron Klotz e6aba31a8f 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-09 20:28:05 +00:00
Ricky Stewart 02a7b4ebdf Bug 1654103: Standardize on Black for Python code in `mozilla-central`.
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.

To produce this patch I did all of the following:

1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.

2. Run ./mach lint --linter black --fix

3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.

4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.

5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).

# ignore-this-changeset

Differential Revision: https://phabricator.services.mozilla.com/D94045
2020-10-26 18:34:53 +00:00
Bogdan Tara da1098d4aa Backed out 10 changesets (bug 1654103, bug 1672023, bug 1518999) for PanZoomControllerTest.touchEventForResult gv-junit failures CLOSED TREE
Backed out changeset ff3fb0b4a512 (bug 1672023)
Backed out changeset e7834b600201 (bug 1654103)
Backed out changeset 807893ca8069 (bug 1518999)
Backed out changeset 13e6b92440e9 (bug 1518999)
Backed out changeset 8b2ac5a6c98a (bug 1518999)
Backed out changeset 575748295752 (bug 1518999)
Backed out changeset 65f07ce7b39b (bug 1518999)
Backed out changeset 4bb80556158d (bug 1518999)
Backed out changeset 8ac8461d7bd7 (bug 1518999)
Backed out changeset e8ba13ee17f5 (bug 1518999)
2020-10-24 03:36:18 +03:00
Ricky Stewart c0cea3b0fa Bug 1654103: Standardize on Black for Python code in `mozilla-central`. r=remote-protocol-reviewers,marionette-reviewers,webdriver-reviewers,perftest-reviewers,devtools-backward-compat-reviewers,jgilbert,preferences-reviewers,sylvestre,maja_zf,webcompat-reviewers,denschub,ntim,whimboo,sparky
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.

To produce this patch I did all of the following:

1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.

2. Run ./mach lint --linter black --fix

3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.

4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.

5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).

# ignore-this-changeset

Differential Revision: https://phabricator.services.mozilla.com/D94045
2020-10-23 20:40:42 +00:00
Dorel Luca 1ff59cb7a3 Backed out changeset 7558c8821a07 (bug 1654103) for multiple failures. CLOSED TREE 2020-10-22 03:51:06 +03:00
Ricky Stewart 50762dacab Bug 1654103: Standardize on Black for Python code in `mozilla-central`. r=remote-protocol-reviewers,marionette-reviewers,webdriver-reviewers,perftest-reviewers,devtools-backward-compat-reviewers,jgilbert,preferences-reviewers,sylvestre,maja_zf,webcompat-reviewers,denschub,ntim,whimboo,sparky
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.

To produce this patch I did all of the following:

1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.

2. Run ./mach lint --linter black --fix

3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.

4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).

# ignore-this-changeset

Differential Revision: https://phabricator.services.mozilla.com/D94045
2020-10-21 21:27:27 +00:00
Aaron Klotz fccd6eb9ba Bug 1542830: Part 4 - Modify mozglue to use new untrusted modules interfaces; r=mhowell
* At this point our DLL blocking infra is complicated enough that I decided to
  bite the bullet and move all of this code out of `mozglue/build` and into its
  own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
   receives a vector containing all saved records of loaded DLLs that happened
   until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
   processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
  any other non-`firefox` processes that do not have a launcher process
  providing a loader API.
* We add some wide to UTF8 conversion functions.

Depends on D43157

Differential Revision: https://phabricator.services.mozilla.com/D43158

--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : browser/app/winlauncher/freestanding/LoaderAPIInterfaces.h => mozglue/dllservices/LoaderAPIInterfaces.h
rename : browser/app/winlauncher/freestanding/ModuleLoadInfo.h => mozglue/dllservices/ModuleLoadInfo.h
rename : browser/app/winlauncher/NtLoaderAPI.h => mozglue/dllservices/NtLoaderAPI.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
2019-09-23 20:18:41 +00:00
Brindusan Cristian 125c934a04 Backed out 8 changesets (bug 1542830) for causing Nightly bustages. a=backout
Backed out changeset 6fcb417f7ff4 (bug 1542830)
Backed out changeset 1aa253e6604a (bug 1542830)
Backed out changeset 73ec288886cd (bug 1542830)
Backed out changeset 84b903e60dc9 (bug 1542830)
Backed out changeset 8e2da9ff5f5a (bug 1542830)
Backed out changeset c4e547a6a039 (bug 1542830)
Backed out changeset 919f1af7c135 (bug 1542830)
Backed out changeset da7e775c4051 (bug 1542830)

--HG--
rename : browser/app/winlauncher/freestanding/DllBlocklist.cpp => browser/app/winlauncher/DllBlocklistWin.cpp
rename : browser/app/winlauncher/freestanding/DllBlocklist.h => browser/app/winlauncher/DllBlocklistWin.h
rename : mozglue/dllservices/Authenticode.cpp => mozglue/build/Authenticode.cpp
rename : mozglue/dllservices/Authenticode.h => mozglue/build/Authenticode.h
rename : mozglue/misc/WinUtils.h => mozglue/build/MozglueUtils.h
rename : mozglue/dllservices/WindowsDllBlocklist.cpp => mozglue/build/WindowsDllBlocklist.cpp
rename : mozglue/dllservices/WindowsDllBlocklist.h => mozglue/build/WindowsDllBlocklist.h
rename : mozglue/dllservices/WindowsDllBlocklistCommon.h => mozglue/build/WindowsDllBlocklistCommon.h
rename : mozglue/dllservices/WindowsDllBlocklistDefs.in => mozglue/build/WindowsDllBlocklistDefs.in
rename : mozglue/dllservices/WindowsDllServices.h => mozglue/build/WindowsDllServices.h
rename : mozglue/dllservices/gen_dll_blocklist_defs.py => mozglue/build/gen_dll_blocklist_defs.py
rename : toolkit/components/telemetry/docs/data/third-party-modules-ping.rst => toolkit/components/telemetry/docs/data/untrusted-modules-ping.rst
rename : toolkit/components/telemetry/tests/unit/test_ThirdPartyModulesPing.js => toolkit/components/telemetry/tests/unit/test_UntrustedModulesPing.js
rename : toolkit/xre/UntrustedModulesProcessor.cpp => toolkit/xre/ModuleEvaluator_windows.cpp
rename : toolkit/xre/UntrustedModulesProcessor.h => toolkit/xre/ModuleEvaluator_windows.h
rename : toolkit/xre/ModuleVersionInfo.cpp => toolkit/xre/ModuleVersionInfo_windows.cpp
rename : toolkit/xre/ModuleVersionInfo.h => toolkit/xre/ModuleVersionInfo_windows.h
2019-09-22 00:01:01 +03:00
Aaron Klotz 8d1be668f6 Bug 1542830: Part 4 - Modify mozglue to use new untrusted modules interfaces; r=mhowell
* At this point our DLL blocking infra is complicated enough that I decided to
  bite the bullet and move all of this code out of `mozglue/build` and into its
  own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
   receives a vector containing all saved records of loaded DLLs that happened
   until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
   processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
  any other non-`firefox` processes that do not have a launcher process
  providing a loader API.
* We add some wide to UTF8 conversion functions.

Differential Revision: https://phabricator.services.mozilla.com/D43158

--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
2019-09-20 19:43:33 +00:00
Ciure Andrei 7db4ad5d80 Backed out 8 changesets (bug 1542830) for causing spidermonkey bustages CLOSED TREE
Backed out changeset b9f7fc8d0172 (bug 1542830)
Backed out changeset b85f58fd5bbd (bug 1542830)
Backed out changeset 0a9169ab2623 (bug 1542830)
Backed out changeset 39a7c05d54ef (bug 1542830)
Backed out changeset 7a3cbd2f59f0 (bug 1542830)
Backed out changeset 268530552281 (bug 1542830)
Backed out changeset df658ffb8599 (bug 1542830)
Backed out changeset e7bef6486a38 (bug 1542830)

--HG--
rename : browser/app/winlauncher/freestanding/DllBlocklist.cpp => browser/app/winlauncher/DllBlocklistWin.cpp
rename : browser/app/winlauncher/freestanding/DllBlocklist.h => browser/app/winlauncher/DllBlocklistWin.h
rename : mozglue/dllservices/Authenticode.cpp => mozglue/build/Authenticode.cpp
rename : mozglue/dllservices/Authenticode.h => mozglue/build/Authenticode.h
rename : mozglue/misc/WinUtils.h => mozglue/build/MozglueUtils.h
rename : mozglue/dllservices/WindowsDllBlocklist.cpp => mozglue/build/WindowsDllBlocklist.cpp
rename : mozglue/dllservices/WindowsDllBlocklist.h => mozglue/build/WindowsDllBlocklist.h
rename : mozglue/dllservices/WindowsDllBlocklistCommon.h => mozglue/build/WindowsDllBlocklistCommon.h
rename : mozglue/dllservices/WindowsDllBlocklistDefs.in => mozglue/build/WindowsDllBlocklistDefs.in
rename : mozglue/dllservices/WindowsDllServices.h => mozglue/build/WindowsDllServices.h
rename : mozglue/dllservices/gen_dll_blocklist_defs.py => mozglue/build/gen_dll_blocklist_defs.py
rename : toolkit/components/telemetry/docs/data/third-party-modules-ping.rst => toolkit/components/telemetry/docs/data/untrusted-modules-ping.rst
rename : toolkit/components/telemetry/tests/unit/test_ThirdPartyModulesPing.js => toolkit/components/telemetry/tests/unit/test_UntrustedModulesPing.js
rename : toolkit/xre/UntrustedModulesProcessor.cpp => toolkit/xre/ModuleEvaluator_windows.cpp
rename : toolkit/xre/UntrustedModulesProcessor.h => toolkit/xre/ModuleEvaluator_windows.h
rename : toolkit/xre/ModuleVersionInfo.cpp => toolkit/xre/ModuleVersionInfo_windows.cpp
rename : toolkit/xre/ModuleVersionInfo.h => toolkit/xre/ModuleVersionInfo_windows.h
2019-09-20 21:21:39 +03:00
Aaron Klotz 12843d81e9 Bug 1542830: Part 4 - Modify mozglue to use new untrusted modules interfaces; r=mhowell
* At this point our DLL blocking infra is complicated enough that I decided to
  bite the bullet and move all of this code out of `mozglue/build` and into its
  own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
   receives a vector containing all saved records of loaded DLLs that happened
   until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
   processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
  any other non-`firefox` processes that do not have a launcher process
  providing a loader API.
* We add some wide to UTF8 conversion functions.

Differential Revision: https://phabricator.services.mozilla.com/D43158

--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
2019-09-20 17:00:14 +00:00
Andreea Pavel 31d9596a28 Backed out 8 changesets (bug 1542830) for gecko decision failure on a CLOSED TREE
DONTBUILD

Backed out changeset 4f72161be496 (bug 1542830)
Backed out changeset 7ee12138946d (bug 1542830)
Backed out changeset 9e90ee4981c6 (bug 1542830)
Backed out changeset 363039c98534 (bug 1542830)
Backed out changeset 70ffff30551a (bug 1542830)
Backed out changeset c25b7bf354d9 (bug 1542830)
Backed out changeset d156dc595b69 (bug 1542830)
Backed out changeset 9f5dbd1b2959 (bug 1542830)

--HG--
rename : browser/app/winlauncher/freestanding/DllBlocklist.cpp => browser/app/winlauncher/DllBlocklistWin.cpp
rename : browser/app/winlauncher/freestanding/DllBlocklist.h => browser/app/winlauncher/DllBlocklistWin.h
rename : mozglue/dllservices/Authenticode.cpp => mozglue/build/Authenticode.cpp
rename : mozglue/dllservices/Authenticode.h => mozglue/build/Authenticode.h
rename : mozglue/misc/WinUtils.h => mozglue/build/MozglueUtils.h
rename : mozglue/dllservices/WindowsDllBlocklist.cpp => mozglue/build/WindowsDllBlocklist.cpp
rename : mozglue/dllservices/WindowsDllBlocklist.h => mozglue/build/WindowsDllBlocklist.h
rename : mozglue/dllservices/WindowsDllBlocklistCommon.h => mozglue/build/WindowsDllBlocklistCommon.h
rename : mozglue/dllservices/WindowsDllBlocklistDefs.in => mozglue/build/WindowsDllBlocklistDefs.in
rename : mozglue/dllservices/WindowsDllServices.h => mozglue/build/WindowsDllServices.h
rename : mozglue/dllservices/gen_dll_blocklist_defs.py => mozglue/build/gen_dll_blocklist_defs.py
rename : toolkit/components/telemetry/docs/data/third-party-modules-ping.rst => toolkit/components/telemetry/docs/data/untrusted-modules-ping.rst
rename : toolkit/components/telemetry/tests/unit/test_ThirdPartyModulesPing.js => toolkit/components/telemetry/tests/unit/test_UntrustedModulesPing.js
rename : toolkit/xre/UntrustedModulesProcessor.cpp => toolkit/xre/ModuleEvaluator_windows.cpp
rename : toolkit/xre/UntrustedModulesProcessor.h => toolkit/xre/ModuleEvaluator_windows.h
rename : toolkit/xre/ModuleVersionInfo.cpp => toolkit/xre/ModuleVersionInfo_windows.cpp
rename : toolkit/xre/ModuleVersionInfo.h => toolkit/xre/ModuleVersionInfo_windows.h
2019-09-20 19:49:27 +03:00
Aaron Klotz 6c7b43b9c8 Bug 1542830: Part 4 - Modify mozglue to use new untrusted modules interfaces; r=mhowell
* At this point our DLL blocking infra is complicated enough that I decided to
  bite the bullet and move all of this code out of `mozglue/build` and into its
  own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
   receives a vector containing all saved records of loaded DLLs that happened
   until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
   processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
  any other non-`firefox` processes that do not have a launcher process
  providing a loader API.
* We add some wide to UTF8 conversion functions.

Differential Revision: https://phabricator.services.mozilla.com/D43158

--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
2019-09-20 00:09:41 +00:00
Mike Hommey 2abcc3d7cb Bug 1553363 - Generalize the *_impl goop for allocation functions in mozglue. r=froydnj
The current situation is suboptimal, where we have the same goop
repeated in multiple files, and where things kinda sorta work out fine
thanks to the linker for files that would have been forbidden, except
when the linker doesn't do its job, which apparently happen on
mingwclang builds.

This change only really covers C++ code using operator new/delete, and
not things that would be using malloc/free, because it's easier.
malloc/free is left for a followup.

Differential Revision: https://phabricator.services.mozilla.com/D32119

--HG--
extra : moz-landing-system : lando
2019-05-29 22:49:42 +00:00
Sylvestre Ledru e0c61dafa5 Bug 1519636 - Reformat recent changes to the Google coding style r=Ehsan
Summary: # ignore-this-changeset

Reviewers: Ehsan

Reviewed By: Ehsan

Subscribers: emilio, jandem, bbouvier, jya

Bug #: 1519636

Differential Revision: https://phabricator.services.mozilla.com/D20062
2019-02-16 20:20:37 +01:00
Aaron Klotz 84c01f8930 Bug 1400344: Rename mscom::MainThreadRuntime to mscom::ProcessRuntime and make it aware of Win32k lockdown and of multiple instantiations; r=Jamie
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
2019-02-14 18:56:20 +00:00
Dorel Luca 67115dd61b Backed out changeset 2d4b8d90cbd7 (bug 1400344) for Spider monkey failrues. CLOSED TREE
--HG--
rename : ipc/mscom/ApartmentRegion.h => ipc/mscom/COMApartmentRegion.h
rename : ipc/mscom/ProcessRuntime.cpp => ipc/mscom/MainThreadRuntime.cpp
rename : ipc/mscom/ProcessRuntime.h => ipc/mscom/MainThreadRuntime.h
2019-02-14 20:45:26 +02:00
Aaron Klotz 0cb12a123a Bug 1400344: Rename mscom::MainThreadRuntime to mscom::ProcessRuntime and make it aware of Win32k lockdown and of multiple instantiations; r=Jamie
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
2019-02-14 16:40:58 +00:00