src/mojo

[Darin Fisher]

Hi folks,

I'm writing to provide a little background about the src/mojo top-level directory that was recently added.

The README file says:

This is an effort to extract a common platform out of Chrome's renderer and plugin processes that can support multiple types of sandboxed content, such as HTML, Pepper, or NaCL.

That sounds like a fairly lofty goal. What it really boils down to is isolating the components of our multi-process architecture that are concerned with process management, sandboxing and IPC. Much of this work is / will be straightforward extraction of code that is currently part of src/content/ into a narrower submodule.

In part with this effort, we are re-thinking IPC. Chrome IPC has served us well, but we see some ways in which it could be improved:

• The IPC system should make connections between services and clients more of a first-class concept. We have a lot of code that is effectively just doing that in an ad-hoc fashion for different services.

• Related to the above, the IPC system should make it easy to move services to different threads or processes with minimal disruption to clients.

• We should have a way to machine-generate C++ bindings for IPC. Imagine if making your code callable from another process was as simple as implementing an interface. That could help with code clarity as well as enable easier/better unit and fuzz testing.

• The IPC system should make it easier to setup and pass around byte streams, shared memory and files. There is a bit of a barrier to using these things correctly in the current setup, which often results in people choosing less efficient methods of passing around data.

• The IPC system should use a messaging format that is optionally capable of being used in cases where we want to talk between end-points built from different versions of the code base. This would open up the possibility of breaking Chrome up into components that are versioned separately. (Note: We already do this to a certain extent by leveraging Pepper, but growing Pepper for these use cases is costly if the APIs are not general purpose.)

• Related to the above, we should have a binary pickling format that is more resilient to version skew. See the mess that is content/common/page_state_serialization.cc for an example of how base::Pickle is not at all the right choice for archiving data structures.

The above is just a taste of some of the benefits to be had. More details as they emerge :-)

-Darin

[Darin Fisher]

FYI, I created mojo...@chromium.org for discussions related to the development of src/mojo. Nothing exciting is happening there yet.

-Darin

[Chris Bentzel]

Naive question: Why not use protobuffers, which are resilient to
data-skew and auto-generate bindings based on an IDL syntax? We'd
probably have to add primitives for shared memory (protobufs were
originally targeted for RPCs between different services) but other
than that seem like a reasonable solution.

>>
>>
>> The above is just a taste of some of the benefits to be had. More details
>> as they emerge :-)
>>
>>
>> -Darin
>
>

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev

[Tom Wiltzius]

On Mon, Oct 7, 2013 at 12:48 AM, Darin Fisher <da...@chromium.org> wrote:

Hi folks,

I'm writing to provide a little background about the src/mojo top-level directory that was recently added.

The README file says:

This is an effort to extract a common platform out of Chrome's renderer and plugin processes that can support multiple types of sandboxed content, such as HTML, Pepper, or NaCL.

That sounds like a fairly lofty goal. What it really boils down to is isolating the components of our multi-process architecture that are concerned with process management, sandboxing and IPC. Much of this work is / will be straightforward extraction of code that is currently part of src/content/ into a narrower submodule.

In part with this effort, we are re-thinking IPC. Chrome IPC has served us well, but we see some ways in which it could be improved:

• The IPC system should make connections between services and clients more of a first-class concept. We have a lot of code that is effectively just doing that in an ad-hoc fashion for different services.

• Related to the above, the IPC system should make it easy to move services to different threads or processes with minimal disruption to clients.

• We should have a way to machine-generate C++ bindings for IPC. Imagine if making your code callable from another process was as simple as implementing an interface. That could help with code clarity as well as enable easier/better unit and fuzz testing.

Since IPCs are on the whole a surface risky for security (and have been the subject of much scrutiny by the security team thus far), does auto-generating them imply a greater burden on manual review of additional IPCs or is that outweighed by the easier unit and fuzz testing?

 

• The IPC system should make it easier to setup and pass around byte streams, shared memory and files. There is a bit of a barrier to using these things correctly in the current setup, which often results in people choosing less efficient methods of passing around data.

• The IPC system should use a messaging format that is optionally capable of being used in cases where we want to talk between end-points built from different versions of the code base. This would open up the possibility of breaking Chrome up into components that are versioned separately. (Note: We already do this to a certain extent by leveraging Pepper, but growing Pepper for these use cases is costly if the APIs are not general purpose.)

• Related to the above, we should have a binary pickling format that is more resilient to version skew. See the mess that is content/common/page_state_serialization.cc for an example of how base::Pickle is not at all the right choice for archiving data structures.

