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
