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 <pwal...@mozilla.com> 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" <p...@mozilla.com> wrote: >> >> On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt <j...@metajack.im> 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