The above is just a taste of some of the benefits to be had. More details as they emerge :-)

-Darin

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Darin Fisher]

Right, protobufs have many of these properties. They also have significant overhead. We also looked at Cap'n Proto (http://kentonv.github.io/capnproto/), which is a newer take on protobufs by the guy who created protobufs v2.

We looked hard at just using Cap'n Proto, but instead ended up using it quite heavily for inspiration. The code is all C++x11, which makes it a difficult starting point for Chromium.

I need to share more thoughts on the IPC design...

-Darin

[Darin Fisher]

On Sun, Oct 13, 2013 at 3:35 PM, Tom Wiltzius <wilt...@google.com> wrote:

On Mon, Oct 7, 2013 at 12:48 AM, Darin Fisher <da...@chromium.org> wrote:

Hi folks,

I'm writing to provide a little background about the src/mojo top-level directory that was recently added.

The README file says:

This is an effort to extract a common platform out of Chrome's renderer and plugin processes that can support multiple types of sandboxed content, such as HTML, Pepper, or NaCL.

That sounds like a fairly lofty goal. What it really boils down to is isolating the components of our multi-process architecture that are concerned with process management, sandboxing and IPC. Much of this work is / will be straightforward extraction of code that is currently part of src/content/ into a narrower submodule.

In part with this effort, we are re-thinking IPC. Chrome IPC has served us well, but we see some ways in which it could be improved:

• The IPC system should make connections between services and clients more of a first-class concept. We have a lot of code that is effectively just doing that in an ad-hoc fashion for different services.

• Related to the above, the IPC system should make it easy to move services to different threads or processes with minimal disruption to clients.

• We should have a way to machine-generate C++ bindings for IPC. Imagine if making your code callable from another process was as simple as implementing an interface. That could help with code clarity as well as enable easier/better unit and fuzz testing.

Since IPCs are on the whole a surface risky for security (and have been the subject of much scrutiny by the security team thus far), does auto-generating them imply a greater burden on manual review of additional IPCs or is that outweighed by the easier unit and fuzz testing?

My understanding from talking to "security guys" is that having an IDL for IPCs would be a big win. It enables easier static analysis as well as fuzz testing, etc.

-Darin

[Kenton Varda]

Hi Darin and chromium-dev,

I'm the author of Cap'n Proto (and formerly proto2).  I was pointed to this thread by Will Chan.

Cap'n Proto would indeed be an excellent fit for Chrome's use case.  In fact, although it is intended to work well over a network as well, I have been explicitly designing it for the use case of a sandboxed process talking to a supervisor on the same machine.

As you know, the use case of communicating through shared memory is exactly the case where Cap'n Proto is literally "infinity times faster", since it actually results in zero copies end-to-end.

What might be a bit less obvious is that Cap'n Proto's capability-based RPC system is excellent for handling complex object-oriented interactions in a secure way, especially between a sandbox and its supervisor.  It is directly based on research by Mark Miller of the Google security team -- the same concepts that underlie Google Caja, which allows untrusted Javascript "gadgets" to run safely inside the context of a trusted site.

Regarding the C++11 issue, you aren't the first to have a problem with this -- Windows users by and large cannot use Cap'n Proto right now as they aren't willing to give up MSVC, and MSVC has been slow about implementing C++11.  To that end, I have had it on my wish list for a while to do a C++03 backport of the runtime library.  However, it is not on my own critical path, as my use case is a purely-Linux server environment.

I'm not sure how far along you are with your own solution, but I think it would make a lot of sense to work together on this.  Even though Chrome can't use the runtime library as-is, it could benefit from a lot of other pieces of the project.  You'd be able to reuse the command-line tools, such as the code generator framework and the debugging utility.  You also might benefit from the budding Cap'n Proto ecosystem, e.g. the Python implementation might be useful for testing.  Since I'm also targeting a sandbox-supervisor use case, it's likely that the ecosystem will continue to develop in a way that is favorable to Chrome's use.  And, of course, backporting the existing runtime library from C++11 is going to be a lot easier than writing something new from scratch, and future improvements will be easier to port between the two.

I'd be happy to up the priority on the C++03 backport if it means Chrome developers are likely to lend some development effort and security expertise to the project.

Thoughts?

-Kenton

[Kenton Varda]

[+cc darin, which the Groups interface didn't do for some reason]

[Darin Fisher]

Hi Kenton,

Thanks for reaching out. I think it would be interesting to learn more about Cap'n Proto. Indeed, many of the ideas resonated with us as we were exploring alternative messaging formats. We ended up with perhaps a variation of the Cap'n Proto messaging format.

That said, we are not that far invested in our design. Of course, we may have developed some affinity for our choices ;-) It is hard to say. The C++x11 obstacle somewhat limited out exploration of Cap'n Proto.

