On multi-GPU systems, even though the GPU we're going to use for
accelerated video decoding is driven by Mesa, sometimes the nvidia
proprietary driver can be loaded and attempt to probe devices. This
patch attempts to make the sandbox policy quietly return errors for
those syscalls, instead of treating them as unexpected (and crashing on
Nightly).
Differential Revision: https://phabricator.services.mozilla.com/D149652
There are two parts to this patch; both affect only Linux:
1. The GMP sandbox policy is adjusted to allow certain syscalls used in
shared memory creation (ftruncate and fallocate). However, the file
broker is not used; the process still has no access to files in /dev/shm.
2. The profiler is not initialized for GMP processes unless memfd_create
is available (so the process can create shared memory to send
profiling data back, without filesystem access), or the GMP sandbox
is disabled (either at runtime or build time).
As of this patch, profiling GMP processes on Linux should succeed on
distros with kernel >=3.17 (Oct. 2014), but native stack frames won't
have symbols (and may be incorrectly unwound, not that it matters much
without symbols); see the bug for more info. Pseudo-stack frames and
markers should work, however.
Differential Revision: https://phabricator.services.mozilla.com/D148470
The profiler may try to readlink `/proc/self/exe` to determine the
executable name; currently, its attempt to get information about loaded
objects is broken for other reasons, so this isn't helpful. Thus, this
patch has it fail with `EINVAL` (meaning "not a symbolic link) instead of
being treated as unexpected.
(In the future, if we need to, we could simulate that syscall by
recording the target of `/proc/self/exe` before sandboxing, and
recognizing that specific case in a trap function.)
Differential Revision: https://phabricator.services.mozilla.com/D148469
The patch for bug 1769499 lets the RDD process create a headless EGL
context using GBM, which needs access only to the GPU device files, not
the display server. This means that the X11 access recently added in
bug 1769182 can be turned back off.
Differential Revision: https://phabricator.services.mozilla.com/D147792
This patch mostly turns on the features set up by the earlier patches:
allow connecting to the X server and reading various related things
(.Xauthority, GPU device info in sysfs, etc.). It also turns off Mesa's
shader cache in the RDD process; that shouldn't be needed here, and
disabling it lets us avoid dealing with a few things in the sandbox
policy that we'd rather not (e.g., `getpwuid`).
Differential Revision: https://phabricator.services.mozilla.com/D146275
#including ApplicationServices.h within `namespace ApplicationServices` indirectly causes emmintrin.h to also be #included in namespace ApplicationServices in non-unified builds.
In file included from security/sandbox/common/test/SandboxTestingChild.cpp:12:
In file included from objdir-x86_64-apple-darwin21.4.0-clang-mozbuild/dist/include/mozilla/ipc/UtilityProcessChild.h:10:
In file included from objdir-x86_64-apple-darwin21.4.0-clang-mozbuild/dist/include/mozilla/ipc/UtilityAudioDecoderParent.h:9:
In file included from objdir-x86_64-apple-darwin21.4.0-clang-mozbuild/ipc/ipdl/_ipdlheaders/mozilla/PRemoteDecoderManagerParent.h:23:
In file included from objdir-x86_64-apple-darwin21.4.0-clang-mozbuild/dist/include/PlatformDecoderModule.h:23:
In file included from objdir-x86_64-apple-darwin21.4.0-clang-mozbuild/dist/include/mozilla/layers/KnowsCompositor.h:10:
In file included from objdir-x86_64-apple-darwin21.4.0-clang-mozbuild/dist/include/mozilla/layers/LayersTypes.h:14:
In file included from objdir-x86_64-apple-darwin21.4.0-clang-mozbuild/dist/include/Units.h:19:
objdir-x86_64-apple-darwin21.4.0-clang-mozbuild/dist/include/nsRect.h:294:26: error: unknown type name '__m128i'; did you mean 'ApplicationServices::__m128i'?
static MOZ_ALWAYS_INLINE __m128i floor_ps2epi32(__m128 x) {
^~~~~~~
ApplicationServices::__m128i
/Users/chris/.mozbuild/clang/lib/clang/14.0.1/include/emmintrin.h:20:19: note: 'ApplicationServices::__m128i' declared here
typedef long long __m128i __attribute__((__vector_size__(16), __aligned__(16)));
Differential Revision: https://phabricator.services.mozilla.com/D145516
Background: When 32-bit types are passed in registers on x86-64 (and
probably other platforms?), the function call ABI does not specify the
contents of the upper half, and the Linux kernel syscall ABI appears to
have the same behavior.
In practice, the upper half is usually zero (or maybe sign-extended from
the lower half), because 64-bit operations aren't cheaper than 32-bit,
and 32-bit operations zero-extend their outputs; therefore, this case
usually doesn't happen in the first place, and any kind of spill or
register move will zero the upper half. However, arbitrary values are
possible, and a case like this has occurred with the Firefox profiler
using `clock_gettime`. (This paragraph is applicable to x86-64 and
ARM64; other 64-bit architecutures may behave differently.)
But the Chromium seccomp-bpf compiler, when testing the value of a 32-bit
argument on a 64-bit platform, requires that the value be zero-extended
or sign-extended, and (incorrectly, as far as I can tell) considers
anything else an ABI violation.
With this patch, when that case is detected, we use the `SIGSYS` handler
to zero-extend the problematic argument and re-issue the syscall.
(It would also be possible to just ignore the upper half, and that would
be faster, but that could lead to subtle security holes if the type
used in `bpf_dsl` is incorrect and the kernel really does treat it as
64-bit.)
Differential Revision: https://phabricator.services.mozilla.com/D143964
Background: When 32-bit types are passed in registers on x86-64 (and
probably other platforms?), the function call ABI does not specify the
contents of the upper half, and the Linux kernel syscall ABI appears to
have the same behavior.
In practice, the upper half is usually zero (or maybe sign-extended from
the lower half), because 64-bit operations aren't cheaper than 32-bit,
and 32-bit operations zero-extend their outputs; therefore, this case
usually doesn't happen in the first place, and any kind of spill or
register move will zero the upper half. However, arbitrary values are
possible, and a case like this has occurred with the Firefox profiler
using `clock_gettime`. (This paragraph is applicable to x86-64 and
ARM64; other 64-bit architecutures may behave differently.)
But the Chromium seccomp-bpf compiler, when testing the value of a 32-bit
argument on a 64-bit platform, requires that the value be zero-extended
or sign-extended, and (incorrectly, as far as I can tell) considers
anything else an ABI violation.
With this patch, when that case is detected, we use the `SIGSYS` handler
to zero-extend the problematic argument and re-issue the syscall.
(It would also be possible to just ignore the upper half, and that would
be faster, but that could lead to subtle security holes if the type
used in `bpf_dsl` is incorrect and the kernel really does treat it as
64-bit.)
Differential Revision: https://phabricator.services.mozilla.com/D143964
Recently bug 1753305 introduced the use of the getcpu syscall to add
this information to a profiler marker, but didn't allow this syscall
from the sandbox. In most situations this syscall doesn't happen because
of the VDSO mechanism. However in the cases where VDSO isn't used such
as running under rr, the sandbox crashes the process when starting the
profiler.
Thanks :padenot, :lissyx, :jcristau for all the help.
Differential Revision: https://phabricator.services.mozilla.com/D139712
Background: The X11 protocol has a very permissive security model;
clients have essentially full access to the windows of other clients,
and to global resources like input devices. Previously, our sandbox
policy for content processes needed to allow access to the X server;
this limited its effectiveness against a dedicated attacker.
This patch turns on the `security.sandbox.content.headless` pref added
in bug 1640345, which removes the sandbox policy rules that allowed
making new X11 connections, as well as opening the Xauthority file,
reading hardware info needed by Mesa, etc. It also runs content
processes in headless mode (whence the name) so they won't connect to a
display server at startup.
This also removes access to the Wayland compositor: the sandbox policy
never allowed that (as of when socket connections became default-deny),
but now content processes won't connect to it at startup. Wayland is
more capability-oriented so this is less significant for security, but at
a minimum it removes unnecessary attack surface.
Note that if the `webgl.out-of-process` pref is turned off, WebGL
will break unless `security.sandbox.content.headless` is also turned
off. (Similarly, `widget.non-native-theme.enabled` is needed to render
scrollbars and form controls in content.) As a result, this patch
adjusts the job definitions used by CI to test in-process WebGL so that
that they will continue to work.
Differential Revision: https://phabricator.services.mozilla.com/D138613
This is used by the new code from the profiler that is able to detect
unregistered threads. Blocking it will make child-process hit sandbox
violation.
Differential Revision: https://phabricator.services.mozilla.com/D135648
The original SandboxTesting protocol assumed tests would just care about
whether operations succeeded or failed, but now we have tests that check
for specific error codes. Currently that doesn't work well: getting an
error with the wrong error code is misreported as the syscall succeeding.
This patch changes the protocol to simply indicate whether the test
passed and give an unstructured message about what happened, and fixes
the `SandboxTestingChild::*Test` methods to include the relevant
information in the message.
Differential Revision: https://phabricator.services.mozilla.com/D132853
Currently, there are situations where Remote WebGL is disabled due to
lack of HW support (For example, if it is run in a Virtual Machine)
This makes it so that the WebGL remoting is enabled anyway, since it is
needed for Win32k Lockdown.
Differential Revision: https://phabricator.services.mozilla.com/D135650
Currently, there are situations where Remote WebGL is disabled due to
lack of HW support (For example, if it is run in a Virtual Machine)
This makes it so that the WebGL remoting is enabled anyway, since it is
needed for Win32k Lockdown.
Differential Revision: https://phabricator.services.mozilla.com/D135649
In some cases (doing video decode on the CPU and uploading the result
with dmabuf) we'll need to use `DMA_BUF_IOCTL_SYNC` in the RDD process.
This patch allows that ioctl type ('b', used only by dmabuf and Android
binder; the latter doesn't apply on Desktop), for forward compatibility
with any future usage of dmabuf ioctls.
Differential Revision: https://phabricator.services.mozilla.com/D133715