GetCurrentPhysicalThread and GetCurrentVirtualThread are, in practice,
identical, as the TLS override that GetCurrentVirtualThread depends on
is never actually set. This simply removes that and renames some things/
deletes some comments.
Differential Revision: https://phabricator.services.mozilla.com/D41247
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
* 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
* 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
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
* 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
* 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
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
We'd like to offer a way for developers to safely do asynchronous instantiations
of COM objects. This patch adds a static CreateInstance method to mscom::EnsureMTA
that facilitates this under certain conditions (as outlined in the comments).
To help ensure that this is as safe as possible, we return a MozPromise that,
once resolved, produces an AgileReference that may then be passed between
threads, and may then be resolved when a specific thread needs to access the
interface.
Differential Revision: https://phabricator.services.mozilla.com/D44519
--HG--
extra : moz-landing-system : lando
We want to ensure that the code being added in part 2 is only used when it is
reasonable and safe to do so. One way to ensure this is to add a check that the
desired CLSID is an in-process, thread-aware server.
Differential Revision: https://phabricator.services.mozilla.com/D44518
--HG--
extra : moz-landing-system : lando
This will help to catch changes that cause a loss of annotations without
affecting Release or Beta.
This also makes CrashReporterClient::InitSingleton return void as the previous
bool was ignored in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D44642
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
Until now, AgileReference was not copyable because it could not handle the
copying of global interface table cookies. By moving the cookie into its own
reference counted object, we can enable copying on the AgileReference.
Differential Revision: https://phabricator.services.mozilla.com/D43616
--HG--
extra : moz-landing-system : lando
This patch provides us with utility functions that give us more specific
information about the current thread's MTA if so desired.
Differential Revision: https://phabricator.services.mozilla.com/D41852
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
This patch also includes some spot fixes for the storage principal
support on the XUL browser element.
Differential Revision: https://phabricator.services.mozilla.com/D42203
--HG--
extra : moz-landing-system : lando
We're not using the library it produces anymore. The code is still used,
though, directly #included from browser/app/nsBrowserApp.cpp and
ipc/app/MozillaRuntimeMain.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D42279
--HG--
extra : moz-landing-system : lando
In order to use `mscom::ProcessRuntime` in the maintenance service, we need
`ProcessRuntime` to be able to distinguish between more than just whether or not
the current process is the parent process.
I've added a new `ProcessCategory` enum to track this information, and revised
the constructors so that we now have one that accepts a ProcessCategory.
The `ProcessCategory` constructor is private inside XUL, since the
`GeckoProcessType` variant should always be used in that case.
We also slightly change apartment initialization to depend on the underlying
`ProcessCategory` value.
Finally, I modify the one case where we instantiate a `ProcessRuntime` in the
launcher process to use the new constructor.
Differential Revision: https://phabricator.services.mozilla.com/D42225
--HG--
extra : moz-landing-system : lando
Also refactor SharedMemoryBasic::SystemProtect to allow testing cases
that are expected to fail.
Depends on D26748
Differential Revision: https://phabricator.services.mozilla.com/D26749
--HG--
rename : ipc/moz.build => ipc/gtest/moz.build
extra : moz-landing-system : lando
If mmap failed, we'd leave the memory_ member variable set to MAP_FAILED,
but everything else in this file checks for nullptr (and only nullptr) to
test if the pointer is valid.
Also, this removes the debug assertion that the mmap succeeded, to allow
writing unit tests where we expect it to fail (e.g., for insufficient
permissions).
Depends on D26747
Differential Revision: https://phabricator.services.mozilla.com/D26748
--HG--
extra : moz-landing-system : lando
This allows writing to shared memory and then making it read-only before
sharing it to other processes, such that a malicious sandboxed process
cannot regain write access. This is currently available only in the
low-level base::SharedMemory interface.
The freeze operation exposes the common subset of read-only shared
memory that we can implement on all supported OSes: with some APIs
(POSIX shm_open) we can't revoke writeability from existing capabilies,
while for others (Android ashmem) we *must* revoke it. Thus, we require
that the writeable capability not have been duplicated or shared to
another process, and consume it as part of freezing. Also, because in
some backends need special handling at creation time, freezeability must
be explicitly requested.
In particular, this doesn't allow giving an untrusted process read-only
access to memory that the original process can write.
Note that on MacOS before 10.12 this will use temporary files in order to
avoid an OS security bug that allows regaining write access; those OS
versions are no longer supported by Apple (but are supported by Firefox).
Depends on D26742
Differential Revision: https://phabricator.services.mozilla.com/D26743
--HG--
extra : moz-landing-system : lando
This uses RAII to handle error-case cleanup in the POSIX backend for
SharedMemory::Create, to simplify the complexity that will be added to
support freezing.
Depends on D26741
Differential Revision: https://phabricator.services.mozilla.com/D26742
--HG--
extra : moz-landing-system : lando
The Unix backend for shared memory needs to keep the mapped size to pass
to munmap, while the Windows backend doesn't. Currently it's reusing the
max_size field, and then zeroing it when it's unmapped, which breaks the
freezing use case. This patch uses a dedicated field for that.
Depends on D26740
Differential Revision: https://phabricator.services.mozilla.com/D26741
--HG--
extra : moz-landing-system : lando
Despite the comment saying not to use the "handle" except as an opaque
identifier, it is being used to pass the handle to other OS APIs. Direct
access to the handle needs to be controlled to make sure freezing is
safe, so this patch replaces that with interfaces that are more explicit
about ownership and lifetime.
Depends on D26739
Differential Revision: https://phabricator.services.mozilla.com/D26740
--HG--
extra : moz-landing-system : lando
FreeBSD's SHM_ANON is useful for the usual case of shared memory, but it
doesn't support freezing. It could be re-added later, but for now it's
simplest to remove it (and use named shm instead) while refactoring.
Depends on D26738
Differential Revision: https://phabricator.services.mozilla.com/D26739
--HG--
extra : moz-landing-system : lando
This changes the way crash reports for child processes happening too early
during the child process' startup. Before bug 1547698 we wrote a partial
.extra file with those crashes that lacked the process type. The user would
not be notified of those crashes until she restarted Firefox and even when
submitted those crashes would be erroneously labeled as browser crashes.
After bug 1547698 we stopped writing .extra files entirely for those crashes
which left orphaned .dmp files among the pending crash reports.
This patch does three things to improve the situation:
* It writes a partial .extra file so that the crashes are detected at the next
startup. So the user is still not notified directly of these crashes but she
can report them later.
* It adds the process type to the .extra file so that the crash reporters are
labelled correctly.
* It fixes a leak in the `pidToMinidump` hash-map. Since the crashes were
not finalized the `ChildProcessData` strucutre associated with them would
never be fred.
Differential Revision: https://phabricator.services.mozilla.com/D40810
--HG--
extra : moz-landing-system : lando
(a) Substitute Cross-Origin header with COEP
(b) Forcing cors in FetchDriver is removed since COEP doesn't need to IIUC
Differential Revision: https://phabricator.services.mozilla.com/D38788
--HG--
extra : moz-landing-system : lando
The stack from crash report suggests that ChildImpl was deleted at the end of function GetOrCreateSocketActorForCurrentThread(). This only happens when SendInitBackground failed, so we have to close the IPC channel before ChildImpl getting destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D40838
--HG--
extra : moz-landing-system : lando
The new StaticLocalAutoPtr smart pointer has a trivial destructor, so we will
either properly clean up this data or leak it on process shutdown. Either way,
we will not destroy it in a way that the underlying type does not support.
Differential Revision: https://phabricator.services.mozilla.com/D40842
--HG--
extra : moz-landing-system : lando
The new StaticLocalAutoPtr smart pointer has a trivial destructor, so we will
either properly clean up this data or leak it on process shutdown. Either way,
we will not destroy it in a way that the underlying type does not support.
Differential Revision: https://phabricator.services.mozilla.com/D40842
--HG--
extra : moz-landing-system : lando
ipc_message_utils.h defines IPDLParamTraits on windows for some things like
HWND and HANDLE. However, it doesn't directly include windows.h on Windows to
include them. All other usages seem to rely on including base/process.h, which
does include windows.h and adds the appropriate typedefs.
Differential Revision: https://phabricator.services.mozilla.com/D35089
--HG--
extra : moz-landing-system : lando
This takes the approach of directly tying the `AddRef()` and `Release()` calls
on the underlying actor object to the lifecycle of the ActorLifecycleProxy
object, by adding another virtual `ActorAlloc()` method as the counterpart to
`ActorDealloc()`.
The changes to the methods called from C++ are relatively minimal:
1. The `SendPFooConstructor(...)` methods have the same signature, but now will
AddRef() internally (through `ActorAlloc()`), so an `do_AddRef(foo).take()`
isn't needed. Same with the `{Bind,Open}PFooEndpoint` methods.
This was done to reduce the number of invasive internal changes in the
codegen which were required to pipe a passed-in `already_AddRefed` to the
underlying `ActorLifecycleProxy` which is created by generic code.
2. The `AllocPFoo{Parent,Child}` methods have been modified to return an
`already_AddRefed` by default, and the callsites will store the result in a
`RefPtr<T>` if the type is refcounted.
3. No `DeallocPFoo...` method is called anymore. Unfortunately due to
devirtualization, it won't be an error if an unused method is still present,
though it won't be called.
Differential Revision: https://phabricator.services.mozilla.com/D39502
--HG--
extra : moz-landing-system : lando
The syntax for the new construct looks like the following, and re-uses the
refcounted keyword from refcounted using statements:
async refcounted protocol PFoo { ... }
Differential Revision: https://phabricator.services.mozilla.com/D39501
--HG--
extra : moz-landing-system : lando
The previous behaviour of failing unconditionally was performed as, during
shutdown, the channel could become unable to send without worker threads having
a chance to react. This change keeps that behaviour, isolating async message
senders from impending IPC shutdown, while performing expected actor teardown if
the manager actor has already been destroyed, and should no longer send messages.
An alternate behaviour here could be to crash if !Manager()->CanSend(). That
behaviour may be preferable if a sufficient number of callsites don't check the
return value of the `SendPFooConstructor()` method.
Differential Revision: https://phabricator.services.mozilla.com/D39534
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Until now we asserted that EnsureMTA was being called from the main thread
unless the current thread was already in the MTA.
This patch makes MTA thread initialization thread-safe by using a C++11
"magic static," thus allowing EnsureMTA to be safely invoked from any thread.
Differential Revision: https://phabricator.services.mozilla.com/D38422
--HG--
extra : moz-landing-system : lando
At the moment, this shouldn't make any difference because we only ever
launch one child process on android.
Differential Revision: https://phabricator.services.mozilla.com/D38244
--HG--
extra : moz-landing-system : lando
Now that UniqueFileHandle can be used more widely, and with
ipc::FileDescriptor being essentially a copyable UniqueFileHandle, it
makes sense to add a move constructor and a "forget"-like method to
convert between them when needed.
Depends on D26737
Differential Revision: https://phabricator.services.mozilla.com/D26738
--HG--
extra : moz-landing-system : lando
I'm not convinced the current comment about being race-free is accurate
in context of the launcher pool. It probably _is_ correct under this
patch, because ProcessLaunchers should only be constructed on a single
thread, but it's easy enough just to make it atomic.
Hopefully moving the timestamp doesn't perturb telemetry too much.
Differential Revision: https://phabricator.services.mozilla.com/D37305
--HG--
extra : moz-landing-system : lando
This is intended to facilitate future work to break up
PerformAsyncLaunch into asynchronous pieces. It also aims to fix some
raciness around access to state in the GeckoChildProcessHost instance.
There appears to be at least one data race in the existing code, in which
OpenPrivilegedHandle are run on both the launcher thread and the IO
thread without synchronization.
Differential Revision: https://phabricator.services.mozilla.com/D36539
--HG--
extra : moz-landing-system : lando
Having to namespace these into GeckoChildProcessHost is annoying. The
|using| declarations help to some extent, but it's easier to just put
them in mozilla::ipc.
Differential Revision: https://phabricator.services.mozilla.com/D36538
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Also refactor SharedMemoryBasic::SystemProtect to allow testing cases
that are expected to fail.
Depends on D26748
Differential Revision: https://phabricator.services.mozilla.com/D26749
--HG--
rename : ipc/moz.build => ipc/gtest/moz.build
extra : moz-landing-system : lando
If mmap failed, we'd leave the memory_ member variable set to MAP_FAILED,
but everything else in this file checks for nullptr (and only nullptr) to
test if the pointer is valid.
Also, this removes the debug assertion that the mmap succeeded, to allow
writing unit tests where we expect it to fail (e.g., for insufficient
permissions).
Depends on D26747
Differential Revision: https://phabricator.services.mozilla.com/D26748
--HG--
extra : moz-landing-system : lando
This allows writing to shared memory and then making it read-only before
sharing it to other processes, such that a malicious sandboxed process
cannot regain write access. This is currently available only in the
low-level base::SharedMemory interface.
The freeze operation exposes the common subset of read-only shared
memory that we can implement on all supported OSes: with some APIs
(POSIX shm_open) we can't revoke writeability from existing capabilies,
while for others (Android ashmem) we *must* revoke it. Thus, we require
that the writeable capability not have been duplicated or shared to
another process, and consume it as part of freezing. Also, because in
some backends need special handling at creation time, freezeability must
be explicitly requested.
In particular, this doesn't allow giving an untrusted process read-only
access to memory that the original process can write.
Note that on MacOS before 10.12 this will use temporary files in order to
avoid an OS security bug that allows regaining write access; those OS
versions are no longer supported by Apple (but are supported by Firefox).
Depends on D26742
Differential Revision: https://phabricator.services.mozilla.com/D26743
--HG--
extra : moz-landing-system : lando
This uses RAII to handle error-case cleanup in the POSIX backend for
SharedMemory::Create, to simplify the complexity that will be added to
support freezing.
Depends on D26741
Differential Revision: https://phabricator.services.mozilla.com/D26742
--HG--
extra : moz-landing-system : lando
The Unix backend for shared memory needs to keep the mapped size to pass
to munmap, while the Windows backend doesn't. Currently it's reusing the
max_size field, and then zeroing it when it's unmapped, which breaks the
freezing use case. This patch uses a dedicated field for that.
Depends on D26740
Differential Revision: https://phabricator.services.mozilla.com/D26741
--HG--
extra : moz-landing-system : lando
Despite the comment saying not to use the "handle" except as an opaque
identifier, it is being used to pass the handle to other OS APIs. Direct
access to the handle needs to be controlled to make sure freezing is
safe, so this patch replaces that with interfaces that are more explicit
about ownership and lifetime.
Depends on D26739
Differential Revision: https://phabricator.services.mozilla.com/D26740
--HG--
extra : moz-landing-system : lando
FreeBSD's SHM_ANON is useful for the usual case of shared memory, but it
doesn't support freezing. It could be re-added later, but for now it's
simplest to remove it (and use named shm instead) while refactoring.
Depends on D26738
Differential Revision: https://phabricator.services.mozilla.com/D26739
--HG--
extra : moz-landing-system : lando
Now that UniqueFileHandle can be used more widely, and with
ipc::FileDescriptor being essentially a copyable UniqueFileHandle, it
makes sense to add a move constructor and a "forget"-like method to
convert between them when needed.
Depends on D26737
Differential Revision: https://phabricator.services.mozilla.com/D26738
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
Will also silence static analysis in phabricator whenever a caller of this code is used.
Differential Revision: https://phabricator.services.mozilla.com/D33419
--HG--
extra : moz-landing-system : lando
The vast majority of the virtual methods which were used on ProtocolState were
actually methods which only had meaningful implementations on the toplevel
protocol. This patch adds a new field to IProtocol holding a direct pointer to
the protocol's `IToplevelProtocol`, and the methods formerly implemented with
ProtocolState now directly call the corresponding method on IToplevelProtocol.
IToplevelProtocol then shadows these methods with the toplevel protocol
implementation, meaning that the right code is run in the right places.
In addition, some state was maintained for protocols inside of the separate
ProtocolState allocation, and this patch moves that state back into the actor
itself.
Differential Revision: https://phabricator.services.mozilla.com/D32044
--HG--
extra : moz-landing-system : lando
Make nsIWebBrowserPrint included unconditionally for addressing nsIDocShell.rs build failure.
Remove direct_call of PPrinting and PRemotePrintJob. Their ipdl are built unconditionally, but their derived classes are not built with --disable-printing.
Differential Revision: https://phabricator.services.mozilla.com/D33391
--HG--
extra : moz-landing-system : lando
This patch includes multiple changes cleaning up various aspects of the crash
reporter client and exception handler:
* Some Unix-specific code was moved out from the base crashreporter client
code and into the appropriate platform implementation
* Functions used to open files in the crashreporter client now accept C++
`std::ios` flags instead of unreadable booleans
* Useless character conversion routines were removed from the
minidump-analyzer
* Crash annotations are not serialized into a huge string anymore every time
they change. They are all written out individually during an exception.
* `WriteEscapedMozCrashReason()` uses the exception-safe `my_strlen()` instead
of plain `strlen()`
* The Windows-specific DLL-blocklist shutdown was removed from the Linux &
macOS Breakpad callbacks
* The `CrashReporterHost`, `CrashReporterClient` and
`CrashReporterMetadataShmem` classes now take `nsACString` references
instead of `nsCString` ones since they never modify their contents
Differential Revision: https://phabricator.services.mozilla.com/D33267
--HG--
extra : moz-landing-system : lando
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
Currently the Android implementation of process launch signals failure by
returning pid 0 through an out-parameter; we don't check for that, so we
report success and then the bad pid spreads through IPC until it sets off
an assertion somewhere else. This patch adds the missing check and
strengthens an assertion that would have caught the problem more directly.
Differential Revision: https://phabricator.services.mozilla.com/D32875
--HG--
extra : moz-landing-system : lando
This allows for the getter to be used in IProtocol's destructor, and generally
brings IProtocol more in line with IToplevelProtocol.
Differential Revision: https://phabricator.services.mozilla.com/D32042
--HG--
extra : moz-landing-system : lando
Don't hold gMutex when calling HandleSharePortsMessage() from PortServerThread to avoid deadlock.
Differential Revision: https://phabricator.services.mozilla.com/D31694
--HG--
extra : moz-landing-system : lando
These values were only being used for assertions within IPDL send
methods. They had no positive impact beyond causing crashes when sending
a message over a dead actor.
Differential Revision: https://phabricator.services.mozilla.com/D30235
--HG--
extra : moz-landing-system : lando
Historically we've failed very loudly when receiving a message which was
destined for an actor which had already been destroyed. This had the
effect of requiring manual teardown for most actors, as work would need
to be done to ensure messages weren't sent when the target actor might
be about to tear itself down.
In addition, due to this teardown work being done outside of IPDL, this
work would have to manually be checked in subactors, and involved the
addition of new flags, such as `mIPCOpen`, in order to track whether IPC
had begun to be shut down, and discard messages manually if it had.
It is an ongoing issue that we occasionally miss places where we need to
discard messages, and it is easy to not remember to perform async
destruction when building a new actor, meaning that extra work is
required to correctly discard messages when the actor is being torn
down. Due to the correct decision, almost all of the time, being to
discard the message, this patch takes the approach of transforming the
crash which was previously performed into a message discard.
The hope is that this will reduce the burden on actor implementors, by
allowing the use of `Send__delete__` without first synchronizing with
the remote actor, as well as reduce unintentional crashes.
Differential Revision: https://phabricator.services.mozilla.com/D28892
--HG--
extra : moz-landing-system : lando
Upon a content process crash or hang crash annotations were incrementally
written into the .extra file starting with the exception handler callback and
then in a number of different places before the file was ready for submission.
This had a number of downsides: since the annotations were directly added to
the file it was impossible to tell which ones were already written at a
certain point in time, additionally some were written twice or even thrice.
The code doing the writing would also behave differently depending on the
contents of the file, the parameters passed to it and the contents of global
variables.
This change overhauls the whole process by keeping the annotations into a
temporary per-crash annotation table which is filled with all the required
annotations before being written out in a single pass when they are ready.
The annotations are gathered from the main process annotation table, the
per-process one (held by the CrashReporterHost) and exception-time specific
ones.
The resulting annotations are slightly different than before the patch: first
of all there are no more duplicate entries in the .extra file and secondly all
content/plugin process hangs annotations are properly filtered, before
annotations that were main process-only would leak into them.
Differential Revision: https://phabricator.services.mozilla.com/D31069
--HG--
extra : moz-landing-system : lando
This removes the XRE_TakeMinidumpForChild() which does not need to be
exposed anymore in the XUL API as well as
IToplevelProtocol::TakeMinidump() which was simply unused.
Differential Revision: https://phabricator.services.mozilla.com/D31062
--HG--
extra : moz-landing-system : lando
This patch changes the way how we handle sync ctor send errors. They are now
ignored and treated like messages which successfully were queued to send, but
got lost due to the other side hanging up.
For more details, see bug 1509362 which originally did it for async ctors.
The main differences here are that we destroy the actor and we return null when
the send fails.
Differential Revision: https://phabricator.services.mozilla.com/D31517
This isn't needed now that BrowserParent has the same name
as the protocol.
Differential Revision: https://phabricator.services.mozilla.com/D30151
--HG--
extra : rebase_source : dbfc1722a43e1f8fbbe01f1766a397b570fa7d6a
extra : source : 792b49f269bb6308e152290ed0dfa03efbffa536
extra : histedit_source : e001669549af547f5387a3b010ad52ebee6eea3f
ContentVerifier has been dead code since bug 1355166 (which, incidentally, means
it has no tests). Its presence is preventing improvements to
ContentSignatureVerifier (see e.g. bug 1534600), so this patch removes it.
As a result, the nsILoadInfo attributes verifySignedContent and enforceSRI are
also unused, so this patch removes those as well.
Differential Revision: https://phabricator.services.mozilla.com/D28885
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
This consolidates array, maybe and unique ptrs in IPDL into a single
"has base type" qualifier, for types that wrap another type. I'm not
sure this patch fixes everything, but I think it is at least more
correct.
It also adds checking for the stuff inside the UniquePtr<>, because
the intent seems to be to allow things like protocol types in there.
Differential Revision: https://phabricator.services.mozilla.com/D28571
--HG--
extra : moz-landing-system : lando
Currently, when deserialization fails, the error message contains the base
name of the C++ type, without template parameters; this means we can get
unhelpfully vague errors about `RefPtr` or `Maybe` or `nsTArray`. (The
identical error cases are then merged by the compiler, so the execution
path can't be recovered from the crash dump.)
This patch uses the IPDL type instead. It would be possible to invoke
the code generator to use the full C++ type, but more complicated for no
real benefit.
Differential Revision: https://phabricator.services.mozilla.com/D28401
--HG--
extra : moz-landing-system : lando
In sandboxed processes with Win32k lockdown, when we initialize COM using an MTA
on a background thread, the main thread is automatically initialized by the COM
runtime as having an implicit MTA.
This is fine, except for the fact that if we want to enqueue any work that needs
to operate specifically on the EnsureMTA thread, it won't happen.
This patch adds a flag to EnsureMTA's constructor that ensures that, even if the
current thread is in an MTA (implicit or otherwise), we still forcibly enqueue
the closure specifically to the EnsureMTA thread.
Differential Revision: https://phabricator.services.mozilla.com/D28391
--HG--
extra : moz-landing-system : lando
Brindusan Cristian
Matt Woodrow
Peter Van der Beken
Narcis Beleuzu
Aaron Klotz
Razvan Maries
Honza Bambas
Christoph Kerschbaumer
Cosmin Sabou
Mihai Alexandru Michis
Doug Thayer
Bogdan Tara
Olli Pettay
arthur.iakab
Ciure Andrei
Andreea Pavel
Byron Campen [:bwc]
Ehsan Akhgari
Nika Layzell
Jed Davis
Gijs Kruitbosch
Jean-Yves Avenard
Nathan Froyd
Barret Rennie
Dorel Luca
Mike Hommey
Oana Pop Rus
David Major
Gabriele Svelto
Perry Jiang
Sylvestre Ledru
Junior Hsu
Kershaw Chang
Bobby Holley
Sebastian Streich
Andrea Marchesini
Nicholas Nethercote
Coroiu Cristina
Christian Holler
Benjamin
Brian Hackett
Alexis Beingessner
Jonathan Kingston
Victor Porof
shindli
Tarek Ziadé
Boris Zbarsky
myfreeweb
Gurzau Raul
Haik Aftandilian
sotaro
PHO
Jan Varga
Ryan Hunt
Bas Schouten
Jonathan Kew
Dana Keeler
Andrew McCreight