It would anyways be a good thing for us to detail more of what we had in mind and to share our design considerations / objectives.

Regards,

-Darin

On Mon, Oct 14, 2013 at 11:24 AM, Kenton Varda <temp...@gmail.com> wrote:

[Kenton Varda]

Hi Darin,

I'm willing to consider design changes.  :)  I don't consider anything about Cap'n Proto to be set in stone yet.  There are some existing users, and changes to the wire format would be inconvenient for them, but if it meant the difference between having Chromium as a user and not, that could be a compelling argument for a breaking change.

Of course, intractable differences in opinion are always possible, but at the very least it would be better to figure out if they exist than to just assume.  :)  And we'll likely at least be able to steal some ideas from each other.

If you're in Mountain View, I'd be happy to come in and meet in person.  (I still live nearby.)

-Kenton

[William Chan (陈智昌)]

Just wanted to say I think now's a great time to evaluate design choices, both on the Chromium side and Cap'n Proto side. If we have a design doc or something on the Chromium side, I think it'd be awesome to share that.

[Darin Fisher]

Yes, that's what I meant by:

"It would anyways be a good thing for us to detail more of what we had in mind and to share our design considerations / objectives."

I'm on vacation this week, so it'll have to be next week :)

-Darin

[Darin Fisher]

bcc:chromium-dev

Thanks. Happy to meet up in Mountain View. Let me know your availability next week. Tuesday 10/22 would be ideal for us.

-Darin

[William Chan (陈智昌)]

Oops, I missed that line. That's what happens when I skim too quickly :)

PS: Enjoy your vacation and stop reading email :P

[Fabio Kaminski]

Funny.. im doing a outsider project using chrome, and for my use case i need badly of a serialization protocol like protobuf and cap'n proto

.. my use case is similar, its was my intention that process could use a more plastic IPC between each other, but would be using the classic hardcoded chrome IPC for browser-child communication, because of security and because that interface wouldnt change much..

Cap'n proto vs. Protobuf is much more fun to use, but i had the same bad felling about it being a x11 implementation, since working on windows is intended and Clang for Windows still very green..

If you guys come up with something together, and with the possibility for this to be used even for plumbing between the classic IPC system, it will be wonderful..

I must say that the DSL of cap ń proto looks pretty good, and if you guys came up with a common formula together, it will be awesome for the chrome project, and the plasticity achieved by using it for the IPC mechanism will be fantastic!

Cheers!

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[David Michael]

I'll look forward to more design information next week.

But while I'm thinking about it, here's my 2 cents. I'm hoping we don't try to reinvent serialization versioning, and I'm also hoping we don't saddle *all* IPC with that kind of complexity.

I'm imagining something where there's a small core of relatively primitive types for sending over IPC that rarely if ever changes. More complex messages are built out of these, and I think the typical case is these wouldn't bother with versioning because I suspect our common case is still going to be that clients and servers come from the same code tree and don't need to interact with newer or older versions of their peers.

But in those rare cases where versioning is important for an interface, we fix the message format to something very small and opaque that sends a "buffer" as far as IPC is concerned. The buffer is a versioned protobuf (or similar). We can make nice wrappers around this, if desired.

Something like that. In general, I'm hoping we keep simple stuff simple, and layer complexity on only where it's needed.

But maybe I'm preaching to the choir :)

[Alec Flett]

On Wed, Oct 16, 2013 at 10:33 AM, David Michael <dmic...@google.com> wrote:

I'll look forward to more design information next week.

But while I'm thinking about it, here's my 2 cents. I'm hoping we don't try to reinvent serialization versioning, and I'm also hoping we don't saddle *all* IPC with that kind of complexity.

 

I'm imagining something where there's a small core of relatively primitive types for sending over IPC that rarely if ever changes. More complex messages are built out of these, and I think the typical case is these wouldn't bother with versioning because I suspect our common case is still going to be that clients and servers come from the same code tree and don't need to interact with newer or older versions of their peers.

