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 <j...@metajack.im> 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 <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 > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
