Eliminates the NPAPI plugin process type from the GeckoChildProcess enum as part of NPAPI removal. In order to avoid altering enum values when updating the process list, the GECKO_PROCESS_TYPE macro has been updated to include the desired enum value. We want to resist altering the values as they need to be consistent e.g. in telemetry reports.
We also remove plugins from adjacent spots that need to maintain consistency with GeckoChildProcess -- most notably the nsICrashService.
Differential Revision: https://phabricator.services.mozilla.com/D108689
Removes Windows NPAPI process sandboxing code, including the code to establish a viable temp directory that was accessible by the sandboxed process.
Differential Revision: https://phabricator.services.mozilla.com/D108688
The function to detect whether the kernel has separate syscalls for
socket operations (rather than only `socketcall`) had a comment that
it's called only once, which is no longer true. So, this seems like a
good time to add a cache (but not on newer archs like `x86_64` where the
answer is constant).
This patch also removes the ifdefs on `__NR_socket`, because all archs
have it now, and our local headers will define it even if the build
host's headers don't.
Differential Revision: https://phabricator.services.mozilla.com/D105853
When setting up calls to `sendmsg` for IPC on Unix systems, we generate
`iovec`s for the entire message or until the `IOV_MAX` limit is reached,
whichever comes first. However, messages can be very large (up to 256
MiB currently), while the OS socket buffer is relatively small (8KiB on
macOS and FreeBSD, ~200KiB on Linux).
This patch detects the socket buffer size with the `SO_SNDBUF` socket
option and cuts off the `iovec` array after it's reached; it also adjusts
the Linux sandbox policy to allow reading that value in all processes.
On my test machines this increases throughput on large messages by about
2.5x on macOS (from ~0.3 to ~0.7 GB/s), but on Linux the improvement is
only about 5% (most of the running time is spent elsewhere).
Differential Revision: https://phabricator.services.mozilla.com/D105852
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
Because Widevine may probe madvise using advice arguments we do not currently
support, including invalid arguments, this patch changes the handling of these
args so we will not crash in nightly.
Differential Revision: https://phabricator.services.mozilla.com/D106537
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
The patch for the chromium changes doesn't include the updates to
windows_version, because these are already in the release version of chromium
and so will be picked up when we next update.
Differential Revision: https://phabricator.services.mozilla.com/D103473
Thunderbird does not yet have the same blocklist initialization as Firefox, so we skip calling InitDllBlocklistOOP to avoid a MOZ_RELEASE_ASSERT.
Differential Revision: https://phabricator.services.mozilla.com/D99173
This patch is to improve the way to detect an injected dependent module for
automatic DLL blocking (bug 1659438).
In the previous version, we created a list of dependent modules in the launcher
process and shared it with other processes via the shared section. However, it
was not compatible with third-party applications who tamper the Import Table and
revert it in the injected module's DllMain (bug 1682834) because we parsed the
Import Table in the launcher process after it was reverted.
With this patch, we check the Import Table in `patched_NtMapViewOfSection`,
so we can see tampering before it's reverted. More specifically, we create
a list of dependent modules in the browser process as below.
1. The launcher process creates a section object and initializes
the kernel32.dll's functions in it.
2. The launcher process transfers a writable handle of the shared
section to the browser process.
3. In the browser process, if an injected dependent module is being
mapped by `NtMapViewOfSection`, we add its NT path to the shared
section and block it with `REDIRECT_TO_NOOP_ENTRYPOINT`.
4. The `main` function of the browser process converts the writable
handle of the shared section into a readonly handle.
5. The browser process transfers a readonly handle of the shared
section to a sandbox process.
Since automatic DLL blocking may still cause a compat issue like bug 1682304,
we activate it only in Nightly for now.
Differential Revision: https://phabricator.services.mozilla.com/D101460
This patch is to improve the way to detect an injected dependent module for
automatic DLL blocking (bug 1659438).
In the previous version, we created a list of dependent modules in the launcher
process and shared it with other processes via the shared section. However, it
was not compatible with third-party applications who tamper the Import Table and
revert it in the injected module's DllMain (bug 1682834) because we parsed the
Import Table in the launcher process after it was reverted.
With this patch, we check the Import Table in `patched_NtMapViewOfSection`,
so we can see tampering before it's reverted. More specifically, we create
a list of dependent modules in the browser process as below.
1. The launcher process creates a section object and initializes
the kernel32.dll's functions in it.
2. The launcher process transfers a writable handle of the shared
section to the browser process.
3. In the browser process, if an injected dependent module is being
mapped by `NtMapViewOfSection`, we add its NT path to the shared
section and block it with `REDIRECT_TO_NOOP_ENTRYPOINT`.
4. The `main` function of the browser process converts the writable
handle of the shared section into a readonly handle.
5. The browser process transfers a readonly handle of the shared
section to a sandbox process.
Since automatic DLL blocking may still cause a compat issue like bug 1682304,
we activate it only in Nightly for now.
Differential Revision: https://phabricator.services.mozilla.com/D101460
CLOSED TREE
Backed out changeset f82f5070bee5 (bug 1205985)
Backed out changeset 89b03879ce7d (bug 1205985)
Backed out changeset 9ba60febbcf8 (bug 1205985)
32-bit Linux architectures have gained new versions of every system
call handling time values, to allow a transition to 64-bit time_t that
will continue to work after the year 2038; newer versions of glibc will
attempt them and fall back to the 32-bit path (without caching the
failure, so at best we take the overhead of handling SIGSYS).
This patch allows time64 syscalls in the same cases where we allow their
time32 versions, including the restrictions on clockid_t to prevent
interacting with other processes or threads of other processes. (I've
confirmed that the argument types match otherwise, so it's safe to reuse
the same policies.)
Differential Revision: https://phabricator.services.mozilla.com/D98693
It's a common way to check the existence of system calls. Glibc may fall
back to fstatat when statx is called, passing down the null path.
Since we handle fstatat, let's return -EFAULT the same way the real
fstatat syscall would do.
This is needed for the sandbox not to constantly crash due to this statx
call in rustc:
09c9c9f7da/library/std/src/sys/unix/fs.rs (L119-L123)
Differential Revision: https://phabricator.services.mozilla.com/D98414
The RDD process can no longer work without having access to win32k ; enabling this pref would lead to a crash on Nightly and failure to work elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D97753
This patch enables pre-spawn CIG in the RDD process.
If CIG prevents a module in the executable's Import Directory Table, Windows totally
fails to launch a process. So we add a policy rule of `SUBSYS_SIGNED_BINARY` for
all files under the directory containing the executable such as mozglue.dll, and
modules injected via Import Directory Table. The latter ones will be blocked by our
blocklist with `REDIRECT_TO_NOOP_ENTRYPOINT` (bug 1659438).
Differential Revision: https://phabricator.services.mozilla.com/D96933
The fix for bug 1660901, to handle the subset of fstatat that is
equivalent to fstat, was incomplete: it was added to the existing
hook for the file broker, so processes that don't use a broker (like
GMP) didn't get the fix. That wasn't a problem when the only use of
that feature was in content processes via GTK, but now that glibc has
reimplemented fstat that way, it's necessary for all processes.
Differential Revision: https://phabricator.services.mozilla.com/D95108
Sandbox policies handle the case of `fstatat(fd, "", AT_EMPTY_PATH|...)`
by invoking the SIGSYS handler (because seccomp-bpf can't tell if the
string will be empty when the syscall would use it), which makes the
equivalent call to `fstat`.
Unfortunately, recent development versions of glibc implement `fstat` by
calling `fstatat`, which causes unbounded recursion and stack overflow.
(This depends on the headers present at build time; see the bug for more
details.) This patch switches it to use the `fstat` (or `fstat64` on
32-bit) syscall directly.
Differential Revision: https://phabricator.services.mozilla.com/D94798
This patch introduces a class `CrossExecTransferManager` to manage the data
transfer from the current process to a remote process via `WriteProcessMemory`.
The class also encapsulates a logic to bridge the gap between two executable's
imagebase.
Differential Revision: https://phabricator.services.mozilla.com/D94652
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
Csoregi Natalia
David Parks
Simon Giesecke
Jed Davis
Jan Alexander Steffens (heftig)
Bryce Seager van Dyk
Narcis Beleuzu
Bob Owen
Haik Aftandilian
Jonathan Kew
Alexis Beingessner
Michael Goossens
Geoff Lankow
Toshihito Kikuchi
smolnar
Paul Adenot
Mihai Alexandru Michis
Gerald Squelart
Emilio Cobos Álvarez
Jean-Yves Avenard
Sylvestre Ledru
Jean-Yves Avenard
Cosmin Sabou
Philipp Ammann
Aaron Klotz
Ricky Stewart