being future/past-proof doesn't necessarily mean explicit versioning and the complexity that that entails.. Protobufs are designed, and used, with this in mind: that a message can contain data (i.e. data added in a future version of the message) that you don't recognize.. and that is ok and you should ignore it. (i.e. you should be able to read known fields from a protobuf, and reserialize the protobuf, without losing values for fields you don't recognize.)

The key is just being careful as you evolve messages -you generally try to only evolve your IPC messages additively - meaning you only add new fields, and try not to take away old ones unless you can guarantee that old code will deal well with the specific missing fields. 

Alec

[Jochen Eisinger]

+mojo-dev, so it doesn't feel so lonely over there

[Darin Fisher]

bcc:chromium-dev

This thread is better on mojo-dev@.

@dmichael - I'll post more details shortly, but in a nut-shell, our idea is to decompose the IPC system into two parts: connections and message format.

A connection (Mojo MessagePipe) works like a HTML5 MessagePort. You can send messages on a MessagePipe that consist of a byte array and an object array. The types of objects you can send with a message include other MessagePipes as well as DataPipes and RandomAccessBlobs (i.e., Files or SHM). There may be other object types supported in the future.

The message format can vary from connection to connection, but we would obviously want to reuse some particular format for most of our connections. I can imagine cases where a connection would simply reuse Chrome IPC as it would be convenient for existing code. I could also imagine a connection that just speaks the Extensions Protocol or Dev Tools Protocol. We have many different protocols in use already in the Chromium world. You could also imagine using protobuf to speak to particular services.

Anyways, Cap'n Proto or something like it is what we have been imagining for the particular format that we would use for most of our connections. It has some very nice properties. As for versioning, I think it is easy to make that have zero cost when you don't need it and minimal cost when you do need it.

More details when I have more free time.

-Darin

[Mounir Lamouri]

On Mon, Oct 7, 2013, at 7:48, Darin Fisher wrote:
> In part with this effort, we are re-thinking IPC. Chrome IPC has served us well, but we see some ways in which it could be improved:
>

> *

> The IPC system should make connections between services and clients more of a first-class concept. We have a lot of code that is effectively just doing that in an ad-hoc fashion for different services.
>

> *

> Related to the above, the IPC system should make it easy to move services to different threads or processes with minimal disruption to clients.
>

> *

> We should have a way to machine-generate C++ bindings for IPC. Imagine if making your code callable from another process was as simple as implementing an interface. That could help with code clarity as well as enable easier/better unit and fuzz testing.
>

> *

> The IPC system should make it easier to setup and pass around byte streams, shared memory and files. There is a bit of a barrier to using these things correctly in the current setup, which often results in people choosing less efficient methods of passing around data.
>

> *

> The IPC system should use a messaging format that is optionally capable of being used in cases where we want to talk between end-points built from different versions of the code base. This would open up the possibility of breaking Chrome up into components that are versioned separately. (Note: We already do this to a certain extent by leveraging Pepper, but growing Pepper for these use cases is costly if the APIs are not general purpose.)
>

> *

> Related to the above, we should have a binary pickling format that is more resilient to version skew. See the mess that is content/common/page_state_serialization.cc for an example of how base::Pickle is not at all the right choice for archiving data structures.

Did you had a look at IPDL (Inter-Process Protocol Definition Language)
[1]? It seems to meet a few of the points above.

[1] https://wiki.mozilla.org/IPDL
--
Mounir

[Adam Barth]

On Mon, Oct 28, 2013 at 11:12 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:

Did you had a look at IPDL (Inter-Process Protocol Definition Language)

[1]? It seems to meet a few of the points above.

From a brief skim of the wiki, that system seems to be coupled with XPCOM.

Adam

 

[1] https://wiki.mozilla.org/IPDL

[Mounir Lamouri]

Obviously, it is assuming Mozilla specific types like nsTArray, nsString, etc. Excepted that, IPDL is not strongly linked to XPCOM, as far as I remember. This said, this applies for the language itself (IPDL), it might be different for the internals.

 

-- Mounir

[Paweł Hajdan, Jr.]

Just my opinion: isn't XPCOM and infrastructure related to it complex and making code using it also complex?

I was under impression this was one of major technical difficulties in Mozilla land, probably not without benefits, but in Chrome land I think we strive no to create overly complex solutions (sometimes code needs to be complex because it's solving a difficult problem, but it shouldn't be complicated).

Paweł

[Darin Fisher]

I haven't reviewed IPDL before. It is interesting how a single interface contains messages intended for the parent and for the child.

Note, we intend Mojo IPC to be sensible for communication between any two peers in the system. They need not have a parent / child relationship.

-Darin

[Darin Fisher]

Don't worry. There's no chance that we'll be using XPCOM in Chromium. I think Mounir pointed out that IPDL doesn't strictly speaking require XPCOM. I'm sure there is code though to create convenient bindings to XPCOM :-)

-Darin