Re: [b2g] B2G's kernel level permissions and reliability

[Guillaume Destuynder]

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

[ptheriault]

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

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

[Chris Jones]

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

[lkcl luke]

On Thu, Mar 15, 2012 at 3:26 AM, Chris Jones <cjo...@mozilla.com> wrote:
> That's right: the ideal model is one process per "app" and one process per <iframe browser> (arbitrary web content).

processes (fork) are not secure, and are not securable. privilege
escalation is still possible. for maximum security (even when not
using SE/Linux to audit, track and enforce security), exec has to be
used.

that means designing the system so that there is inter-process communication.

and in the case under discussion, that's actually very very easy to
add.... to XPCOM. COM, which inspired XPCOM, can have its parameters
marshalled, shipped over an inter-process communications pipe, and
unmarshalled, because the fundamental basis of COM is actually
DCE/RPC.

so there is absolutely no reason in the world why XPCOM should not
also be properly upgraded to use DCE/RPC. there are at least two
suitable implementations out there: one is http://freedce.sf.net and
the other is in Wine. the license on freedce is both BSD and LGPLv2+.

now, for precisely the reasons you raised chris (speed and memory
requirements optimised when things like security are blatantly
ignored) microsoft chose to make an "optimisation" to COM where the
inter-process communication could be removed and the parameters
swapped on the stack.

i believe they may actually have used COM to construct the function
call parameter stack in assembly code by the marshaller/unmarshaller
:)

so, anyway: if you've got the pieces in place, you can make the decision.

but... yeah. the above is quite a bit of work. it's why i
recommended the architecture of just creating JSONRPC services for all
B2G back-end functionality instead.

i'm actually quite concerned that to the Mozilla Foundation, with its
technical hammer called "WebAPI", that all technical problems are now
looking like nails.

l.