Support for accept4 and arc4random_buf depends on which set of NDK
headers we're using. accept4 is supported for API >= 21 for unified and
non-unified headers. arc4random_buf is supported for API >= 21 if using
non-unified headers, and it's always supported if using unified headers
(the unified headers provide shims for API < 21).
MozReview-Commit-ID: FY8n5jWXB1K
--HG--
rename : ipc/chromium/src/third_party/libevent/patches/android-arc4random-buf.patch => ipc/chromium/src/third_party/libevent/patches/android-api-level.patch
extra : rebase_source : 45ec28ca03ba877d9e0911bde081df7d9cb2d3d2
Support for accept4 and arc4random_buf depends on which set of NDK
headers we're using. accept4 is supported for API >= 21 for unified and
non-unified headers. arc4random_buf is supported for API >= 21 if using
non-unified headers, and it's always supported if using unified headers
(the unified headers provide shims for API < 21).
MozReview-Commit-ID: FY8n5jWXB1K
--HG--
rename : ipc/chromium/src/third_party/libevent/patches/android-arc4random-buf.patch => ipc/chromium/src/third_party/libevent/patches/android-api-level.patch
extra : rebase_source : a8974cb1e8e71a8c951754ca9902fff28c099031
This fix is completely speculative, but I have strong reason to believe that
we are having lifetime issues, and that refcount stabilization might be coming
into play.
The situation is this:
Suppose we're aggregating an object, so we pass |this| as the outer IUnknown.
The inner object might perform AddRef() and Release() on |this| during its
initialization.
But if we're in the process of creating the outer object, that refcount might
not yet have been incremented by 1, so the inner object's invocation of the
outer object's Release() could trigger a deletion.
The way around this is to temporarily bump the refcount when aggregating another
object. The key, though, is to not do this via AddRef() and Release(), but by
direct maniuplation of the refcount variable, so that we don't trigger any of
the self-deletion stuff.
MozReview-Commit-ID: 3WA2AJvb6jY
--HG--
extra : rebase_source : ab05a52760541a4ab11f1245a5ddeae938998047
The FunctionBroker is a special kind of FunctionHook that brokers the hooked function on another process. In the child process, it uses the FunctionBrokerChild to request that the FunctionBrokerParent run a function and return the response. It handles most cases of parameter, return value and error marshaling on its own. It also guarantees that requests are issued from the proper thread.
The FunctionBroker actors allow the NPAPI process (child) to run methods on the main process (parent). Both the parent and the child run dedicated threads for this task -- this is a top-level protocol.
Namespace isolation is now handled by using clone() at process creation
time, rather than calling unshare.
pthread_atfork will no longer apply to sandboxed child processes.
The two significant uses of it in Firefox currently are to (1) make
malloc work post-fork, which we already avoid depending on in IPC and
sandboxing, and (2) block SIGPROF while forking, which is taken care of;
see SandboxFork::Fork for details. Note that if we need pthread_atfork
in the future it could be emulated by symbol interposition.
clone() is called via glibc's wrapper, for increased compatibility vs.
invoking the syscall directly, using longjmp to recover the syscall's
fork-like semantics the same way Chromium does; see comments for details.
The chroot helper is reimplemented; the general approach is similar,
but instead of a thread it's a process cloned with CLONE_FS (so the
filesystem root is shared) from the child process before it calls
exec, so that it still holds CAP_SYS_CHROOT in the newly created user
namespace. This does mean that it will retain a CoW copy of the
parent's address space until the child starts sandboxing, but that is a
relatively short period of time, so the memory overhead should be small
and short-lived.
The chrooting now happens *after* the seccomp-bpf policy is applied;
previously this wasn't possible because the chroot thread would have
become seccomp-restricted and unable to chroot. This fixes a potential
race condition where a thread could try to access the filesystem after
chrooting but before having its syscalls intercepted for brokering,
causing spurious failure. (This failure mode hasn't been observed in
practice, but we may not be looking for it.)
This adds a hidden bool pref, security.sandbox.content.force-namespace,
which unshares the user namespace (if possible) even if no sandboxing
requires it. It defaults to true on Nightly and false otherwise, to
get test coverage; the default will change to false once we're using
namespaces by default with content.
MozReview-Commit-ID: JhCXF9EgOt6
--HG--
rename : security/sandbox/linux/LinuxCapabilities.cpp => security/sandbox/linux/launch/LinuxCapabilities.cpp
rename : security/sandbox/linux/LinuxCapabilities.h => security/sandbox/linux/launch/LinuxCapabilities.h
extra : rebase_source : f37acacd4f79b0d6df0bcb9d1d5ceb4b9c5e6371
inline is never set so cgen never emits inline.
MozReview-Commit-ID: BDL6BV8906t
--HG--
extra : rebase_source : aa51cda34db36ba08622d9940402cea14617c74a
never_inline is never set so cgen never emits MOZ_NEVER_INLINE.
MozReview-Commit-ID: HS7qw7D4lBC
--HG--
extra : rebase_source : 2eae9e3a7a0c95d94986283fabe670d5decec3c3
pure or override implies virtual. static is mutually exclusive with virtual (and pure and override). Combining these types into a "method specifier" enum simplifies the code and prevents bogus states like virtual=0 and pure=1.
MozReview-Commit-ID: IFeuvbp1RIo
--HG--
extra : rebase_source : d423d168a8b3a3d60cabd0f5e58fd03c6f655baf
We had to force-include Char16.h to simulate char16_t on older MSVC versions.
But it is no longer the case. We should not rebuild the world whenever we
touch this file.
MozReview-Commit-ID: 1XY7tQD8LoK
--HG--
extra : rebase_source : a08ccfc9b6a4abf90f6f8b97a42079865724c9ec
CPU is only used on Windows, for TimeTicks::HighResNow, but the latter
is not used, so remove them all.
MozReview-Commit-ID: CvV1gMrVRA5
--HG--
extra : rebase_source : 2a512e2cfbe7d734a2c806214a2a96f79cbc9f11
CPU is only used on Windows, for TimeTicks::HighResNow, but the latter
is not used, so remove them all.
MozReview-Commit-ID: CvV1gMrVRA5
--HG--
extra : rebase_source : 60ddcf6ea5542f4526a23d739a2fe754219e5b9f
This patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
--HG--
extra : rebase_source : f932d7597a26a3f0c4246b3a95df638860d3d32d
PluginMessageUtils.h was bootlegging base/shared_memory.h via transport_dib.h
MozReview-Commit-ID: CPGxu2lpdj0
--HG--
extra : rebase_source : 796c747a4a125dddc2a0685f1e0d0152ac3ef74f
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
Summary:
We currently have a single WebAuthnManager instance per process that's shared
between all CredentialContainers. That way the nsPIDOMWindowInner parent has
to be tracked by the transaction, as multiple containers could kick off
requests simultaneously.
This patch lets us we have one WebAuthnManager instance per each
CredentialsContainer and thus each nsPIDOMWindowInner. This matches the current
U2F implementation where there is one instance per parent window too.
This somewhat simplifies the communication diagram (at least in my head), as
each U2F/WebAuthnManager instance also has their own TransactionChild/Parent
pair for IPC protocol communication. The manager and child/parent pair are
destroyed when the window is.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1421616
Differential Revision: https://phabricator.services.mozilla.com/D305
Summary:
We currently have a single WebAuthnManager instance per process that's shared
between all CredentialContainers. That way the nsPIDOMWindowInner parent has
to be tracked by the transaction, as multiple containers could kick off
requests simultaneously.
This patch lets us we have one WebAuthnManager instance per each
CredentialsContainer and thus each nsPIDOMWindowInner. This matches the current
U2F implementation where there is one instance per parent window too.
This somewhat simplifies the communication diagram (at least in my head), as
each U2F/WebAuthnManager instance also has their own TransactionChild/Parent
pair for IPC protocol communication. The manager and child/parent pair are
destroyed when the window is.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1421616
Differential Revision: https://phabricator.services.mozilla.com/D305
Also ensure we're more consistent about having two blank lines after these methods.
MozReview-Commit-ID: 2SXXjDuMW4u
--HG--
extra : rebase_source : 05279ceab3aa32d1e577ea02ccd113180bb55792
There's already a typedef for MessageChannel, so use that instead of
Channel. Also, use IProtocol and not ProtocolBase or ChannelListener,
for simplicity.
MozReview-Commit-ID: 2zCjTpPTW4L
--HG--
extra : rebase_source : eed8d6d51a512ac85f6b4962fc12591bf81c2981
This method is now trivial, so we can inline a few things. This
removes the only callers of sendSems(), so remove that, too.
MozReview-Commit-ID: Bb4EF9M56ut
--HG--
extra : rebase_source : dedf31aa225361e31122362aefc76940edbf25f3
This also changes URIUtils.cpp:DeserializeURI() to use the mutator to instantiate new URIs, instead of using their default constructor.
MozReview-Commit-ID: JQOvIquuQAP
--HG--
extra : rebase_source : e146624c5ae423f7f69a738aaaafaa55dd0940d9
If QueryHandlerInterface returns E_NOINTERFACE, the proxy will be queried for the interface.
However, the handler might know that the interface is definitely not available and could thus avoid a pointless cross-process call.
To facilitate this, the handler can now return S_FALSE to signal that the proxy should not be queried, thus immediately returning E_NOINTERFACE to the client.
MozReview-Commit-ID: 4RtBsA9BTOV
--HG--
extra : rebase_source : 4b0dcb16c469361c1944b24568ceb83fd0ac09c1
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
This is a hack that was added back when the chromium ipc codebase was
imported, but that shouldn't be required anymore. The mozalloc operator
new is gotten through stl wrapping these days.
This patch uses MozURL in ServiceWorkerRegistrar and in DBScheme to obtain the
origin of a URL. This is safe because the URL is always http/https/ftp.
It also changes the serialization of Principal in nsJSPrincipals in order to
pass the originNoSuffix together with the OriginAttributes and the spec.
This patch moves handling of the "MOZ_DISABLE_CONTENT_SANDBOX" environment
variable into GetEffectiveContentSandboxLevel. It also introduces
IsContentSandboxEnabled and ports many users of GetEffectiveContentSandboxLevel
to use it.
MozReview-Commit-ID: 4CsOf89vlRB
--HG--
extra : rebase_source : b9130f522e860e6a582933799a9bac07b771139b
This patch moves handling of the "MOZ_DISABLE_CONTENT_SANDBOX" environment
variable into GetEffectiveContentSandboxLevel. It also introduces
IsContentSandboxEnabled and ports many users of GetEffectiveContentSandboxLevel
to use it.
MozReview-Commit-ID: 4CsOf89vlRB
--HG--
extra : rebase_source : 10234bd7d837eae8dc915e4a0c0a37040fd0a280
MOZ_CRASH_UNSAFE_PRINTF causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_PRINTF are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: 5ujXa9MHH5Z
--HG--
extra : rebase_source : 1367e6ac3c6085341e36cb0859d91417245ea472
extra : source : 3edeb64a40afd79d5c01ae0f0d3ab2777a2e744b
This also enables the crash reporter on the MinGW build, as this is the
only thing blocking that from working.
MozReview-Commit-ID: Hygd7UUQvwl
--HG--
extra : rebase_source : a4a12b8edaa5b1fba869d6f7c21fc8444be2d9d7
Summary:
This patch fixes the reported leak of U2FTransactionChild instances in the
content process by introducing a WebAuthnTransactionChildBase class that both
WebAuthnTransactionChild and U2FTransactionChild inherit from.
This base class is responsible for proper refcounting. In
BackgroundChildImpl::DeallocPWebAuthnTransactionChild() we currently always
cast to WebAuthnTransactionChild, that will work only for the WebAuthn API. We
can now cast to WebAuthnTransactionChildBase to make this work for U2F as well.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1412408
Differential Revision: https://phabricator.services.mozilla.com/D179
And remove unreachable code after MOZ_CRASH_UNSAFE_OOL().
MOZ_CRASH_UNSAFE_OOL causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_OOL are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: IHmJfuxXSqw
--HG--
extra : rebase_source : 031f30934b58a7b87f960e57179641d44aefe5c5
extra : source : fe9f638a56a53c8721eecc4273dcc074c988546e
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
StripHandlerFromOBJREF shortens the OBJREF by sizeof(CLSID), so it needs to seek the stream back after tweaking the OBJREF.
Previously, this was done using a relative seek.
Unfortunately, for some reason I can't fathom on Windows 7, this doesn't work when marshaling for VT_DISPATCH.
The Seek call succeeds, but either does nothing or sets the stream position to a garbage value.
Instead, we now use an absolute seek, which seems to behave.
This was breaking IAccessible::accNavigate and AccessibleChildren on Windows 7.
MozReview-Commit-ID: FEH93oiyP5R
--HG--
extra : rebase_source : b15db60da888b49cbd371bc5c8311577a2c7ece4
This was used to support cross-architecture NPAPI plugins on OS X, but
we stopped supporting that in 54 (bug 1339182).
MozReview-Commit-ID: 2BcWYD6mguY
--HG--
extra : rebase_source : 6e509a3cc1f356ccd24f1459c43bc8fb66d7b0f4
This patch adds two additional fields to each mscom log entry: The first is
the duration, in microseconds, of time spent in mscom overhead when executing
a call from the MTA on behalf of a remote client.
The second field is the duration, in microseconds, of time spent actually
executing the method within Gecko itself.
(In other words, the sum of the two fields will equal the total duration of
time spent executing the call.)
MozReview-Commit-ID: EhFieEPrhE5
As its original comments indicate, SetAllFDsToCloseOnExec has an
unavoidable race condition if another thread creates file descriptors
during launch. Instead, use POSIX_SPAWN_CLOEXEC_DEFAULT, which is an
Apple-specific extension to posix_spawn that accomplished the desired
effect atomically.
This patch also introduces some RAII to simplify cleanup in error cases.
MozReview-Commit-ID: 6oHggs77AiY
--HG--
extra : rebase_source : a9391031a95fee4977af800ca993871277db51ce
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : source : 237acf2879f6222bc4b076c377bf026d18a6ebef
extra : amend_source : dfaf6e88e3c4758f7fdcf7fb422d457edafab1b7
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : rebase_source : d2a5e0862f8c964fb5a3e46b50c2e9629b218699
extra : amend_source : 27d7a7ef5da6fe2aa1104009b6ee067465db73e1
ChildPrivileges is a leftover from the B2G process model; it's now
mostly unused, except for the Windows sandbox using it to carry whether
a content process has file:/// access.
In general, when sandboxing needs to interact with process launch, the
inputs are some subset of: the GeckoProcessType, the subtype if content,
various prefs and even GPU configuration; and the resulting launch
adjustments are platform-specific. And on some platforms (e.g., OS X)
it's all done after launch. So a simple enum used cross-platform isn't
a good fit.
MozReview-Commit-ID: K31OHOpJzla
--HG--
extra : rebase_source : 3928b44eb86cd076bcac7897536590555237b76b
This is mostly based on the BSD version, which in turn is more or less
the Mac version minus some race conditions. The Linux version does
something similar, but more verbosely and (at least in my opinion) is
harder to follow. Some changes have been made, mainly to use C++11
features like UniquePtr.
MozReview-Commit-ID: 3Gv4DKCqWvu
--HG--
extra : rebase_source : 972264a778b9361d1259851554b5b7ae8f3dcdc6
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
Avoid going through GeckoAppShell and move the start child process JNI
call directly to GeckoProcessManager.
MozReview-Commit-ID: KU62TiHVQJX
--HG--
extra : rebase_source : 0e8546da502257e1c59bc00b79f50c79a314f3e6
After the previous patch, all that is needed to pass eslint is some
whitespace fixes I generated using:
./mach eslint --fix ipc
The .eslintrc.js file makes eslint expect XPCShell global variables.
With those two changes, eslint can be enabled for the ipc/ directory.
MozReview-Commit-ID: BqSICp2iV6O
--HG--
extra : rebase_source : ccab8be9fc1ae1116ae55631d3978c39d35cad05
I don't fully understand what this test is trying to do, but as far as
I can see, test_ipcshell_child.js does nothing when loaded from
test_ipcshell.js besides define a few variables, so just define them
directly in test_ipcshell.js. I am doing this because eslint does not
like the way the test is currently written: the definition of runtime
in another file confuses it, and it does not like the assignment to
run_test.
MozReview-Commit-ID: Ek0HY9n49eZ
--HG--
extra : rebase_source : 5c99b20afe93c085a198e7824e82207be347f26b
