When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : intermediate-source : 46a6f9d0773ba2d756d8801cee79bfa994165d44
extra : absorb_source : a725a095946946797fd4f3abe6461e810b15d899
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : 958212e804df7f9e1be6af182e73edc956b9a576
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : dc1c7c8015e0443eed218f826fda9f5b38b3e062%2C4cfa2f90104ca3e907607d884ac86f73ad4995bf
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : rebase_source : f5de7462438e33cf4983be3fcef3c781c25ec492
extra : absorb_source : 9f9861546fc0b11333e575bb3c164dfe07575d99
The current code is a bit of a mess. This patch does the following.
- Changes the processing from backwards to forwards. This avoids the need for
all the `found` booleans, because if a flag is present multiple times, the
last one will naturally override.
- Tightens up the checking. It now doesn't use assertions, but instead returns
false if any of the options are missing arguments, or have malformed
arguments, or any of the mandatory flags are missing. (It assumes that
-appdir and -profile are optional.)
- Renames the loop variable `idx` as `i`.
- Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer.
- Avoids a redundant nsCString when handling -appdir.
The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It
holds the appModelUserId argument, which XRE_InitChildProcess() always expects
is present in the command. But it's only set to a non-empty value in
InitWindowsGroupID(), which is only called for plugin processes. So in lots of
cases the appModelUserId argument was missing, and a different argument would
be interpreted as the appModelUserId argument (seemingly without noticeable ill
effect).
The patch changes things to mGroupId defaults to "-", which means it's always
present in the command.
Note: all this explains why the old code for ContentProcess::Init() started
processing from argument aArgc, instead of aArgc-1 as you might expect -- it
had to read one extra arg in order to see the argument following -appdir,
because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId
argument even when that argument wasn't present. The new code for
ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId
fix ensures the appModelUserId argument is always present.
MozReview-Commit-ID: 8a8k6ABYMgo
--HG--
extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
All prefs that need to be sent to a new content process are now put into the
shared memory segment, and they are identified by the pref name instead of an
index into a list. The old IPC used at process startup (in XPCOMInitData) is
removed.
Benefits:
- It removes the need for the early prefs list
(dom/ipc/ContentProcesses.{h,cpp}) and the associated checking, which is ugly
and often trips people up (e.g. bug 1432979, bug 1439406).
- Using prefnames instead of indices fixes some fragility (fixing bug 1419432).
- It fixes the problem of early prefs being installed as unlocked default
values even if they are locked and/or have user values.
MozReview-Commit-ID: FRIzHF8Tjd
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
This code is used to detect too-early accesses of prefs in content processes.
The patch makes the following changes.
- New terminology: "early" prefs are those sent via the command line; "late"
prefs are those sent via IPC. Previously the former were "init" prefs and the
latter didn't have a clear name.
- The phase tracking and checking is now almost completely encapsulated within
Preferences.cpp. The only exposure to outside code is via the
AreAllPrefsSetInContentProcess() method, which has a single use.
- The number of states tracked drops from 5 to 3. There's no need to track the
beginning of the pref-setting operations, because we only need to know if
they've finished. (This also avoids the weirdness where we could transition
from END_INIT_PREFS back to BEGIN_INIT_PREFS because of the way -intPrefs,
-boolPrefs and -stringPrefs were parsed separately.)
MozReview-Commit-ID: IVJWiDxdsDV
--HG--
extra : rebase_source : 8cee1dcbd40847bf052ca9e2b759dd550350e5a1
This makes the IPC messages a little bigger, but that's unavoidable.
MozReview-Commit-ID: 1oPz2Yjjd9y
--HG--
extra : rebase_source : 0cff8cf5b25f66b73f6864ce50c1e5f575026ec3
It represents a pref, so `Pref` is a better name. Within Preferences.cpp the
patch uses domPref/aDomPref to distinguish it from PrefHashEntry values.
MozReview-Commit-ID: HXTl0GX4BtO
--HG--
extra : rebase_source : c1e0726c55e7577720f669f0ed2dbc38627d853e
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
In some unknown circumstance, possibly if the parent process has a
different version than the child process, the child does not receive
scheduler prefs, which makes it read out of an uninitialized local
variable. This can probably happen because the scheduler prefs are
checked before we do the ContentChild::Init version check. Bill also
suggested that the pref env var might be getting truncated.
This patch improves on the situation by using null for the prefs array
if none was sent, and falling back on the default values, which leave
the scheduler disabled.
This also checks that the pref string is at least long enough to avoid
a buffer overflow. Note that if the end of the string isn't an integer
we'll end up with an sPrefThreadCount of zero, which can't be good.
MozReview-Commit-ID: ByHLFMEpgyZ
--HG--
extra : rebase_source : 8f6368b88ec3746f4d1c7716a962bb2ac3c2f3b5
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : cd5a853c46a5cd334504b339bef8df30a3cabe51
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : 1a26ffc5b9f80e6df4c37c23f506e907ba44053a
When a subprocess is launched, gfxVars updates (for non-default values) are
serialized and passed on the command line, up to a limit of 1023 characters,
and ensuring it should not overflow the command line size.
When the child starts, the command line parameter is given to gfxVars, so the
updates can be used during gfxVars::Initialize(), instead of doing a sync
request to the parent.
In case the updates are not sent, or in the unlikely case the child cannot
parse them, we fallback to the sync request -- The former case should be rare
enough that a slow sync request is acceptable: It should only happen if D3D
block-list is *modified* (most people would either use the default, or just
overwrite these prefs with short strings.)
MozReview-Commit-ID: 6MoJC0fe59Q
--HG--
extra : rebase_source : cdc2e451783160c579b8fc84050e8457c600523e
the << operator of std:stringstream is occationally hanging on Windows 7 PGO builds, this uses nsPrintfCString to do formatting rather than stringstreams and replaces the std::string with nsFixedCSting for string building
Nathan Froyd
Ehsan Akhgari
Kershaw Chang
Andreea Pavel
Sylvestre Ledru
Haik Aftandilian
Narcis Beleuzu
Tiberius Oros
Brian Hackett
Kris Maglione
Brindusan Cristian
Margareta Eliza Balazs
Stephen A Pohl
Nicholas Nethercote
Alex Gaynor
shindli
Andrew McCreight
Bill McCloskey
Sebastian Hengst
Phil Ringnalda
Gerald Squelart
Brad Lassey
Dave Townsend
Masatoshi Kimura