-
Notifications
You must be signed in to change notification settings - Fork 15.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support mixed-sandbox mode on linux #15870
Conversation
5bdce3e
to
b0b66bf
Compare
a137eea
to
b34e727
Compare
@nornagon would it make sense to keep two zygotes? one sandboxed and one non-sandboxed? |
possibly, but it would be a rather more involved change and it's not clear to me that the zygote is providing substantial value other than optimizing sandbox setup (see e.g. rsesek's comment here). It may indeed be a worthwhile improvement, but without data to back it up I don't think it's worth going through the effort of supporting a 2nd zygote. If we were to go down the 2-zygote path, we'd also want to consider lazily initializing the zygotes, so that if an app is using all-sandboxed or all-unsandboxed renderers, they don't have to pay the memory cost of an additional process. |
b34e727
to
398e9fc
Compare
ping @zcbenz @deepak1556, this is ready for review :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Can we have a tracking issue for #15870 (comment) ? Could lead to a potential enhancement. |
I don't think it makes sense to have a tracking issue at this time, given we haven't even evaluated whether it would be an improvement or not. |
The tracking issue in my mind was for this specifically (evaluate the perf benefits of having a zygote), don't want it to get lost in PR comments :) |
want it to get lost in the issue tracker instead? :D |
Release Notes Persisted
|
Merging even though I still have some concerns about the way this might interact with site-per-process, we can revert / fix forward if we discover issues. |
Description of Change
This adds a patch to Chromium to allow mixing
--no-zygote
renderers with regular zygote-launched renderers.This currently only works when launching the app with
--enable-mixed-sandbox
on the command line—when using theapp.enableMixedSandbox
API, the zygote process is launched before the JS initialization code is run, and thus fails to pick up the mixed-sandbox flag and launches with--no-sandbox
, resulting in a weird mix of zygote-launched and non-zygote-launched renderers all of which are without sandbox. My preferred fix for that problem is to remove the--enable-mixed-sandbox
flag and have it be the default (overridden by--no-sandbox
or--enable-sandbox
).I'm not exactly sure how this will interact with site-per-process and navigation. In particular, will this behave correctly if you load
a.com
in a sandboxed renderer and then navigate tob.com
with site-per-process enabled? (Further, what's the status of site-per-process? cc @ppontes)Checklist
npm test
passesRelease Notes
Notes: mixed-sandbox mode works on Linux