Move sandbox early start logic to GeckoChildProcessHost.
Move sandbox CLI param logic into MacSandboxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D22409
--HG--
extra : moz-landing-system : lando
This patch adds two things:
1. An optional fixed_address argument to SharedMemoryBasic::Map, which
is the address to map the shared memory at.
2. A FindFreeAddressSpace function that callers can use to find a
contiguous block of free address space, which can then be used to
determine an address to pass in to Map that is likely to be free.
Patches in bug 1474793 will use these to place the User Agent style
sheets in a shared memory buffer in the parent process at an address
that is also likely to be free in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D15057
--HG--
extra : moz-landing-system : lando
Replaced instances of callers in both C++ and JS files to query the state from the principal directly.
Differential Revision: https://phabricator.services.mozilla.com/D22532
--HG--
extra : moz-landing-system : lando
Added assert to check if the id is exceeding bounds of signed 32 bit integer.
```
x < (1<<29)
x+1 <= (1<<29)
((x+1)<<2) <= (1<<31)
((x+1)<<2) | (two bit tag t)<= (1<<31)
```
Differential Revision: https://phabricator.services.mozilla.com/D23808
--HG--
extra : moz-landing-system : lando
I'd like to move an ipc::ByteBuf member of a struct into a Maybe,
and in order for that to work IPDLParamTraits<Maybe> needs to support
the rvalue Write.
Differential Revision: https://phabricator.services.mozilla.com/D23986
--HG--
extra : moz-landing-system : lando
I'd like to move an ipc::ByteBuf member of a struct into a Maybe,
and in order for that to work IPDLParamTraits<Maybe> needs to support
the rvalue Write.
Differential Revision: https://phabricator.services.mozilla.com/D23986
--HG--
extra : moz-landing-system : lando
By allowing the creation of StrongWorkerRefs in the Canceling state we
ensure that IPC will not fail and lead to crashes.
Differential Revision: https://phabricator.services.mozilla.com/D21920
--HG--
extra : moz-landing-system : lando
This is needed to maintain full feature parity with the existing
nsIPrincipal serializer while switching to using the PrincipalInfo-based
one.
Depends on D14434
Differential Revision: https://phabricator.services.mozilla.com/D20854
--HG--
extra : moz-landing-system : lando
GMP shouldn't need them anyway, and this reduces the dependencies from the x86
build we need to package in the "i686" subdir.
Differential Revision: https://phabricator.services.mozilla.com/D19902
--HG--
extra : source : 72ef2d2e9429ddb00d423181e3f8c881db228889
extra : intermediate-source : 1481e243977a28f1e8bbc12641f9a44ecb0a3856
extra : histedit_source : 1eb8f04f329e2df8f92b85a884304fd89c616234
This patch assumes that "the build" places plugin-container.exe, xul.dll, and
their dependencies in the "i686" subdirectory of the aarch64 firefox package
directory.
Differential Revision: https://phabricator.services.mozilla.com/D19898
--HG--
extra : source : bcba2fa22c772ba7c17e0dbdb5a10e5bbfe900d6
extra : histedit_source : 4b7f79876b3e67d1c1c64d91e869c3ad1efc4913
Implements the windows remove client and server based on the current remoting
code in nsNativeAppSupportWin.cpp. Makes the hidden window classname encode both
program name and profile name. nsNativeAppSupportWin is now just used for
setting up the console.
Differential Revision: https://phabricator.services.mozilla.com/D19076
--HG--
extra : source : 84e8066625fd72fdb1eb6eab85621ae842fe91b4
extra : amend_source : b698f986cce0ccfae29c04fcbe0d84a6c8605ab6
Implements the windows remove client and server based on the current remoting
code in nsNativeAppSupportWin.cpp. Makes the hidden window classname encode both
program name and profile name. nsNativeAppSupportWin is now just used for
setting up the console.
Differential Revision: https://phabricator.services.mozilla.com/D19076
--HG--
extra : rebase_source : 57d9dd30fe7df2dab104bdc15cf68467d3f56e91
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
* New topLevel loads get the nsILoadInfo.openerPolicy of the current top level document
* Parsing the Cross-Opener-Origin-Policy of a channel will update mLoadInfo.openerPolicy and this value will get propagated to the child process.
* SessionStore now checks nsIHttpChannel.hasCrossOriginOpenerPolicyMismatch (preffed off) and performs a process switch if needed
Differential Revision: https://phabricator.services.mozilla.com/D19000
--HG--
rename : toolkit/components/remotebrowserutils/tests/browser/browser_httpResponseProcessSelection.js => toolkit/components/remotebrowserutils/tests/browser/browser_httpCrossOriginOpenerPolicy.js
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
* New topLevel loads get the nsILoadInfo.openerPolicy of the current top level document
* Parsing the Cross-Opener-Origin-Policy of a channel will update mLoadInfo.openerPolicy and this value will get propagated to the child process.
* SessionStore now checks nsIHttpChannel.hasCrossOriginOpenerPolicyMismatch (preffed off) and performs a process switch if needed
Differential Revision: https://phabricator.services.mozilla.com/D19000
--HG--
rename : toolkit/components/remotebrowserutils/tests/browser/browser_httpResponseProcessSelection.js => toolkit/components/remotebrowserutils/tests/browser/browser_httpCrossOriginOpenerPolicy.js
extra : moz-landing-system : lando
Shmem sizes serialized in an ipc::ShmemCreated message should be sent as an
uint32_t rather than a size_t, as size_t is defined as different sizes in 64
and 32 bit builds. If the size isn't consistent, we won't be able to reliably
send this message between cross architecture processes.
Also, Shmem's have a limit of 32bit for their size anyway:
https://searchfox.org/mozilla-central/rev/e00ea598e52bbb35f8c45abf9c2eade17962bb5e/ipc/glue/Shmem.cpp#127
So this patch should not affect allocations of shmems.
Differential Revision: https://phabricator.services.mozilla.com/D18909
--HG--
extra : source : d7276bbcafafd5cb96ef498ef74629294483e002
extra : amend_source : 9e4b7721cfbef5f2caf34c22de106c3127628597
extra : intermediate-source : 57b88145a6357f2fd3d93a101952b22279a246f2
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Alloc/Dealloc methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18131
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
Launching processes takes enough time that we should avoid blocking the
parent process's IPC I/O thread for it; it's less bad for responsiveness
than blocking the main thread, but it's not good.
On Windows we need to use a dedicated thread, because the sandbox isn't
thread-safe and it asserts that the same thread is used for every
launch. Otherwise, a thread pool is used. (Or, in the Web Replay
middleman process, where there isn't enough of XPCOM for any of this,
launching the actual content processes remains on the I/O thread.)
Depends on D18011
Differential Revision: https://phabricator.services.mozilla.com/D8946
--HG--
extra : moz-landing-system : lando
In order to enable asynchronous launch, destruction of
GeckoChildProcessHost (and its subclasses) has to be delayed until after
launching (or anything else that might be made asynchronous in the
future) has completed, to prevent use-after-free. However, there are
other dependencies on process hosts always being destroyed on the I/O
thread, so refcounting would be difficult to use.
Instead, GeckoChildProcessHost now may not be destroyed directly, but
must go through a method that handles the scheduling.
There are also some minor cleanups to the affected headers (removed
duplicate access modifiers, and made PluginProcessParent final).
Depends on D18010
Differential Revision: https://phabricator.services.mozilla.com/D18011
--HG--
extra : moz-landing-system : lando
The total size of an IPC inputStream message must be less than 1mb. When we
compose the message for the multiplex stream, each sub stream collaborates with
its own size, deciding if it's better to be a pipe stream (IPCRemoteStream) or
a full serialized one.
Differential Revision: https://phabricator.services.mozilla.com/D18543
--HG--
extra : moz-landing-system : lando
ProcessTypeRequiresWinEventHook was added when attempting to turn on win32k
lockdown for GMP processes. Having a less specific, but globally accessible,
function will make it more useful while applying win32k lockdown to other
process types.
Before this patch, IPCStream was an union containing IPCRemoteSteam or an
InputStreamParamsWithFds. Now InputStreamParamsWithFds is renamed IPCStream and
IPCRemoteSteam is one of the possible InputStreamParams structs.
Before this set of patches, the decision of exposing the stream as a pipe was
centralized in IPCStreamUtils, based on the total expectation size of the IPC
message. This triggers issues when multiplex inputStreams contain something
that cannot be sent as a pipe (IPCBlobInputStream, for instance), or something
that it's better to do not set as a pipe (nsFileInputStream), together with
memory streams (nsStringInputStream), which could make the IPC message greater
then what accepted (1mb).
These patches move the "pipe vs non-pipe" choice into the single inputStream
implementation.