On 32-bit x86, Linux originally used a single system call, ipc(2), for
all SysV IPC. This is similar to socketcall(2), but the arguments are
passed directly (shifted by one position) instead of indirected via
a pointer, so seccomp-bpf can filter them normally. Also similar to
socketcall(2), individual syscalls were added later (in kernel 5.1,
vs. 4.3 for socket calls), so the policy needs to handle both of them,
adjusting argument offsets as needed. This patch adds an argument to
`EvaluateIpcCall` to allow that.
Differential Revision: https://phabricator.services.mozilla.com/D131678
For running in FIPS mode, NSS needs to check /proc/sys/crypto/fips_enabled, to be able to tell whether FIPS is enabled or not.
FIPS also mandates using /dev/random instead of /dev/urandom.
Differential Revision: https://phabricator.services.mozilla.com/D129126
If we get `MSG_CTRUNC` back from `recvmsg` in this context, it means
a file descriptor couldn't be received; because the sender will never
attach too many fds, the only reasonable cause is fd exhaustion in the
receiving process. Therefore, we should return `EMFILE` ("Too many open
files") instead of `EMSGSIZE` ("Message too long") to reduce confusion
when reading log messages.
Differential Revision: https://phabricator.services.mozilla.com/D129891
This is a fairly significant update, so required a few changes to Gecko code, but I've commented on the interesting details, so they should be easy to find
Differential Revision: https://phabricator.services.mozilla.com/D129465
This adds a new cross call using the chromium shared memory IPC to proxy use of
the Uniscribe line breaker, because it cannot be used in the content process
with win32k lockdown enabled.
If the text being processed is too long to fit into the IPC params then it is
processed in chunks.
This change implements an INPTR_TYPE in the sandbox, which appears to have
been removed at some point.
It also fixes a bug in OpcodeFactory::MakeOpAction, so that a null param is
passed and we can use an empty parameter set.
New files are in chromium-shim as these are most likely to require changes and
this means we will not have to update the main chromium patch.
Depends on D129125
Differential Revision: https://phabricator.services.mozilla.com/D126809
If the `XAUTHORITY` env var is unset, libXau will fall back to
`$HOME/.Xauthority`, but our content sandbox policy didn't handle that
case when it needs to allow access to that file; this patch corrects
that oversight.
This broke WebGL as of bug 1635451, because we no longer eagerly connect
to the X server before sandbox startup, only as needed for WebGL.
Usually the `XAUTHORITY` env var is set even if the file is in its
default location, but some environments (including but not limited to
the Linux VMs on Chrome OS) do not set it.
Differential Revision: https://phabricator.services.mozilla.com/D127984
These includes provide some types and functionality that these files need. In
the default build environment, there's no issue because they pick up these
includes via piggybacking on neighboring files that they're unified with; but
in a non-unified build, the files need to directly have these includes, to
avoid build errors.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1730265#c0 for the specific
build errors being addressed here.
Differential Revision: https://phabricator.services.mozilla.com/D125285
The Widevine CDM tries to open certain procfs/sysfs files, as noted
in the bug, but doesn't appear to need them; some of them are opened
repeatedly, causing log spam. This patch suppresses logging for the
files where this is known to happen, by adding "opened file" objects
that always silently fail.
It would also be possible to turn off all of this logging by default
and make it conditional on MOZ_SANDBOX_LOGGING, but it's relatively
low-noise (compared to content process file access) and provides some
value (see bug 1725828), so for now let's leave it enabled and just
blocklist a few files.
Differential Revision: https://phabricator.services.mozilla.com/D123562
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
mozilla-central has some imported files of build_config.h from Chromium.
Actually although they doesn't have riscv64 defines yet, I would like to
add it to build Firefox for riscv64.
Differential Revision: https://phabricator.services.mozilla.com/D119051
Currently we return an error when creating a WebGL context in headless
mode, but our WebGL implementation renders to an offscreen context, so
in theory it could work normally in a headless browser, and in practice
it already does work on some OSes. This patch removes that check; the
attempt to use GL may fail, in which case we'll return an error to
content.
The main purpose of this patch is to run content processes with headless
mode set in an otherwise non-headless browser, but it should also be
useful for fully headless mode. Comments in bug NNNNNNN indicate that
this change should be sufficient for headless WebGL on Windows and MacOS,
although it may not have been extensively tested.
Linux is more complicated. The EGL/X11 backend manages its own
connection to the X server (indirectly via the EGL library); a later
patch in this series allows doing that in GLX mode as well. Our Wayland
support can't do this yet, but it should be possible.
This patch also modifies the Linux sandbox policy so that content
processes can connect to a local X server (via the file broker) even when
the parent process is in headless mode.
Differential Revision: https://phabricator.services.mozilla.com/D118721
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
Otherwise the build fails on OpenBSD:
In file included from security/sandbox/common/SandboxSettings.cpp:7:
/usr/obj/m-c/dist/include/mozilla/SandboxSettings.h:39:26: error: unknown type name 'GeckoProcessType'
bool StartOpenBSDSandbox(GeckoProcessType type);
Differential Revision: https://phabricator.services.mozilla.com/D116633
- Move the decision logic for Win32k Lockdown to a common area where it can
be re-used
- Cache the Win32k Lockdown state, since the result will never change
- Add IDL to allow JavaScript to query it
- Add it to the "about:support" page
- Add an annotation to Crash Reporter after the first time it's read
Differential Revision: https://phabricator.services.mozilla.com/D114850
Win32k Lockdown requires WebRender, but WR is not currently guaranteed
on all computers. It can also fail to initialize and fallback to
non-WR render path.
We don't want a situation where "Win32k Lockdown + No WR" occurs without
the user explicitly requesting unsupported behavior.
Differential Revision: https://phabricator.services.mozilla.com/D114849
- Move the decision logic for Win32k Lockdown to a common area where it can
be re-used
- Cache the Win32k Lockdown state, since the result will never change
- Add IDL to allow JavaScript to query it
- Add it to the "about:support" page
- Add an annotation to Crash Reporter after the first time it's read
Differential Revision: https://phabricator.services.mozilla.com/D114850
Win32k Lockdown requires WebRender, but WR is not currently guaranteed
on all computers. It can also fail to initialize and fallback to
non-WR render path.
We don't want a situation where "Win32k Lockdown + No WR" occurs without
the user explicitly requesting unsupported behavior.
Differential Revision: https://phabricator.services.mozilla.com/D114849
When doing (e.g.) `MOZ_LOG=PlatformDecoderModule:4`, ffmpeg ends up doing
`ioctl(TCGETS, ...)` via `tcgetattr`, and this crashes the RDD. We don't care
much about the result, so let's just say `ENOTTY`.
Differential Revision: https://phabricator.services.mozilla.com/D113162
This `madvise` type is used by one Linux distro's libc, and in
principle could be used by other userspace libraries trying to optimize
performance, and I'd rather not allow it (see bug for more details).
Therefore, this patch returns an error instead of treating it as an
unknown syscall (which crashes on Nightly).
However, the content policy doesn't yet filter `madvise` (bug 1510861);
this patch doesn't change that.
Differential Revision: https://phabricator.services.mozilla.com/D112884
Win32k is required for moz-icon in the file content process and we don't want to
block enabling for web content processes on this and other uses that may only be
in the file content process.
Differential Revision: https://phabricator.services.mozilla.com/D112960
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
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
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
I think since it takes an FD this might be ok, but let me know if this
somehow doesn't cut it and a more nuanced fix is needed.
Since stuff like PR_GetNumberOfProcessors() uses it with some glibc
versions, which is pretty basic functionality, we probably need to make
it work in all processes.
Differential Revision: https://phabricator.services.mozilla.com/D94358
This commit also allows `memfd_create` in the seccomp-bpf policy for all
process types.
`memfd_create` is an API added in Linux 3.17 (and adopted by FreeBSD
for the upcoming version 13) for creating anonymous shared memory
not connected to any filesystem. Supporting it means that sandboxed
child processes on Linux can create shared memory directly instead of
messaging a broker, which is unavoidably slower, and it should avoid
the problems we'd been seeing with overly small `/dev/shm` in container
environments (which were causing serious problems for using Firefox for
automated testing of frontend projects).
`memfd_create` also introduces the related operation of file seals:
irrevocably preventing types of modifications to a file. Unfortunately,
the most useful one, `F_SEAL_WRITE`, can't be relied on; see the large
comment in `SharedMemory:ReadOnlyCopy` for details. So we still use
the applicable seals as defense in depth, but read-only copies are
implemented on Linux by using procfs (and see the comments on the
`ReadOnlyCopy` function in `shared_memory_posix.cc` for the subtleties
there).
There's also a FreeBSD implementation, using `cap_rights_limit` for
read-only copies, if the build host is new enough to have the
`memfd_create` function.
The support code for Android, which doesn't support shm_open and can't
use the memfd backend because of issues with its SELinux policy (see bug
1670277), has been reorganized to reflect that we'll always use its own
API, ashmem, in that case.
Differential Revision: https://phabricator.services.mozilla.com/D90605
This commit also allows `memfd_create` in the seccomp-bpf policy for all
process types.
`memfd_create` is an API added in Linux 3.17 (and adopted by FreeBSD
for the upcoming version 13) for creating anonymous shared memory
not connected to any filesystem. Supporting it means that sandboxed
child processes on Linux can create shared memory directly instead of
messaging a broker, which is unavoidably slower, and it should avoid
the problems we'd been seeing with overly small `/dev/shm` in container
environments (which were causing serious problems for using Firefox for
automated testing of frontend projects).
`memfd_create` also introduces the related operation of file seals:
irrevocably preventing types of modifications to a file. Unfortunately,
the most useful one, `F_SEAL_WRITE`, can't be relied on; see the large
comment in `SharedMemory:ReadOnlyCopy` for details. So we still use
the applicable seals as defense in depth, but read-only copies are
implemented on Linux by using procfs (and see the comments on the
`ReadOnlyCopy` function in `shared_memory_posix.cc` for the subtleties
there).
There's also a FreeBSD implementation, using `cap_rights_limit` for
read-only copies, if the build host is new enough to have the
`memfd_create` function.
The support code for Android, which doesn't support shm_open and can't
use the memfd backend because of issues with its SELinux policy (see bug
1670277), has been reorganized to reflect that we'll always use its own
API, ashmem, in that case.
Differential Revision: https://phabricator.services.mozilla.com/D90605
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. 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
Ultimately, we should be able to remove everything that got added to the RDD sandbox from the content's one.
Fly-by fix; allow checking if AVX512 is supported in content sandbox.
Splitting sandbox setting from Utility to a new RDD one as per review comment in P12 considering it's no longer an IPC only sandbox.
Depends on D91688
Differential Revision: https://phabricator.services.mozilla.com/D91689
This commit also allows `memfd_create` in the seccomp-bpf policy for all
process types.
`memfd_create` is an API added in Linux 3.17 (and adopted by FreeBSD
for the upcoming version 13) for creating anonymous shared memory
not connected to any filesystem. Supporting it means that sandboxed
child processes on Linux can create shared memory directly instead of
messaging a broker, which is unavoidably slower, and it should avoid
the problems we'd been seeing with overly small `/dev/shm` in container
environments (which were causing serious problems for using Firefox for
automated testing of frontend projects).
`memfd_create` also introduces the related operation of file seals:
irrevocably preventing types of modifications to a file. Unfortunately,
the most useful one, `F_SEAL_WRITE`, can't be relied on; see the large
comment in `SharedMemory:ReadOnlyCopy` for details. So we still use
the applicable seals as defense in depth, but read-only copies are
implemented on Linux by using procfs (and see the comments on the
`ReadOnlyCopy` function in `shared_memory_posix.cc` for the subtleties
there).
There's also a FreeBSD implementation, using `cap_rights_limit` for
read-only copies, if the build host is new enough to have the
`memfd_create` function.
Differential Revision: https://phabricator.services.mozilla.com/D90605
This commit also allows `memfd_create` in the seccomp-bpf policy for all
process types.
`memfd_create` is an API added in Linux 3.17 (and adopted by FreeBSD
for the upcoming version 13) for creating anonymous shared memory
not connected to any filesystem. Supporting it means that sandboxed
child processes on Linux can create shared memory directly instead of
messaging a broker, which is unavoidably slower, and it should avoid
the problems we'd been seeing with overly small `/dev/shm` in container
environments (which were causing serious problems for using Firefox for
automated testing of frontend projects).
`memfd_create` also introduces the related operation of file seals:
irrevocably preventing types of modifications to a file. Unfortunately,
the most useful one, `F_SEAL_WRITE`, can't be relied on; see the large
comment in `SharedMemory:ReadOnlyCopy` for details. So we still use
the applicable seals as defense in depth, but read-only copies are
implemented on Linux by using procfs (and see the comments on the
`ReadOnlyCopy` function in `shared_memory_posix.cc` for the subtleties
there).
There's also a FreeBSD implementation, using `cap_rights_limit` for
read-only copies, if the build host is new enough to have the
`memfd_create` function.
Differential Revision: https://phabricator.services.mozilla.com/D90605
This also adds a diagonstic assert to make sure the code works in all process types.
And it adds another item to the sandbox IOKit property name allowlist, so that
the detection works in content processes.
This landed before, in bug 1649490, but without the sandbox adjustment (so it
didn't work in content processes).
Differential Revision: https://phabricator.services.mozilla.com/D91950
The ABI on ARM64 requires 16-byte stack alignment, and that includes the
small temporary stack that exists only so that we can `longjmp` off of
it in the child process after calling `clone`.
Differential Revision: https://phabricator.services.mozilla.com/D90001
In addition to e.g. lacking `open` in favor of `openat`, Linux/arm64
also removes a number of older syscalls along similar lines, like `dup2`
in favor of `dup3`, and all variants of `select` other than `pselect6`.
Differential Revision: https://phabricator.services.mozilla.com/D90000
Linux/arm64 omits syscalls that can be implemented in terms of newer
syscalls by inserting constant arguments; this means that all of the
basic filesystem operations use the `at` versions, like `unlinkat`
replacing both `unlink` and `rmdir`. We've supported some of them when
x86 libcs started using them, but there are several others we were
missing; this patch adds them.
Differential Revision: https://phabricator.services.mozilla.com/D89999
Linux/arm64 seems to exclude any syscalls that were redundant when it was
created (specifically, that can be implemented in terms of another by
inserting constant arguments), which includes all the of the non-`at`
filesystem syscalls --- for example, `open` vs. `openat`.
This patch rearranges ifdefs to handle that case; later patches will
fill in the currently unhandled syscalls in the `at`-only side.
Differential Revision: https://phabricator.services.mozilla.com/D89998
Not strictly part of ARM support, but worth committing, and in
particular printing the `AT_*` flags in hex is helpful for matching them
against headers when `*at` syscalls fail.
Differential Revision: https://phabricator.services.mozilla.com/D89997
We no longer use GConf (bug 1433685), so we can remove the sandbox rule
allowing it to call utime(). That syscall doesn't exist on ARM or ARM64,
so this rule would have to be ifdef'ed if it were re-added.
Differential Revision: https://phabricator.services.mozilla.com/D89996
Chromium's Linux sandboxing code needs some architecture-specific files
for ARM and ARM64 that we don't currently include in our partial import.
These are copied from Chromium tag 81.0.4044.138 (matching the latest
import of the rest of security/sandbox/chromium) without changes.
Differential Revision: https://phabricator.services.mozilla.com/D89994
The earlier fix ea452bb92e6a proved the executable's imagebase in a child
process is not always the same as the local imagebase. This patch applies
the new approach to retieve the imagebase from a handle to all channels.
Interestingly, we observed the launcher failures at `VirtualProtectEx` only
when launching a sandboxed process, not when launching the browser process.
In the long term, we may need to take care of all `WriteProcessMemory` calls
for a child process for greater safety, but given that observation, this
patch only updates `RestoreImportDirectory` and `InitializeDllBlocklistOOP`.
Differential Revision: https://phabricator.services.mozilla.com/D90316
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
The [[nodiscard]] attribute must precede a function declaration's declaration specifiers (like static, extern, inline, or virtual). The __attribute__((warn_unused_result)) attribute does not have this order restriction.
Differential Revision: https://phabricator.services.mozilla.com/D89235
Per the manpage "Both stat() and lstat() act as though AT_NO_AUTOMOUNT
was set.", so don't bail if it's set in a call to fstatat.
Differential Revision: https://phabricator.services.mozilla.com/D89121
This patch adds a new property `process_type` to the launcher process failure
ping, indicating which process type the browser process failed to initialize
as a sandboxed process.
Depends on D83639
Differential Revision: https://phabricator.services.mozilla.com/D83640
This fixes the following error when running on Apple Silicon DTK:
AGX: agxs_util.cpp:355:size_t getSystemMemorySize(): !!! Verification failed: status == 0
Differential Revision: https://phabricator.services.mozilla.com/D87048
Allow access to the "com.apple.trustd.agent" service in the content process sandbox. VTDecompressionSessionCreate() fails without it, causing playback failure for some MP4 videos.
Translate deprecated OS version numbers so that sandbox version checks don't need to check for 10.16.
Differential Revision: https://phabricator.services.mozilla.com/D85213
WebRender makes extensive use of shared memory buffers, particularly for
images decoded in the content process. These images can be arbitrarily
large, and there being insufficient memory for an allocation must be
handled gracefully.
On Linux, we will currently crash with a SIGBUS signal during image
decoding instead of just displaying the broken image tag. This is
because the pages backing the shared memory are only allocated when we
write to them. This blocks shipping WebRender on Linux.
This patch uses posix_fallocate to force the reservation of the pages,
and allows failing gracefully if they are unavailable.
Differential Revision: https://phabricator.services.mozilla.com/D80650
With these changes, on my Linux analysis with ClangBuildAnalyzer, the
top two expensive headers, DOMTypes.h and TabMessageUtils.h are no longer
among the 30 most expensive headers.
Differential Revision: https://phabricator.services.mozilla.com/D82935
As of kernel 5.8 (commit [e9c15badb][]), Linux will set the internal
`FMODE_NONOTIFY` flag on files that don't exist in the filesystem,
including (unnamed) pipes and sockets. Although this flag isn't
properly part of the userspace API, it will be returned by F_GETFL, so
userspace code that tries to change file flags will pass it to F_SETFL.
The implementation of `F_SETFL` has an allow list of flags userspace can
change (`SETFL_MASK`) and ignores all others, but our sandbox has a list
of flags *known* to be ignored, because currently unknown flags could
potentially be accepted by the kernel in the future.
This patch adds `FMODE_NONOTIFY` as an ignored flag.
[e9c15badb]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9c15badbb7b20ccdbadf5da14e0a68fbad51015
Differential Revision: https://phabricator.services.mozilla.com/D83205
This adds the boolean pref security.sandbox.content.headless (on Linux
only) which does two things:
1. Sets the MOZ_HEADLESS env var for content processes, so that they
don't initialize GTK and don't connect to the X server.
2. Disallows brokered access to parts of the filesystem used only for
graphics -- most critically connecting to the X11 socket itself, but
also opening GPU device nodes and the parts of sysfs used by Mesa, for
example.
This is experimental; use at your own risk.
Setting this pref will break native widgets, so it's also necessary to
set widget.disable-native-theme-for-content
Additionally, it breaks Flash and WebGL; see bug 1638466 for the latter.
Differential Revision: https://phabricator.services.mozilla.com/D81425
Now that filesystem broker policy entries that depend on prefs can be
cached in the "common" policy object, let's do this wherever possible.
Partially fixes bug 1600189.
Differential Revision: https://phabricator.services.mozilla.com/D81424
When the SandboxBrokerPolicyFactory is constructed, prefs aren't
available, which constrains the cached subset of the content process
policy to entries that don't depend on prefs. Delaying the computation
until a content process is started removes that restriction.
(This also delays the reading of dynamic linker configuration to discover
library directories, so a test needs to be adjusted.)
Differential Revision: https://phabricator.services.mozilla.com/D81423
Not strictly necessary, but I noticed this while I was making changes:
AddDynamicPathList can be a simple static function instead of a private
static method, and doesn't need to be in the header.
Differential Revision: https://phabricator.services.mozilla.com/D81422
CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
This commit does:
- Sync files under security/sandbox/chromium/ with Chromium 81.0.4044.138
- Update files under security/sandbox/chromium-shim/
- Apply patches under security/sandbox/chromium-shim/patches/with_update/
- Add mozilla::AddWin32kLockdownPolicy to apply MITIGATION_WIN32K_DISABLE before SUBSYS_WIN32K_LOCKDOWN
Differential Revision: https://phabricator.services.mozilla.com/D79560
This commit updates files under security/sandbox/chromium-shim/patches/
to prepare our codebase for Chromium sandbox update. See patch files for
the details of each patch.
This also removes the following patches from with_update no longer needed.
1) update_chromium_linux_x86_syscalls.patch is included in
b4f3df4e77
2) ifdef_out_ApplyMitigationsToCurrentThread.patch cannot be used because
we use ApplyMitigationsToCurrentThread since the following commit.
4bed2eb502
3) mingw_base_win_get_caller.patch is included in
d8b73eb8f0
4) fix_incorrect_int_use_in_Kernel32BaseVersion.patch is fixed by
https://hg.mozilla.org/mozilla-central/rev/dc9d71fb3bac807a37dbfba35d609ac4ffff1980
5) revert_removal_of_AlterEnvironment_on_Windows.patch is altered by adding
environment_internal.h/cc as a different commit.
6) mingw_undefine_MemoryBarrier.patch is no longer needed as
base::subtle::MemoryBarrier was removed by
bdbaaf4e7e
7) public_siginfo_fields.patch is included in
6bd491daaf
Differential Revision: https://phabricator.services.mozilla.com/D79558
This commit does:
- Sync files under security/sandbox/chromium/ with Chromium 81.0.4044.138
- Update files under security/sandbox/chromium-shim/
- Apply patches under security/sandbox/chromium-shim/patches/with_update/
- Apply a workaround for Clang's bug to compile *_interception.cc
- Add mozilla::AddWin32kLockdownPolicy to apply MITIGATION_WIN32K_DISABLE before SUBSYS_WIN32K_LOCKDOWN
Differential Revision: https://phabricator.services.mozilla.com/D79560
This commit updates files under security/sandbox/chromium-shim/patches/
to prepare our codebase for Chromium sandbox update. See patch files for
the details of each patch.
This also removes the following patches from with_update no longer needed.
1) update_chromium_linux_x86_syscalls.patch is included in
b4f3df4e77
2) ifdef_out_ApplyMitigationsToCurrentThread.patch cannot be used because
we use ApplyMitigationsToCurrentThread since the following commit.
4bed2eb502
3) mingw_base_win_get_caller.patch is included in
d8b73eb8f0
4) fix_incorrect_int_use_in_Kernel32BaseVersion.patch is fixed by
https://hg.mozilla.org/mozilla-central/rev/dc9d71fb3bac807a37dbfba35d609ac4ffff1980
5) revert_removal_of_AlterEnvironment_on_Windows.patch is altered by adding
environment_internal.h/cc as a different commit.
6) mingw_undefine_MemoryBarrier.patch is no longer needed as
base::subtle::MemoryBarrier was removed by
bdbaaf4e7e
7) public_siginfo_fields.patch is included in
6bd491daaf
Differential Revision: https://phabricator.services.mozilla.com/D79558
This commit does:
- Sync files under security/sandbox/chromium/ with Chromium 81.0.4044.138
- Update files under security/sandbox/chromium-shim/
- Apply patches under security/sandbox/chromium-shim/patches/with_update/
- Apply a workaround for Clang's bug to compile *_interception.cc
- Add mozilla::AddWin32kLockdownPolicy to apply MITIGATION_WIN32K_DISABLE before SUBSYS_WIN32K_LOCKDOWN
Differential Revision: https://phabricator.services.mozilla.com/D79560
This commit updates files under security/sandbox/chromium-shim/patches/
to prepare our codebase for Chromium sandbox update. See patch files for
the details of each patch.
This also removes the following patches from with_update no longer needed.
1) update_chromium_linux_x86_syscalls.patch is included in
b4f3df4e77
2) ifdef_out_ApplyMitigationsToCurrentThread.patch cannot be used because
we use ApplyMitigationsToCurrentThread since the following commit.
4bed2eb502
3) mingw_base_win_get_caller.patch is included in
d8b73eb8f0
4) fix_incorrect_int_use_in_Kernel32BaseVersion.patch is fixed by
https://hg.mozilla.org/mozilla-central/rev/dc9d71fb3bac807a37dbfba35d609ac4ffff1980
5) revert_removal_of_AlterEnvironment_on_Windows.patch is altered by adding
environment_internal.h/cc as a different commit.
6) mingw_undefine_MemoryBarrier.patch is no longer needed as
base::subtle::MemoryBarrier was removed by
bdbaaf4e7e
7) public_siginfo_fields.patch is included in
6bd491daaf
Differential Revision: https://phabricator.services.mozilla.com/D79558
The current taskqueue is blocked until the current function has finished; Running the event loop would only process events on the running thread.
Additionally, we make mIPCLaunchThread an nsISerialEventTarget to guarantee that at shutdown the tasks are run in order regardless of the IPC Launch Thread type.
Differential Revision: https://phabricator.services.mozilla.com/D81511
This adds the boolean pref security.sandbox.content.headless (on Linux
only) which does two things:
1. Sets the MOZ_HEADLESS env var for content processes, so that they
don't initialize GTK and don't connect to the X server.
2. Disallows brokered access to parts of the filesystem used only for
graphics -- most critically connecting to the X11 socket itself, but
also opening GPU device nodes and the parts of sysfs used by Mesa, for
example.
This is experimental; use at your own risk.
Setting this pref will break native widgets, so it's also necessary to
set widget.disable-native-theme-for-content
Additionally, it breaks Flash and WebGL; see bug 1638466 for the latter.
Differential Revision: https://phabricator.services.mozilla.com/D81425
Now that filesystem broker policy entries that depend on prefs can be
cached in the "common" policy object, let's do this wherever possible.
Should also fix bug 1621231.
Differential Revision: https://phabricator.services.mozilla.com/D81424
When the SandboxBrokerPolicyFactory is constructed, prefs aren't
available, which constrains the cached subset of the content process
policy to entries that don't depend on prefs. Delaying the computation
until a content process is started removes that restriction.
Differential Revision: https://phabricator.services.mozilla.com/D81423
Not strictly necessary, but I noticed this while I was making changes:
AddDynamicPathList can be a simple static function instead of a private
static method, and doesn't need to be in the header.
Differential Revision: https://phabricator.services.mozilla.com/D81422
Fix the content and Flash sandbox policies to use the major and minor number for OS version checks allowing video playback to work properly on macOS 11 Big Sur.
Pass the macOS major and minor version to sandbox policies as a combined string.
Remove unused OSXVersion methods and members and more minor cleanup in Sandbox.mm.
Leave in the checks for unsupported versions (macOS 10.9 - 10.11) for now in case this fix needs to be uplifted.
Differential Revision: https://phabricator.services.mozilla.com/D81385
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
This commit does:
- Sync files under security/sandbox/chromium/ with Chromium 81.0.4044.138
- Update files under security/sandbox/chromium-shim/
- Apply patches under security/sandbox/chromium-shim/patches/with_update/
- Apply a workaround for Clang's bug to compile filesystem_interception.cc
- Add mozilla::AddWin32kLockdownPolicy to apply MITIGATION_WIN32K_DISABLE before SUBSYS_WIN32K_LOCKDOWN
Depends on D79558
Differential Revision: https://phabricator.services.mozilla.com/D79560
This commit updates files under security/sandbox/chromium-shim/patches/
to prepare our codebase for Chromium sandbox update. See patch files for
the details of each patch.
This also removes the following patches from with_update no longer needed.
1) update_chromium_linux_x86_syscalls.patch is included in
b4f3df4e77
2) ifdef_out_ApplyMitigationsToCurrentThread.patch cannot be used because
we use ApplyMitigationsToCurrentThread since the following commit.
4bed2eb502
3) mingw_base_win_get_caller.patch is included in
d8b73eb8f0
4) fix_incorrect_int_use_in_Kernel32BaseVersion.patch is fixed by
https://hg.mozilla.org/mozilla-central/rev/dc9d71fb3bac807a37dbfba35d609ac4ffff1980
5) revert_removal_of_AlterEnvironment_on_Windows.patch is altered by adding
environment_internal.h/cc as a different commit.
6) mingw_undefine_MemoryBarrier.patch is no longer needed as
base::subtle::MemoryBarrier was removed by
bdbaaf4e7e
7) public_siginfo_fields.patch is included in
6bd491daaf
Differential Revision: https://phabricator.services.mozilla.com/D79558
converts:
* security.sandbox.rdd.win32k-disable
* security.sandbox.gmp.win32k-disable
I'm assuming the pattern established by the other, newer, win32k StaticPrefs can
be followed here, and the xpcom checks aren't needed.
Differential Revision: https://phabricator.services.mozilla.com/D78933
Content processes allow a restricted subset of F_{GET,SET}{FD,FL} that
prevents setting unknown or known-unsafe flags, which was copied to the
socket process policy; this patch moves it to the common policy and
removes RDD's copy of GMP's override.
The immediate reason for this is DMD using F_GETFL via fdopen to use a
file descriptor passed over IPC, but in general this should be safe and
it's a reasonable thing to expect to be able to use.
Differential Revision: https://phabricator.services.mozilla.com/D77379
When the browser process starts a sandbox process, we copy the executable's IAT
for ntdll.dll into the new process to prevent DLL injection via IAT tampering as
the launcher process does. However, if IAT has been modified by a module injected
via `SetWindowHookEx`, the browser process cannot copy IAT because a modified IAT
is invalid in a different process, failing to start any sandbox processes.
The proposed fix is to cache IAT before COM initialization which may load
modules via `SetWindowHookEx` for the first time in the process.
Differential Revision: https://phabricator.services.mozilla.com/D73303
If a third-party application modifies IAT of ntdll.dll in the browser process
after process launch, the browser process fails to launch a sandbox process,
resulting in a situation where a window is opened without any functionality.
This patch is to mitigate that situation by disabling the launcher process
when the browser process fails to launch a sandbox process.
Differential Revision: https://phabricator.services.mozilla.com/D70873
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
When the GPU sandbox is enabled, access to most of the filesystem is blocked.
The GPU process uses a directory, "%profiledir%/shader-cache", to cache
compiled shared for performance reasons. Not allowing access to that directory
results in a HUGE performance backslide when the sandbox is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D67893
--HG--
extra : moz-landing-system : lando
Add rule to allow content processes to duplicate named pipes to other child
processes. This is why SetLockdownDefaultDacl wasn't working before because it
broke the local handle duplication.
This also reverts the change that was using USER_LIMITED from the start of the
process because that breaks DLL loading when installed somewhere that relies on
the user's own SID for access.
Differential Revision: https://phabricator.services.mozilla.com/D68850
--HG--
extra : moz-landing-system : lando
We've had some bugs where the sandboxed child process and/or the chroot
helper process deadlocks during launch, often reported by end users,
and it's confusing to have the mysterious hanging task inherit the name
of the launching thread; this patch fixes that by giving them more
informative names.
`prctl(PR_SET_NAME, ...)` is used directly, instead of via one of our
wrappers for it, to avoid the possibility of async signal unsafe
operations.
This doesn't name the pre-exec child process in the cases where regular
`fork()` is used, but as far as I know we haven't had any bugs (yet?)
where that would matter.
Differential Revision: https://phabricator.services.mozilla.com/D68134
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
When the launcher process is enabled, we run `RestoreImportDirectory` twice as
below. This patch removes the 1st one.
1st call:
xul!mozilla::SandboxBroker::LaunchApp
--> xul!mozilla::RestoreImportDirectory
2nd call:
xul!mozilla::SandboxBroker::LaunchApp
--> firefox!mozilla::InitializeDllBlocklistOOP
--> firefox!mozilla::InitializeDllBlocklistOOPInternal
--> firefox!mozilla::RestoreImportDirectory
To handle the case where the launcher process is disabled, we need to call
`RestoreImportDirectory` from `InitializeDllBlocklistOOP` if the browser
process is not bootstrapped.
Differential Revision: https://phabricator.services.mozilla.com/D62853
--HG--
extra : moz-landing-system : lando
The special handling of PR_SET_NO_NEW_PRIVS can't be overridden with
Allow(); otherwise every thread in the process will repeatedly apply
copies of the policy to itself until it reaches whatever limits the
kernel imposes, and then we crash so we don't continue execution
seemingly unsandboxed. (See also bug 1257361.)
The prctl policy for the socket process is still allow-all after this
patch; it just prevents crashing the socket process on startup on
kernels before 3.17 (which don't support applying the policy atomically
to all threads).
This patch also adds a comment to try to document this failure mode.
Differential Revision: https://phabricator.services.mozilla.com/D66523
--HG--
extra : moz-landing-system : lando
This adds AddRestrictingRandomSid feature, which fixes our issues with
SetLockdownDefaultDacl, apart from when we are running from a network drive.
Differential Revision: https://phabricator.services.mozilla.com/D66610
--HG--
extra : moz-landing-system : lando
Jed Davis
M. Sirringhaus
Jon Bauman
Bob Owen
Florian Quèze
Haik Aftandilian
Kershaw Chang
Cristian Tuns
Olivier Tilloy
Jens Stutte
Marian-Vasile Laza
Alexandre Lissy
Csoregi Natalia
Daniel Holbert
Ben Hearsum
Mark Banner
Emilio Cobos Álvarez
Andi-Bogdan Postelnicu
Alexandre Lissy
stransky
Makoto Kato
Nika Layzell
Butkovits Atila
Landry Breuil
David Parks
Joel Maher
Chris Martin
Mike Hommey
Paul Adenot
smolnar
Simon Giesecke
Jan Alexander Steffens (heftig)
Bryce Seager van Dyk
Narcis Beleuzu
Jonathan Kew
Alexis Beingessner
Michael Goossens
Geoff Lankow
Toshihito Kikuchi
Mihai Alexandru Michis
Gerald Squelart
Jean-Yves Avenard
Sylvestre Ledru
Jean-Yves Avenard
Cosmin Sabou
Philipp Ammann
Aaron Klotz
Ricky Stewart
Bogdan Tara
Dorel Luca
Razvan Maries
Bert Peers
Chris Peterson
Julien Cristau
Andrew Osmond
Kris Maglione
Noemi Erli
Gian-Carlo Pascutto
Jeff Gilbert
Gabriele Svelto
Michael Froman
Brindusan Cristian