That's right: the ideal model is one process per "app" and one process per 
<iframe browser> (arbitrary web content).

In practice, OS processes aren't free, and memory is a finite resource, so 
we'll need to multiplex apps/tabs onto OS processes.  Gecko is quite flexible 
on how this can be done.  The allocation of apps/tabs to processes will take 
into account regulatory requirements, performance goals, and security issues.

Cheers,
Chris

----- Original Message -----
> From: "ptheriault" <ptheria...@mozilla.com>
> To: "Guillaume Destuynder" <gdestuyn...@mozilla.com>
> Cc: "Chris Jones" <cjo...@mozilla.com>, dev-security@lists.mozilla.org, 
> "Mozilla B2G mailing list"
> <dev-...@lists.mozilla.org>
> Sent: Tuesday, March 13, 2012 2:59:47 PM
> Subject: Re: [b2g] B2G's kernel level permissions and reliability
> 
> So my understanding is that the goal would be one process per app,
> however for performance reasons, apps may need to be grouped. There
> will always be at least one lower-privileged process for running
> content (apps) and ideally there would be at least enough to
> separate critical apps (dialer, sms) from non-cirtical apps. (to
> limit the extent of priv-esc bugs).
> 
> That was how I understood from our discussion the other day Chris -
> does that sound accurate?
> 
> Regards,
> Paul
> 
> 
> On Mar 14, 2012, at 8:51 AM, Guillaume Destuynder wrote:
> 
> > On 03/07/2012 08:11 PM, Chris Jones wrote:
> >>> Note that the solution is likely to be electrolysis, but, while
> >>> it's
> >>> on
> >>> the roadmap, as far as I understand, it is likely that B2G won't
> >>> actually ship with electrolysis enabled, nor would it really be
> >>> planned
> >>> in the future.
> >> 
> >> I'm not sure where you got that idea, but it's not correct :).  On
> >> the contrary, B2G won't ship to consumers *without* multi-process
> >> support.
> >> 
> > 
> > Well, it sounds like the multi-process support wouldn't be one
> > process
> > per app, to be more precise.
> > 
> > I don't find any precise decision or information about this so far.
> > 
> > 
> > Guillaume
> > _______________________________________________
> > dev-b2g mailing list
> > dev-...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-b2g
> 
> 
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Reply via email to