[dev-servo] Questions about constellation, sandboxing and multiprocess
I'd like to have a better understanding of how sandboxing and multiprocess work. First, is multiprocess and sandboxing actively supported? Is Servo tested with the "-M -S" options? What's the status of the sandbox? Is there any reasons for these options to not be turned on by default? Do we want to enable "-M -S" for browserhtml? Would that help? I'd like to understand what is not part of the sandboxed content process. I guess compositor code and anything GPU and window related is not sandboxed so it runs in the main process. How does a sync call to localStorage work in a sandboxed process? Where is networking code executed? I'm trying to understand the relation between a constellation, iframes and a sandboxed process. I would naively expect to have one process per constellation, but apparently, it's one process per iframe. If I'm not mistaken, today in browserhtml, we have only one constellation. I imagine in the future there would be one sandboxed process per constellation, one constellation per group of tabs of the same domain, and one constellation for browserhtml. Thanks. -- Paul ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox
Hi, On Wed, Jun 22, 2016 at 09:57:22AM -0700, Bobby Holley wrote: > In a bit more detail, there are basically 3 ways to manage CI: > (1) The mozilla-inbound model (land possibly-untested stuff, run CI > post-commit, perform backouts and close tree as necessary) > (2) The bors/homu model (run the full suite on the precise commit that will > be merged, and only merge it when green) > (3) The relaxed bors/homu model: Run CI in parallel on pending commits. Any > mergable commits with "recent enough" green CI runs can be merged. We do > additional periodic post-merge CI runs on the master branch to spot the > occasional intra-commit bustage. This is a bit late to the discussion; but I have been wondering for a while: can't we just pipeline the final pre-commit tests? I.e. whenever a PR is approved, it is merged on top of the current auto-commit queue and tests are started, *even if tests for a previous PR are still running*. As long as tests pass on all PRs, everything can be merged without delays. (There are several options how to handle test runs finishing out of order -- but that's a detail not fundamental to the core idea.) When a test run actually does fail, the offending PR is dropped from the auto queue; those that came after it are automatically flushed and requeued. This means the worst case is lots of failing tests, in which case we would effectively degenerate to (2) -- however, failures at this stage should actually be quite rare, as most problems are already caught by the pre-approval tests. Most of the time, we should be way faster, on the same order as (3). I believe this should preserve all the important properties of (2), while avoiding the mess from post-merge failures in (3). Thoughts? -antrik- ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox
This sounds like a useful optimization; and it can be applied to the system after it is set up. I believe that the autoland model works like this anyway, though I'm not 100% sure. But we could do this on the Servo side. -Manish Goregaokar ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Questions about constellation, sandboxing and multiprocess
The constellation is the process manager; as far as Servo is concerned, there is only one constellation in the entire universe. What we have is one-process-per-Origin, since iframes within the same Origin are able to share JavaScript objects directly. On Tue, Aug 2, 2016 at 12:46 AM Paul Rouget wrote: > I'd like to have a better understanding of how sandboxing and multiprocess > work. > > First, is multiprocess and sandboxing actively supported? > Is Servo tested with the "-M -S" options? > What's the status of the sandbox? > Is there any reasons for these options to not be turned on by default? > Do we want to enable "-M -S" for browserhtml? Would that help? > > I'd like to understand what is not part of the sandboxed content process. > I guess compositor code and anything GPU and window related is not > sandboxed so it runs in the main process. > How does a sync call to localStorage work in a sandboxed process? > Where is networking code executed? > > I'm trying to understand the relation between a constellation, iframes > and a sandboxed process. I would naively expect to have one process > per constellation, but apparently, it's one process per iframe. If I'm > not mistaken, today in browserhtml, we have only one constellation. I > imagine in the future there would be one sandboxed process per > constellation, one constellation per group of tabs of the same domain, > and one constellation for browserhtml. > > Thanks. > > -- Paul > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Questions about constellation, sandboxing and multiprocess
> First, is multiprocess and sandboxing actively supported? I tested this right before the nightly release, and it was working fine and didn't seem to have bad performance. Note that you can run -M or -M and -S, but not -S by itself (which doesn't make sense). Also note that -M and -S probably don't work on Windows or Android currently. > Is Servo tested with the "-M -S" options? We do not have automated testing of these yet. > What's the status of the sandbox? Should work on Mac and Linux, but hasn't been audited. > Is there any reasons for these options to not be turned on by default? They should be, although I think we wanted to fix perf issues running the WPT suite and get all the platforms working first. We should probably test both configurations. > Do we want to enable "-M -S" for browserhtml? Would that help? I wanted to have this for the nightly, but didn't have time to test. If it works and has decent performance we can switch to having these be on. > I'd like to understand what is not part of the sandboxed content process. > I guess compositor code and anything GPU and window related is not > sandboxed so it runs in the main process. > How does a sync call to localStorage work in a sandboxed process? > Where is networking code executed? The thing that lives in the extra processes (which are sandboxed) are the script and layout threads. Right now each script/layout thread gets its own process (and I think any pipeline which shares the same script thread). Eventually we'll want to have each extra process contain some number of pipelines. So that is script+layout but for arbitrary numbers of domains. The constellation, networking, graphics, etc all live in the root process which has privileges. > I'm trying to understand the relation between a constellation, iframes > and a sandboxed process. I would naively expect to have one process > per constellation, but apparently, it's one process per iframe. If I'm > not mistaken, today in browserhtml, we have only one constellation. I > imagine in the future there would be one sandboxed process per > constellation, one constellation per group of tabs of the same domain, > and one constellation for browserhtml. There is only one constellation. A constellation owns a set of pipelines which then form a tree of pipelines. It is only these pipelines that live outside the main process. Eventually we'll probably experiment with where resource caching threads and such go. Here's a link to the deck I presented in London which has pretty pictures of what the design should be: https://docs.google.com/presentation/d/1ht96DBAynx7dbL2taDAzNHs78QWeKvyzrVV1O-cDQLQ/edit?usp=sharing jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Questions about constellation, sandboxing and multiprocess
We're currently testing -M but not -M -S, e.g. see: https://github.com/servo/saltfs/blob/master/buildbot/master/files/config/steps.yml#L46 I don't think there's any great reason for not testing sandboxing as well as multiprocess. We're testing multiprocess for Mac and Linux, not Windows as multiprocess isn't supported there. Alan. On Tue, Aug 2, 2016 at 9:47 AM, Jack Moffitt wrote: > > First, is multiprocess and sandboxing actively supported? > > I tested this right before the nightly release, and it was working > fine and didn't seem to have bad performance. Note that you can run -M > or -M and -S, but not -S by itself (which doesn't make sense). Also > note that -M and -S probably don't work on Windows or Android > currently. > > > Is Servo tested with the "-M -S" options? > > We do not have automated testing of these yet. > > > What's the status of the sandbox? > > Should work on Mac and Linux, but hasn't been audited. > > > Is there any reasons for these options to not be turned on by default? > > They should be, although I think we wanted to fix perf issues running > the WPT suite and get all the platforms working first. We should > probably test both configurations. > > > Do we want to enable "-M -S" for browserhtml? Would that help? > > I wanted to have this for the nightly, but didn't have time to test. > If it works and has decent performance we can switch to having these > be on. > > > I'd like to understand what is not part of the sandboxed content process. > > I guess compositor code and anything GPU and window related is not > > sandboxed so it runs in the main process. > > How does a sync call to localStorage work in a sandboxed process? > > Where is networking code executed? > > The thing that lives in the extra processes (which are sandboxed) are > the script and layout threads. Right now each script/layout thread > gets its own process (and I think any pipeline which shares the same > script thread). > > Eventually we'll want to have each extra process contain some number > of pipelines. So that is script+layout but for arbitrary numbers of > domains. > > The constellation, networking, graphics, etc all live in the root > process which has privileges. > > > > I'm trying to understand the relation between a constellation, iframes > > and a sandboxed process. I would naively expect to have one process > > per constellation, but apparently, it's one process per iframe. If I'm > > not mistaken, today in browserhtml, we have only one constellation. I > > imagine in the future there would be one sandboxed process per > > constellation, one constellation per group of tabs of the same domain, > > and one constellation for browserhtml. > > There is only one constellation. A constellation owns a set of > pipelines which then form a tree of pipelines. It is only these > pipelines that live outside the main process. > > Eventually we'll probably experiment with where resource caching > threads and such go. > > Here's a link to the deck I presented in London which has pretty > pictures of what the design should be: > > https://docs.google.com/presentation/d/1ht96DBAynx7dbL2taDAzNHs78QWeKvyzrVV1O-cDQLQ/edit?usp=sharing > > jack. > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Questions about constellation, sandboxing and multiprocess
On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt wrote: >> First, is multiprocess and sandboxing actively supported? > > I tested this right before the nightly release, and it was working > fine and didn't seem to have bad performance. Note that you can run -M > or -M and -S, but not -S by itself (which doesn't make sense). Also > note that -M and -S probably don't work on Windows or Android > currently. > >> Is Servo tested with the "-M -S" options? > > We do not have automated testing of these yet. > >> What's the status of the sandbox? > > Should work on Mac and Linux, but hasn't been audited. > >> Is there any reasons for these options to not be turned on by default? > > They should be, although I think we wanted to fix perf issues running > the WPT suite and get all the platforms working first. We should > probably test both configurations. > >> Do we want to enable "-M -S" for browserhtml? Would that help? > > I wanted to have this for the nightly, but didn't have time to test. > If it works and has decent performance we can switch to having these > be on. > >> I'd like to understand what is not part of the sandboxed content process. >> I guess compositor code and anything GPU and window related is not >> sandboxed so it runs in the main process. >> How does a sync call to localStorage work in a sandboxed process? >> Where is networking code executed? > > The thing that lives in the extra processes (which are sandboxed) are > the script and layout threads. Right now each script/layout thread > gets its own process (and I think any pipeline which shares the same > script thread). > > Eventually we'll want to have each extra process contain some number > of pipelines. So that is script+layout but for arbitrary numbers of > domains. In your slides, you say "more process more better". That might be a stupid question, but why? Because of the nature of Servo, can't we just gather all the script+layout threads into one single sandboxed process? > The constellation, networking, graphics, etc all live in the root > process which has privileges. > > >> I'm trying to understand the relation between a constellation, iframes >> and a sandboxed process. I would naively expect to have one process >> per constellation, but apparently, it's one process per iframe. If I'm >> not mistaken, today in browserhtml, we have only one constellation. I >> imagine in the future there would be one sandboxed process per >> constellation, one constellation per group of tabs of the same domain, >> and one constellation for browserhtml. > > There is only one constellation. A constellation owns a set of > pipelines which then form a tree of pipelines. It is only these > pipelines that live outside the main process. Would there be any advantage of having one constellation per tab? Can't a constellation fail? Would it be more robust to have multiple constellations? I've read somewhere that a constellation should be seen as the set of pipelines per tab. But maybe it's a different story with browserhtml because what would hold the tabs/constellations would be a pipeline, so at the end, it's just doesn't make sense to have multiple constellations. Asking because if multiple constellation is better and if that's we eventually want to do, we need to rethink bhtml architecture. > Eventually we'll probably experiment with where resource caching > threads and such go. > > Here's a link to the deck I presented in London which has pretty > pictures of what the design should be: > https://docs.google.com/presentation/d/1ht96DBAynx7dbL2taDAzNHs78QWeKvyzrVV1O-cDQLQ/edit?usp=sharing > > jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Questions about constellation, sandboxing and multiprocess
It's not a stupid question :) I actually think we should gather all script and layout threads together into one process. Maybe two, one for high-security sites and one for all other sites. Patrick On Aug 2, 2016 6:47 PM, "Paul Rouget" wrote: > On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt wrote: > >> First, is multiprocess and sandboxing actively supported? > > > > I tested this right before the nightly release, and it was working > > fine and didn't seem to have bad performance. Note that you can run -M > > or -M and -S, but not -S by itself (which doesn't make sense). Also > > note that -M and -S probably don't work on Windows or Android > > currently. > > > >> Is Servo tested with the "-M -S" options? > > > > We do not have automated testing of these yet. > > > >> What's the status of the sandbox? > > > > Should work on Mac and Linux, but hasn't been audited. > > > >> Is there any reasons for these options to not be turned on by default? > > > > They should be, although I think we wanted to fix perf issues running > > the WPT suite and get all the platforms working first. We should > > probably test both configurations. > > > >> Do we want to enable "-M -S" for browserhtml? Would that help? > > > > I wanted to have this for the nightly, but didn't have time to test. > > If it works and has decent performance we can switch to having these > > be on. > > > >> I'd like to understand what is not part of the sandboxed content > process. > >> I guess compositor code and anything GPU and window related is not > >> sandboxed so it runs in the main process. > >> How does a sync call to localStorage work in a sandboxed process? > >> Where is networking code executed? > > > > The thing that lives in the extra processes (which are sandboxed) are > > the script and layout threads. Right now each script/layout thread > > gets its own process (and I think any pipeline which shares the same > > script thread). > > > > Eventually we'll want to have each extra process contain some number > > of pipelines. So that is script+layout but for arbitrary numbers of > > domains. > > In your slides, you say "more process more better". > That might be a stupid question, but why? > Because of the nature of Servo, can't we just gather all the > script+layout threads into one single sandboxed process? > > > The constellation, networking, graphics, etc all live in the root > > process which has privileges. > > > > > >> I'm trying to understand the relation between a constellation, iframes > >> and a sandboxed process. I would naively expect to have one process > >> per constellation, but apparently, it's one process per iframe. If I'm > >> not mistaken, today in browserhtml, we have only one constellation. I > >> imagine in the future there would be one sandboxed process per > >> constellation, one constellation per group of tabs of the same domain, > >> and one constellation for browserhtml. > > > > There is only one constellation. A constellation owns a set of > > pipelines which then form a tree of pipelines. It is only these > > pipelines that live outside the main process. > > Would there be any advantage of having one constellation per tab? > Can't a constellation fail? Would it be more robust to have multiple > constellations? > > I've read somewhere that a constellation should be seen as the set of > pipelines per tab. > > But maybe it's a different story with browserhtml because what would > hold the tabs/constellations would be a pipeline, so at the end, it's > just doesn't make sense to have multiple constellations. > > Asking because if multiple constellation is better and if that's we > eventually want to do, we need to rethink bhtml architecture. > > > Eventually we'll probably experiment with where resource caching > > threads and such go. > > > > Here's a link to the deck I presented in London which has pretty > > pictures of what the design should be: > > > https://docs.google.com/presentation/d/1ht96DBAynx7dbL2taDAzNHs78QWeKvyzrVV1O-cDQLQ/edit?usp=sharing > > > > jack. > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Questions about constellation, sandboxing and multiprocess
Each process is a sandboxing boundary. Without security as a concern you would just have a single process. A huge next step is to have a second process that all script/layout threads go into. This however still leaves a bit of attack surface for one script task to attack another. How many processes you want is a tradeoff of overhead vs. security. So really it should say "more process more security". jack. On Tue, Aug 2, 2016 at 9:09 PM, Patrick Walton wrote: > It's not a stupid question :) I actually think we should gather all script > and layout threads together into one process. Maybe two, one for > high-security sites and one for all other sites. > > Patrick > > > On Aug 2, 2016 6:47 PM, "Paul Rouget" wrote: >> >> On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt wrote: >> >> First, is multiprocess and sandboxing actively supported? >> > >> > I tested this right before the nightly release, and it was working >> > fine and didn't seem to have bad performance. Note that you can run -M >> > or -M and -S, but not -S by itself (which doesn't make sense). Also >> > note that -M and -S probably don't work on Windows or Android >> > currently. >> > >> >> Is Servo tested with the "-M -S" options? >> > >> > We do not have automated testing of these yet. >> > >> >> What's the status of the sandbox? >> > >> > Should work on Mac and Linux, but hasn't been audited. >> > >> >> Is there any reasons for these options to not be turned on by default? >> > >> > They should be, although I think we wanted to fix perf issues running >> > the WPT suite and get all the platforms working first. We should >> > probably test both configurations. >> > >> >> Do we want to enable "-M -S" for browserhtml? Would that help? >> > >> > I wanted to have this for the nightly, but didn't have time to test. >> > If it works and has decent performance we can switch to having these >> > be on. >> > >> >> I'd like to understand what is not part of the sandboxed content >> >> process. >> >> I guess compositor code and anything GPU and window related is not >> >> sandboxed so it runs in the main process. >> >> How does a sync call to localStorage work in a sandboxed process? >> >> Where is networking code executed? >> > >> > The thing that lives in the extra processes (which are sandboxed) are >> > the script and layout threads. Right now each script/layout thread >> > gets its own process (and I think any pipeline which shares the same >> > script thread). >> > >> > Eventually we'll want to have each extra process contain some number >> > of pipelines. So that is script+layout but for arbitrary numbers of >> > domains. >> >> In your slides, you say "more process more better". >> That might be a stupid question, but why? >> Because of the nature of Servo, can't we just gather all the >> script+layout threads into one single sandboxed process? >> >> > The constellation, networking, graphics, etc all live in the root >> > process which has privileges. >> > >> > >> >> I'm trying to understand the relation between a constellation, iframes >> >> and a sandboxed process. I would naively expect to have one process >> >> per constellation, but apparently, it's one process per iframe. If I'm >> >> not mistaken, today in browserhtml, we have only one constellation. I >> >> imagine in the future there would be one sandboxed process per >> >> constellation, one constellation per group of tabs of the same domain, >> >> and one constellation for browserhtml. >> > >> > There is only one constellation. A constellation owns a set of >> > pipelines which then form a tree of pipelines. It is only these >> > pipelines that live outside the main process. >> >> Would there be any advantage of having one constellation per tab? >> Can't a constellation fail? Would it be more robust to have multiple >> constellations? >> >> I've read somewhere that a constellation should be seen as the set of >> pipelines per tab. >> >> But maybe it's a different story with browserhtml because what would >> hold the tabs/constellations would be a pipeline, so at the end, it's >> just doesn't make sense to have multiple constellations. >> >> Asking because if multiple constellation is better and if that's we >> eventually want to do, we need to rethink bhtml architecture. >> >> > Eventually we'll probably experiment with where resource caching >> > threads and such go. >> > >> > Here's a link to the deck I presented in London which has pretty >> > pictures of what the design should be: >> > >> > https://docs.google.com/presentation/d/1ht96DBAynx7dbL2taDAzNHs78QWeKvyzrVV1O-cDQLQ/edit?usp=sharing >> > >> > jack. >> ___ >> dev-servo mailing list >> dev-servo@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-servo ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Questions about constellation, sandboxing and multiprocess
I can think of one advantage right now: by having script and layout in separate processes, a compromised script thread doesn't automatically give an attacker the ability to produce malformed display lists that draw outside the tab boundary. On Tue, Aug 2, 2016, 20:43 Jack Moffitt wrote: > Each process is a sandboxing boundary. Without security as a concern > you would just have a single process. A huge next step is to have a > second process that all script/layout threads go into. This however > still leaves a bit of attack surface for one script task to attack > another. How many processes you want is a tradeoff of overhead vs. > security. > > So really it should say "more process more security". > > jack. > > On Tue, Aug 2, 2016 at 9:09 PM, Patrick Walton > wrote: > > It's not a stupid question :) I actually think we should gather all > script > > and layout threads together into one process. Maybe two, one for > > high-security sites and one for all other sites. > > > > Patrick > > > > > > On Aug 2, 2016 6:47 PM, "Paul Rouget" wrote: > >> > >> On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt wrote: > >> >> First, is multiprocess and sandboxing actively supported? > >> > > >> > I tested this right before the nightly release, and it was working > >> > fine and didn't seem to have bad performance. Note that you can run -M > >> > or -M and -S, but not -S by itself (which doesn't make sense). Also > >> > note that -M and -S probably don't work on Windows or Android > >> > currently. > >> > > >> >> Is Servo tested with the "-M -S" options? > >> > > >> > We do not have automated testing of these yet. > >> > > >> >> What's the status of the sandbox? > >> > > >> > Should work on Mac and Linux, but hasn't been audited. > >> > > >> >> Is there any reasons for these options to not be turned on by > default? > >> > > >> > They should be, although I think we wanted to fix perf issues running > >> > the WPT suite and get all the platforms working first. We should > >> > probably test both configurations. > >> > > >> >> Do we want to enable "-M -S" for browserhtml? Would that help? > >> > > >> > I wanted to have this for the nightly, but didn't have time to test. > >> > If it works and has decent performance we can switch to having these > >> > be on. > >> > > >> >> I'd like to understand what is not part of the sandboxed content > >> >> process. > >> >> I guess compositor code and anything GPU and window related is not > >> >> sandboxed so it runs in the main process. > >> >> How does a sync call to localStorage work in a sandboxed process? > >> >> Where is networking code executed? > >> > > >> > The thing that lives in the extra processes (which are sandboxed) are > >> > the script and layout threads. Right now each script/layout thread > >> > gets its own process (and I think any pipeline which shares the same > >> > script thread). > >> > > >> > Eventually we'll want to have each extra process contain some number > >> > of pipelines. So that is script+layout but for arbitrary numbers of > >> > domains. > >> > >> In your slides, you say "more process more better". > >> That might be a stupid question, but why? > >> Because of the nature of Servo, can't we just gather all the > >> script+layout threads into one single sandboxed process? > >> > >> > The constellation, networking, graphics, etc all live in the root > >> > process which has privileges. > >> > > >> > > >> >> I'm trying to understand the relation between a constellation, > iframes > >> >> and a sandboxed process. I would naively expect to have one process > >> >> per constellation, but apparently, it's one process per iframe. If > I'm > >> >> not mistaken, today in browserhtml, we have only one constellation. I > >> >> imagine in the future there would be one sandboxed process per > >> >> constellation, one constellation per group of tabs of the same > domain, > >> >> and one constellation for browserhtml. > >> > > >> > There is only one constellation. A constellation owns a set of > >> > pipelines which then form a tree of pipelines. It is only these > >> > pipelines that live outside the main process. > >> > >> Would there be any advantage of having one constellation per tab? > >> Can't a constellation fail? Would it be more robust to have multiple > >> constellations? > >> > >> I've read somewhere that a constellation should be seen as the set of > >> pipelines per tab. > >> > >> But maybe it's a different story with browserhtml because what would > >> hold the tabs/constellations would be a pipeline, so at the end, it's > >> just doesn't make sense to have multiple constellations. > >> > >> Asking because if multiple constellation is better and if that's we > >> eventually want to do, we need to rethink bhtml architecture. > >> > >> > Eventually we'll probably experiment with where resource caching > >> > threads and such go. > >> > > >> > Here's a link to the deck I presented in London which has pretty > >> > pictures of what the design should be:
