Bootstrap Mojo IPC independent of Chrome IPC

Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

On all supported platforms, a new OS pipe handle is
passed through ChildProcessLauncher and hooked up to
the EDK on ChildThreadImpl startup to establish a
Mojo IPC channel to the parent.

A command-line argument is also to used to share a
unique pipe token with the child, and this token is
exchanged over the Mojo IPC channel to bootstrap a
primordial message pipe.

While this CL establishes these facilities in a way
that can be used for all child processes, only
render processes are brought up in this way for now.

BUG=583557
TEST=Chrome still runs in mash with Mus-in-renderer support.

Committed: https://crrev.com/eb199fbaecd8e5d294010dfbe8897b7d83aeab07
Cr-Commit-Position: refs/heads/master@{#378272}

[Ken Rockot(use gerrit already), 2016-02-11 01:57:54]

rockot@chromium.org changed reviewers:
+ markdittmer@chromium.org

[Ken Rockot(use gerrit already), 2016-02-11 01:57:55]

as requested, here's some bits of the CL in progress. this compiles and
bootstraps render process mojo IPC independently of chrome IPC. work in progress
involves not breaking nacl, and making this work on Windows and Android.

eventually ChildController can be used to boostrap Chrome IPC and replace some
other mojo related IPCs like shell BindExternalMojoShellHandle.

[Ken Rockot(use gerrit already), 2016-02-11 04:01:24]

Description was changed from

==========
[nocommit] mojo ipc bootstrap without chrome ipc

posix only, nacl broken; gets a basic controller interface
from RPHI to child process.

BUG=
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This adds support to ChildProcessLauncher/ChildThreadImpl
for establishing a primordial Mojo message pipe between
the browser and all child processes immediately on
process launch without any dependency on Chrome IPC.

The pipe is bound to a new content::mojom::ChildController
interface which the browser can use to perform additional
initialization and configuration steps.

BUG=583557
==========

[Ken Rockot(use gerrit already), 2016-02-11 05:25:09]

rockot@chromium.org changed reviewers:
+ ben@chromium.org

[Ken Rockot(use gerrit already), 2016-02-11 05:25:10]

Ben, please take a look. This is a working end-to-end solution for POSIX - i.e.
Chrome runs in mash.

Note that this gives us a primordial pipe between the browser and every type of
child process, with a mojom::ChildProcess interface bound on the child's end.
Process hosts can get a handle to this from ChildProcessLauncher with basically
zero effort.

This is used by RPHI to bootstrap the shell connection now.

[Ben Goodger (Google), 2016-02-11 06:32:20]

So rather than inventing a new interface, can you just have the child
processes implement ChildController?

https://chromium.googlesource.com/chromium/src/+/master/mojo/shell/runner/chi...

-Ben

On Wed, Feb 10, 2016 at 9:25 PM, <rockot@chromium.org> wrote:

> Ben, please take a look. This is a working end-to-end solution for POSIX -
i.e.
> Chrome runs in mash.
>
> Note that this gives us a primordial pipe between the browser and every type
of
> child process, with a mojom::ChildProcess interface bound on the child's end.
> Process hosts can get a handle to this from ChildProcessLauncher with
basically
> zero effort.
>
> This is used by RPHI to bootstrap the shell connection now.
> https://codereview.chromium.org/1685183004/
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Rockot(use gerrit already), 2016-02-11 06:33:07]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-02-11 06:33:09]

The CQ bit was unchecked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-02-11 06:36:14]

On Wed, Feb 10, 2016 at 10:32 PM, Ben Goodger (Google) <ben@chromium.org>
wrote:

> So rather than inventing a new interface, can you just have the child
> processes implement ChildController?
>

In theory yes, and eventually yes, but I think for some period of time
we'll want to hang some content-specific things here. For at least one
example, we'll a message to initialize a Chrome IPC channel.


>
>
>
https://chromium.googlesource.com/chromium/src/+/master/mojo/shell/runner/chi...
>
> -Ben
>
> On Wed, Feb 10, 2016 at 9:25 PM, <rockot@chromium.org> wrote:
>
>> Ben, please take a look. This is a working end-to-end solution for POSIX -
i.e.
>> Chrome runs in mash.
>>
>> Note that this gives us a primordial pipe between the browser and every type
of
>> child process, with a mojom::ChildProcess interface bound on the child's
end.
>> Process hosts can get a handle to this from ChildProcessLauncher with
basically
>> zero effort.
>>
>> This is used by RPHI to bootstrap the shell connection now.
>> https://codereview.chromium.org/1685183004/
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ben Goodger (Google), 2016-02-11 06:49:12]

Why can't the renderer just use the Shell API to connect to a
ChromeIPCFactory interface that exposes such a method?

-Ben

On Wed, Feb 10, 2016 at 10:36 PM, Ken Rockot <rockot@chromium.org> wrote:

> On Wed, Feb 10, 2016 at 10:32 PM, Ben Goodger (Google) <ben@chromium.org>
> wrote:
>
>> So rather than inventing a new interface, can you just have the child
>> processes implement ChildController?
>>
>
> In theory yes, and eventually yes, but I think for some period of time
> we'll want to hang some content-specific things here. For at least one
> example, we'll a message to initialize a Chrome IPC channel.
>
>
>>
>>
>>
https://chromium.googlesource.com/chromium/src/+/master/mojo/shell/runner/chi...
>>
>> -Ben
>>
>> On Wed, Feb 10, 2016 at 9:25 PM, <rockot@chromium.org> wrote:
>>
>>> Ben, please take a look. This is a working end-to-end solution for POSIX -
i.e.
>>> Chrome runs in mash.
>>>
>>> Note that this gives us a primordial pipe between the browser and every type
of
>>> child process, with a mojom::ChildProcess interface bound on the child's
end.
>>> Process hosts can get a handle to this from ChildProcessLauncher with
basically
>>> zero effort.
>>>
>>> This is used by RPHI to bootstrap the shell connection now.
>>> https://codereview.chromium.org/1685183004/
>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Rockot(use gerrit already), 2016-02-11 07:06:48]

It can, but what's the practical benefit of doing that?

On Wed, Feb 10, 2016 at 10:49 PM, Ben Goodger (Google) <ben@chromium.org>
wrote:

> Why can't the renderer just use the Shell API to connect to a
> ChromeIPCFactory interface that exposes such a method?
>
> -Ben
>
> On Wed, Feb 10, 2016 at 10:36 PM, Ken Rockot <rockot@chromium.org> wrote:
>
>> On Wed, Feb 10, 2016 at 10:32 PM, Ben Goodger (Google) <ben@chromium.org>
>> wrote:
>>
>>> So rather than inventing a new interface, can you just have the child
>>> processes implement ChildController?
>>>
>>
>> In theory yes, and eventually yes, but I think for some period of time
>> we'll want to hang some content-specific things here. For at least one
>> example, we'll a message to initialize a Chrome IPC channel.
>>
>>
>>>
>>>
>>>
https://chromium.googlesource.com/chromium/src/+/master/mojo/shell/runner/chi...
>>>
>>> -Ben
>>>
>>> On Wed, Feb 10, 2016 at 9:25 PM, <rockot@chromium.org> wrote:
>>>
>>>> Ben, please take a look. This is a working end-to-end solution for POSIX -
i.e.
>>>> Chrome runs in mash.
>>>>
>>>> Note that this gives us a primordial pipe between the browser and every
type of
>>>> child process, with a mojom::ChildProcess interface bound on the child's
end.
>>>> Process hosts can get a handle to this from ChildProcessLauncher with
basically
>>>> zero effort.
>>>>
>>>> This is used by RPHI to bootstrap the shell connection now.
>>>> https://codereview.chromium.org/1685183004/
>>>>
>>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Rockot(use gerrit already), 2016-02-11 07:20:38]

In current desktop Chrome with no external shell the two approaches are
essentially equivalent - maybe a little extra overhead in processing the
connection request, but very probably negligible. And in that case
implementing ChildController seems fine.

In the external shell case it seems a bit convoluted to have the browser
pass a pipe to the child which only allows the child to connect to the
shell, and then require the child to ask the shell for a connection to the
browser to setup an IPC channel. This means that, due to the way pipe
transfer works, Chrome IPCs will be proxied through the shell process for
some very brief period of time after the child is launched. It's just a
potential source of inefficiency that seems really easy to avoid.

On Wed, Feb 10, 2016 at 11:06 PM, Ken Rockot <rockot@chromium.org> wrote:

> It can, but what's the practical benefit of doing that?
>
> On Wed, Feb 10, 2016 at 10:49 PM, Ben Goodger (Google) <ben@chromium.org>
> wrote:
>
>> Why can't the renderer just use the Shell API to connect to a
>> ChromeIPCFactory interface that exposes such a method?
>>
>> -Ben
>>
>> On Wed, Feb 10, 2016 at 10:36 PM, Ken Rockot <rockot@chromium.org> wrote:
>>
>>> On Wed, Feb 10, 2016 at 10:32 PM, Ben Goodger (Google) <ben@chromium.org
>>> > wrote:
>>>
>>>> So rather than inventing a new interface, can you just have the child
>>>> processes implement ChildController?
>>>>
>>>
>>> In theory yes, and eventually yes, but I think for some period of time
>>> we'll want to hang some content-specific things here. For at least one
>>> example, we'll a message to initialize a Chrome IPC channel.
>>>
>>>
>>>>
>>>>
>>>>
https://chromium.googlesource.com/chromium/src/+/master/mojo/shell/runner/chi...
>>>>
>>>> -Ben
>>>>
>>>> On Wed, Feb 10, 2016 at 9:25 PM, <rockot@chromium.org> wrote:
>>>>
>>>>> Ben, please take a look. This is a working end-to-end solution for POSIX -
i.e.
>>>>> Chrome runs in mash.
>>>>>
>>>>> Note that this gives us a primordial pipe between the browser and every
type of
>>>>> child process, with a mojom::ChildProcess interface bound on the child's
end.
>>>>> Process hosts can get a handle to this from ChildProcessLauncher with
basically
>>>>> zero effort.
>>>>>
>>>>> This is used by RPHI to bootstrap the shell connection now.
>>>>> https://codereview.chromium.org/1685183004/
>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Rockot(use gerrit already), 2016-02-11 07:26:53]

Another palatable option might to make it easy for an app runner and an app
to exchange services directly when desired, by e.g. adding the option to
exchange InterfaceProviders through ChildController (maybe even on StartApp)

On Wed, Feb 10, 2016 at 11:20 PM, Ken Rockot <rockot@chromium.org> wrote:

> In current desktop Chrome with no external shell the two approaches are
> essentially equivalent - maybe a little extra overhead in processing the
> connection request, but very probably negligible. And in that case
> implementing ChildController seems fine.
>
> In the external shell case it seems a bit convoluted to have the browser
> pass a pipe to the child which only allows the child to connect to the
> shell, and then require the child to ask the shell for a connection to the
> browser to setup an IPC channel. This means that, due to the way pipe
> transfer works, Chrome IPCs will be proxied through the shell process for
> some very brief period of time after the child is launched. It's just a
> potential source of inefficiency that seems really easy to avoid.
>
> On Wed, Feb 10, 2016 at 11:06 PM, Ken Rockot <rockot@chromium.org> wrote:
>
>> It can, but what's the practical benefit of doing that?
>>
>> On Wed, Feb 10, 2016 at 10:49 PM, Ben Goodger (Google) <ben@chromium.org>
>> wrote:
>>
>>> Why can't the renderer just use the Shell API to connect to a
>>> ChromeIPCFactory interface that exposes such a method?
>>>
>>> -Ben
>>>
>>> On Wed, Feb 10, 2016 at 10:36 PM, Ken Rockot <rockot@chromium.org>
>>> wrote:
>>>
>>>> On Wed, Feb 10, 2016 at 10:32 PM, Ben Goodger (Google) <
>>>> ben@chromium.org> wrote:
>>>>
>>>>> So rather than inventing a new interface, can you just have the child
>>>>> processes implement ChildController?
>>>>>
>>>>
>>>> In theory yes, and eventually yes, but I think for some period of time
>>>> we'll want to hang some content-specific things here. For at least one
>>>> example, we'll a message to initialize a Chrome IPC channel.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
https://chromium.googlesource.com/chromium/src/+/master/mojo/shell/runner/chi...
>>>>>
>>>>> -Ben
>>>>>
>>>>> On Wed, Feb 10, 2016 at 9:25 PM, <rockot@chromium.org> wrote:
>>>>>
>>>>>> Ben, please take a look. This is a working end-to-end solution for POSIX
- i.e.
>>>>>> Chrome runs in mash.
>>>>>>
>>>>>> Note that this gives us a primordial pipe between the browser and every
type of
>>>>>> child process, with a mojom::ChildProcess interface bound on the child's
end.
>>>>>> Process hosts can get a handle to this from ChildProcessLauncher with
basically
>>>>>> zero effort.
>>>>>>
>>>>>> This is used by RPHI to bootstrap the shell connection now.
>>>>>> https://codereview.chromium.org/1685183004/
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ben Goodger (Google), 2016-02-11 07:30:00]

If you don't use ChildController you're going to have to bootstrap
RunnerConnection manually in the renderer some other way, which also feels
wrong.

I suspect on most Chrome platforms the shell will be on a thread in the
browser process anyway.

-Ben

On Wed, Feb 10, 2016 at 11:20 PM, Ken Rockot <rockot@chromium.org> wrote:

> In current desktop Chrome with no external shell the two approaches are
> essentially equivalent - maybe a little extra overhead in processing the
> connection request, but very probably negligible. And in that case
> implementing ChildController seems fine.
>
> In the external shell case it seems a bit convoluted to have the browser
> pass a pipe to the child which only allows the child to connect to the
> shell, and then require the child to ask the shell for a connection to the
> browser to setup an IPC channel. This means that, due to the way pipe
> transfer works, Chrome IPCs will be proxied through the shell process for
> some very brief period of time after the child is launched. It's just a
> potential source of inefficiency that seems really easy to avoid.
>
> On Wed, Feb 10, 2016 at 11:06 PM, Ken Rockot <rockot@chromium.org> wrote:
>
>> It can, but what's the practical benefit of doing that?
>>
>> On Wed, Feb 10, 2016 at 10:49 PM, Ben Goodger (Google) <ben@chromium.org>
>> wrote:
>>
>>> Why can't the renderer just use the Shell API to connect to a
>>> ChromeIPCFactory interface that exposes such a method?
>>>
>>> -Ben
>>>
>>> On Wed, Feb 10, 2016 at 10:36 PM, Ken Rockot <rockot@chromium.org>
>>> wrote:
>>>
>>>> On Wed, Feb 10, 2016 at 10:32 PM, Ben Goodger (Google) <
>>>> ben@chromium.org> wrote:
>>>>
>>>>> So rather than inventing a new interface, can you just have the child
>>>>> processes implement ChildController?
>>>>>
>>>>
>>>> In theory yes, and eventually yes, but I think for some period of time
>>>> we'll want to hang some content-specific things here. For at least one
>>>> example, we'll a message to initialize a Chrome IPC channel.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
https://chromium.googlesource.com/chromium/src/+/master/mojo/shell/runner/chi...
>>>>>
>>>>> -Ben
>>>>>
>>>>> On Wed, Feb 10, 2016 at 9:25 PM, <rockot@chromium.org> wrote:
>>>>>
>>>>>> Ben, please take a look. This is a working end-to-end solution for POSIX
- i.e.
>>>>>> Chrome runs in mash.
>>>>>>
>>>>>> Note that this gives us a primordial pipe between the browser and every
type of
>>>>>> child process, with a mojom::ChildProcess interface bound on the child's
end.
>>>>>> Process hosts can get a handle to this from ChildProcessLauncher with
basically
>>>>>> zero effort.
>>>>>>
>>>>>> This is used by RPHI to bootstrap the shell connection now.
>>>>>> https://codereview.chromium.org/1685183004/
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Rockot(use gerrit already), 2016-02-11 07:54:49]

On 2016/02/11 at 07:30:00, ben wrote:
> If you don't use ChildController you're going to have to bootstrap
> RunnerConnection manually in the renderer some other way, which also feels
> wrong.

Ah right, that's fair. We could of course send a ChildController& over
ChildProcess in lieu of the BindToMojoShell message, but I'll see what
it looks like to just bind a ChildController directly.

> 
> I suspect on most Chrome platforms the shell will be on a thread in the
> browser process anyway.
> 
> -Ben
> 
> On Wed, Feb 10, 2016 at 11:20 PM, Ken Rockot <rockot@chromium.org> wrote:
> 
> > In current desktop Chrome with no external shell the two approaches are
> > essentially equivalent - maybe a little extra overhead in processing the
> > connection request, but very probably negligible. And in that case
> > implementing ChildController seems fine.
> >
> > In the external shell case it seems a bit convoluted to have the browser
> > pass a pipe to the child which only allows the child to connect to the
> > shell, and then require the child to ask the shell for a connection to the
> > browser to setup an IPC channel. This means that, due to the way pipe
> > transfer works, Chrome IPCs will be proxied through the shell process for
> > some very brief period of time after the child is launched. It's just a
> > potential source of inefficiency that seems really easy to avoid.
> >
> > On Wed, Feb 10, 2016 at 11:06 PM, Ken Rockot <rockot@chromium.org> wrote:
> >
> >> It can, but what's the practical benefit of doing that?
> >>
> >> On Wed, Feb 10, 2016 at 10:49 PM, Ben Goodger (Google) <ben@chromium.org>
> >> wrote:
> >>
> >>> Why can't the renderer just use the Shell API to connect to a
> >>> ChromeIPCFactory interface that exposes such a method?
> >>>
> >>> -Ben
> >>>
> >>> On Wed, Feb 10, 2016 at 10:36 PM, Ken Rockot <rockot@chromium.org>
> >>> wrote:
> >>>
> >>>> On Wed, Feb 10, 2016 at 10:32 PM, Ben Goodger (Google) <
> >>>> ben@chromium.org> wrote:
> >>>>
> >>>>> So rather than inventing a new interface, can you just have the child
> >>>>> processes implement ChildController?
> >>>>>
> >>>>
> >>>> In theory yes, and eventually yes, but I think for some period of time
> >>>> we'll want to hang some content-specific things here. For at least one
> >>>> example, we'll a message to initialize a Chrome IPC channel.
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>
https://chromium.googlesource.com/chromium/src/+/master/mojo/shell/runner/chi...
> >>>>>
> >>>>> -Ben
> >>>>>
> >>>>> On Wed, Feb 10, 2016 at 9:25 PM, <rockot@chromium.org> wrote:
> >>>>>
> >>>>>> Ben, please take a look. This is a working end-to-end solution for
POSIX - i.e.
> >>>>>> Chrome runs in mash.
> >>>>>>
> >>>>>> Note that this gives us a primordial pipe between the browser and every
type of
> >>>>>> child process, with a mojom::ChildProcess interface bound on the
child's end.
> >>>>>> Process hosts can get a handle to this from ChildProcessLauncher with
basically
> >>>>>> zero effort.
> >>>>>>
> >>>>>> This is used by RPHI to bootstrap the shell connection now.
> >>>>>> https://codereview.chromium.org/1685183004/
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to chromium-reviews+unsubscribe@chromium.org.
>

[Ken Rockot(use gerrit already), 2016-02-11 09:37:36]

Description was changed from

==========
Bootstrap Mojo IPC independent of Chrome IPC

This adds support to ChildProcessLauncher/ChildThreadImpl
for establishing a primordial Mojo message pipe between
the browser and all child processes immediately on
process launch without any dependency on Chrome IPC.

The pipe is bound to a new content::mojom::ChildController
interface which the browser can use to perform additional
initialization and configuration steps.

BUG=583557
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This lets content child processes establish a shell
connection immediately on startup with no dependency
on Chrome IPC.

BUG=583557
==========

[Ben Goodger (Google), 2016-02-11 20:26:17]

Hurray!

[Ken Rockot(use gerrit already), 2016-02-11 20:30:03]

On 2016/02/11 at 20:26:17, ben wrote:
> Hurray!

Yar, it works well! I'll sort out Windows and ping for a real review later
today.

[Ken Rockot(use gerrit already), 2016-02-12 23:53:05]

Description was changed from

==========
Bootstrap Mojo IPC independent of Chrome IPC

This lets content child processes establish a shell
connection immediately on startup with no dependency
on Chrome IPC.

BUG=583557
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This lets content child processes establish a shell
connection immediately on startup with no dependency
on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: ChildProcessLauncher creates a new named
    pipe for the Mojo channel and passes its path
    on the command-line along with a random 64-bit
    secret. The EDK ChannelWin implementation has been
    trained to listen for this token in the parent
    process if expected.

  - POSIX: We add a new file descriptor to the global
    descriptor and process launch descriptor mapping.

Finally, another command-line argument is introduced
to give the child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.

This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
==========

[Ken Rockot(use gerrit already), 2016-02-12 23:55:28]

Description was changed from

==========
Bootstrap Mojo IPC independent of Chrome IPC

This lets content child processes establish a shell
connection immediately on startup with no dependency
on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: ChildProcessLauncher creates a new named
    pipe for the Mojo channel and passes its path
    on the command-line along with a random 64-bit
    secret. The EDK ChannelWin implementation has been
    trained to listen for this token in the parent
    process if expected.

  - POSIX: We add a new file descriptor to the global
    descriptor and process launch descriptor mapping.

Finally, another command-line argument is introduced
to give the child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.

This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: ChildProcessLauncher creates a new named
    pipe for the Mojo channel and passes its path
    on the command-line along with a random 64-bit
    secret. The EDK ChannelWin implementation has been
    trained to listen for this token in the parent
    process if expected. This is similar in spirit to
    how IPC::ChannelWin is bootstrapped.

  - POSIX: We add a new file descriptor to the global
    descriptor and process launch descriptor mapping.

Finally, another command-line argument is introduced
to give the child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.

This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
==========

[Ken Rockot(use gerrit already), 2016-02-13 00:04:28]

OK, I think this is about ready for review. Ben could you take a look at the
Mojo shell-y stuff? Namely MojoShellClientHost/ConnectionImpl and
RunnerConnection?

John could you look as a content and Mojo owner? And Tom for security review
since I'm introducing a new primary IPC channel across content and doing
security sensitive things.

Note for John: I didn't use PlatformChannelPair on Windows because it seems to
me the handle passing mechanism is insufficient for working with sandboxed
processes: i.e. in order to pass the handle to the child we need to duplicate it
in the parent, but we need the child's process handle to do that and therefore
can't pass something useful on the command line. Hence I went with the
name+secret strategy used by IPC::ChannelWin.

[Ken Rockot(use gerrit already), 2016-02-13 00:22:19]

Description was changed from

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: ChildProcessLauncher creates a new named
    pipe for the Mojo channel and passes its path
    on the command-line along with a random 64-bit
    secret. The EDK ChannelWin implementation has been
    trained to listen for this token in the parent
    process if expected. This is similar in spirit to
    how IPC::ChannelWin is bootstrapped.

  - POSIX: We add a new file descriptor to the global
    descriptor and process launch descriptor mapping.

Finally, another command-line argument is introduced
to give the child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.

This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: ChildProcessLauncher creates a new named
    pipe for the Mojo channel and passes its path
    on the command-line along with a random 64-bit
    secret. The EDK ChannelWin implementation has been
    trained to listen for this token in the parent
    process if expected. This is similar in spirit to
    how IPC::ChannelWin is bootstrapped.

  - POSIX: We add a new file descriptor to the global
    descriptor table and process launch descriptor
    mapping. The client side of a PlatformChannelPair
    is stashed here before launch.

Finally, another command-line argument is introduced
to give the child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.

This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
==========

[Ken Rockot(use gerrit already), 2016-02-13 00:23:23]

rockot@chromium.org changed reviewers:
+ jam@chromium.org, tsepez@chromium.org
- markdittmer@chromium.org

[Ken Rockot(use gerrit already), 2016-02-13 00:23:23]

Actually adding the right people this time. Message duped below:

OK, I think this is about ready for review. Ben could you take a look at the
Mojo shell-y stuff? Namely MojoShellClientHost/ConnectionImpl and
RunnerConnection?

John could you look as a content and Mojo owner? And Tom for security review
since I'm introducing a new primary IPC channel across content and doing
security sensitive things.

Note for John: I didn't use PlatformChannelPair on Windows because it seems to
me the handle passing mechanism is insufficient for working with sandboxed
processes: i.e. in order to pass the handle to the child we need to duplicate it
in the parent, but we need the child's process handle to do that and therefore
can't pass something useful on the command line. Hence I went with the
name+secret strategy used by IPC::ChannelWin.

[jam, 2016-02-13 04:15:13]

On 2016/02/13 00:23:23, Ken Rockot wrote:
> Actually adding the right people this time. Message duped below:
> 
> OK, I think this is about ready for review. Ben could you take a look at the
> Mojo shell-y stuff? Namely MojoShellClientHost/ConnectionImpl and
> RunnerConnection?
> 
> John could you look as a content and Mojo owner? And Tom for security review
> since I'm introducing a new primary IPC channel across content and doing
> security sensitive things.
> 
> Note for John: I didn't use PlatformChannelPair on Windows because it seems to
> me the handle passing mechanism is insufficient for working with sandboxed
> processes: i.e. in order to pass the handle to the child we need to duplicate
it
> in the parent, but we need the child's process handle to do that and therefore
> can't pass something useful on the command line. Hence I went with the
> name+secret strategy used by IPC::ChannelWin.

I defer to the windows sandbox experts (sandbox/win/OWNERS lists cpu/jschuh/wfh)
for these details as I'm not very familiar with how we passed the chrome ipc
handle.

https://codereview.chromium.org/1685183004/diff/180001/content/browser/render...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/1685183004/diff/180001/content/browser/render...
content/browser/renderer_host/render_process_host_impl.cc:1628:
shell_pipe_token_);
You'll want to do the same thing in BrowserChildProcessHostImpl so that this
pipe is also setup for non-renderer processes

[Ken Rockot(use gerrit already), 2016-02-13 04:35:09]

rockot@chromium.org changed reviewers:
+ jschuh@chromium.org

[Ken Rockot(use gerrit already), 2016-02-13 04:35:10]

Thanks! Adding jschuh for Windows sandbox expertise.

https://codereview.chromium.org/1685183004/diff/180001/content/browser/render...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/1685183004/diff/180001/content/browser/render...
content/browser/renderer_host/render_process_host_impl.cc:1628:
shell_pipe_token_);
On 2016/02/13 at 04:15:13, jam wrote:
> You'll want to do the same thing in BrowserChildProcessHostImpl so that this
pipe is also setup for non-renderer processes

Yeah, I'm intentionally keeping this on render processes only for this CL. My
plan is to expand this to all child processes soon.

[Ken Rockot(use gerrit already), 2016-02-16 18:08:47]

Patchset #12 (id:200001) has been deleted

[Ken Rockot(use gerrit already), 2016-02-16 18:25:31]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-16 18:26:37]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1685183004/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1685183004/220001

[Ken Rockot(use gerrit already), 2016-02-16 18:30:07]

Description was changed from

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: ChildProcessLauncher creates a new named
    pipe for the Mojo channel and passes its path
    on the command-line along with a random 64-bit
    secret. The EDK ChannelWin implementation has been
    trained to listen for this token in the parent
    process if expected. This is similar in spirit to
    how IPC::ChannelWin is bootstrapped.

  - POSIX: We add a new file descriptor to the global
    descriptor table and process launch descriptor
    mapping. The client side of a PlatformChannelPair
    is stashed here before launch.

Finally, another command-line argument is introduced
to give the child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.

This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: ChildProcessLauncher creates a new named
    pipe for the Mojo channel and passes its path
    on the command-line along with a random 64-bit
    secret. The EDK ChannelWin implementation has been
    trained to listen for this token in the parent
    process if expected. This is similar in spirit to
    how IPC::ChannelWin is bootstrapped.

  - POSIX: We add a new file descriptor to the global
    descriptor table and process launch descriptor
    mapping. The client side of a PlatformChannelPair
    is stashed here before launch.

On all platforms, ChildThreadImpl does a small amount of
work on Init to set up the Mojo IPC channel
(i.e., SetParentPipe).

Finally, another command-line argument is introduced
to give a child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.

This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
==========

[commit-bot: I haz the power, 2016-02-16 20:49:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-16 20:49:13]

Dry run: This issue passed the CQ dry run.

[Ken Rockot(use gerrit already), 2016-02-17 00:13:00]

Description was changed from

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: ChildProcessLauncher creates a new named
    pipe for the Mojo channel and passes its path
    on the command-line along with a random 64-bit
    secret. The EDK ChannelWin implementation has been
    trained to listen for this token in the parent
    process if expected. This is similar in spirit to
    how IPC::ChannelWin is bootstrapped.

  - POSIX: We add a new file descriptor to the global
    descriptor table and process launch descriptor
    mapping. The client side of a PlatformChannelPair
    is stashed here before launch.

On all platforms, ChildThreadImpl does a small amount of
work on Init to set up the Mojo IPC channel
(i.e., SetParentPipe).

Finally, another command-line argument is introduced
to give a child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.

This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: The sandboxed process launch API now
    supports passing in inherited handles.

  - POSIX: A new file descriptor is added to the global
    descriptor table and process launch descriptor
    mapping.

On all platforms ChildThreadImpl does a small amount of
work on Init to set up the Mojo IPC channel
(i.e., SetParentPipe) from the passed handles.

Finally, another command-line argument is introduced
to give a child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.
This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
==========

[Ken Rockot(use gerrit already), 2016-02-17 00:19:44]

rockot@chromium.org changed reviewers:
+ pennymac@chromium.org

[Ken Rockot(use gerrit already), 2016-02-17 00:19:45]

jschuch and +pennymac : I've updated the Windows launching code to use handle
inheritance. Please take a look. A few notes:

It was awkward to have StartSandboxedProcess duplicate the handles *and* launch
the process, because users of the system need to pass handle information on the
command-line. Ideally they could control the switch names used to pass their
handles (as this CL does for its use of the feature). For this reason I added a
new PrepareInheritedHandle alongside StartSandboxedProcess. Users can use this
to get a scoped duplicate of a handle (automatically closed - though maybe this
should be optional), as well as an integer they can pass to the child.

The main bits to review are sandbox/win and the few Windows-specific parts of
ChildProcessLauncher.

This isn't a terribly large CL as-is and this use case is the only consumer of
handle inheritance, so I haven't separated these changes out from the rest of
it. If you'd like me to move them to their own CL, no big deal, just let me
know.

Thanks!

[Ken Rockot(use gerrit already), 2016-02-17 00:20:16]

Description was changed from

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: The sandboxed process launch API now
    supports passing in inherited handles.

  - POSIX: A new file descriptor is added to the global
    descriptor table and process launch descriptor
    mapping.

On all platforms ChildThreadImpl does a small amount of
work on Init to set up the Mojo IPC channel
(i.e., SetParentPipe) from the passed handles.

Finally, another command-line argument is introduced
to give a child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.
This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: The sandboxed process launch API now
    supports passing in inherited handles.

  - POSIX: A new file descriptor is added to the global
    descriptor table and process launch descriptor
    mapping.

On all platforms ChildThreadImpl does a small amount of
work on Init to set up the Mojo IPC channel
(i.e., SetParentPipe) from the passed handles.

Finally, another command-line argument is introduced
to give a child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.
This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
TEST=Chrome still runs in mash with Mus-in-renderer support.
==========

[Ken Rockot(use gerrit already), 2016-02-17 00:23:32]

Oh, also content/common/sandbox{_init.h,_win.cc} of course

[jschuh, 2016-02-17 05:15:58]

On 2016/02/17 00:23:32, Ken Rockot wrote:
> Oh, also content/common/sandbox{_init.h,_win.cc} of course

Could you split the sandbox/win changes out into their own CL and add a test?
pennymac@ has offered to assist on that front.

[jam, 2016-02-17 16:44:49]

fwiw, the code i reviewed before still lgtm (well, of course it's better :) )

[Ken Rockot(use gerrit already), 2016-02-26 16:21:29]

Description was changed from

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

To accomplish this in coordination with the sandbox,
we introduce some new bits on different platforms:

  - Windows: The sandboxed process launch API now
    supports passing in inherited handles.

  - POSIX: A new file descriptor is added to the global
    descriptor table and process launch descriptor
    mapping.

On all platforms ChildThreadImpl does a small amount of
work on Init to set up the Mojo IPC channel
(i.e., SetParentPipe) from the passed handles.

Finally, another command-line argument is introduced
to give a child process a random token it can exchange
for a Mojo message pipe once Mojo IPC is initialized.
This is used to support the renderer-to-shell bootstrap
for Chrome-on-Mus which previously relied upon Chrome IPC
messages for initialization.

BUG=583557
TEST=Chrome still runs in mash with Mus-in-renderer support.
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

On all supported platforms, a new OS pipe handle is
passed through ChildProcessLauncher and hooked up to
the EDK on ChildThreadImpl startup to establish a
Mojo IPC channel to the parent.

A command-line argument is also to used to share a
unique pipe token with the child, and this token is
exchanged over the Mojo IPC channel to bootstrap a
primordial message pipe.

While this CL establishes these facilities in a way
that can be used for all child processes, only
render processes are brought up in this way for now.

BUG=583557
TEST=Chrome still runs in mash with Mus-in-renderer support.
==========

[Ken Rockot(use gerrit already), 2016-02-26 23:31:07]

Ping tsepez@ - could you please take a look for content/common/mojo/messages.h?
Just deleting an IPC.

[jschuh, 2016-02-29 19:34:35]

lgtm for ipc security.

[Ken Rockot(use gerrit already), 2016-02-29 20:00:56]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-02-29 20:00:57]

The patchset sent to the CQ was uploaded after l-g-t-m from jam@chromium.org
Link to the patchset: https://codereview.chromium.org/1685183004/#ps340001
(title: " ")

[commit-bot: I haz the power, 2016-02-29 20:01:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1685183004/340001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1685183004/340001

[commit-bot: I haz the power, 2016-02-29 21:15:30]

Committed patchset #18 (id:340001)

[commit-bot: I haz the power, 2016-02-29 21:16:36]

Description was changed from

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

On all supported platforms, a new OS pipe handle is
passed through ChildProcessLauncher and hooked up to
the EDK on ChildThreadImpl startup to establish a
Mojo IPC channel to the parent.

A command-line argument is also to used to share a
unique pipe token with the child, and this token is
exchanged over the Mojo IPC channel to bootstrap a
primordial message pipe.

While this CL establishes these facilities in a way
that can be used for all child processes, only
render processes are brought up in this way for now.

BUG=583557
TEST=Chrome still runs in mash with Mus-in-renderer support.
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

On all supported platforms, a new OS pipe handle is
passed through ChildProcessLauncher and hooked up to
the EDK on ChildThreadImpl startup to establish a
Mojo IPC channel to the parent.

A command-line argument is also to used to share a
unique pipe token with the child, and this token is
exchanged over the Mojo IPC channel to bootstrap a
primordial message pipe.

While this CL establishes these facilities in a way
that can be used for all child processes, only
render processes are brought up in this way for now.

BUG=583557
TEST=Chrome still runs in mash with Mus-in-renderer support.

Committed: https://crrev.com/eb199fbaecd8e5d294010dfbe8897b7d83aeab07
Cr-Commit-Position: refs/heads/master@{#378272}
==========

[commit-bot: I haz the power, 2016-02-29 21:16:38]

Patchset 18 (id:??) landed as
https://crrev.com/eb199fbaecd8e5d294010dfbe8897b7d83aeab07
Cr-Commit-Position: refs/heads/master@{#378272}

[Mark Seaborn, 2016-03-01 02:15:34]

Description was changed from

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

On all supported platforms, a new OS pipe handle is
passed through ChildProcessLauncher and hooked up to
the EDK on ChildThreadImpl startup to establish a
Mojo IPC channel to the parent.

A command-line argument is also to used to share a
unique pipe token with the child, and this token is
exchanged over the Mojo IPC channel to bootstrap a
primordial message pipe.

While this CL establishes these facilities in a way
that can be used for all child processes, only
render processes are brought up in this way for now.

BUG=583557
TEST=Chrome still runs in mash with Mus-in-renderer support.

Committed: https://crrev.com/eb199fbaecd8e5d294010dfbe8897b7d83aeab07
Cr-Commit-Position: refs/heads/master@{#378272}
==========

to

==========
Bootstrap Mojo IPC independent of Chrome IPC

This initializes Mojo IPC very early in child process
startup so we can start using cross-process pipes in
content without a dependency on Chrome IPC.

On all supported platforms, a new OS pipe handle is
passed through ChildProcessLauncher and hooked up to
the EDK on ChildThreadImpl startup to establish a
Mojo IPC channel to the parent.

A command-line argument is also to used to share a
unique pipe token with the child, and this token is
exchanged over the Mojo IPC channel to bootstrap a
primordial message pipe.

While this CL establishes these facilities in a way
that can be used for all child processes, only
render processes are brought up in this way for now.

BUG=583557
TEST=Chrome still runs in mash with Mus-in-renderer support.

Committed: https://crrev.com/eb199fbaecd8e5d294010dfbe8897b7d83aeab07
Cr-Commit-Position: refs/heads/master@{#378272}
==========

[Ken Rockot(use gerrit already), 2016-03-01 02:22:51]

A revert of this CL (patchset #18 id:340001) has been created in
https://codereview.chromium.org/1748973003/ by rockot@chromium.org.

The reason for reverting is: Breaking NaCl in a way that somehow was not caught
in the CQ... :{

Will reland once that's sorted out.
.