On Thu, Jan 28, 2016 at 11:33 AM, Daniel Cheng
<dch...@chromium.org> wrote:
A couple questions:
These are great questions. In general we're still putting some of the relevant pieces (and documentation) together, but all of these concerns either have a working solution or a solution in progress at the moment.
For security:
- I assume that mojom changes require security reviews, just like IPC message changes already do, but I don't see any mention of this on the Mojo basics.
Yes. Documenting the security model and review process for Mojo is a TODO. We have however started adding security OWNERs for *.mojom in key places, and as the volume of mojom CLs increases we'll adjust priorities here as needed.
- Are there any security gotchas with IPCs that you won't have to worry about in Mojo? What about the other way around?
The gotchas are largely similar IMHO. I think where we'll ultimately see security improvements in the long term is through the reduced complexity with which we can isolate components.
One thing to be aware of is that, because pipes are so easy to pass around, developers may have to be more mindful about to and from whom they send and receive pipe endpoints. There isn't a good one-size-fits-all rule here though as the Right Thing largely depends on context.
- IPC::ParamTraits provides an easy way for common validation of parameters, so individual message handlers don't have to repeat all that validation (or risk forgetting to validate it at all). What is the analogous mechanism in Mojo?
Though it's still a work in progress for more complex structures, we have an analogous mojo::StructTraits<MojomType, T> in development. This can be used to provide a view of any type T so the bindings layer knows how to serialize it as the mojom-defined struct MojomType.
Likewise a deserializer (mojo::StructTraits<MojomType, T>::Read) can be provided which operates on a view of the serialized message buffer to produce a new T (also work in progress to support move-only or non-default-constructable Ts here.) The deserializer can reject the message, resulting in the bindings signaling an error on the pipe.
What should developers do when adding a new IPC::Message to an existing IPC message handler? Should they add a new IPC::Message, or are there guidelines on how to incrementally move things to Mojo?
This is something to be discussed and established on a case-by-case basis. In the simple case (i.e. an isolated bundle of message types with little or no ordering dependencies), interface pipes can be teased apart piece by piece with no additional complexity.
Finally, I'm curious about the FIFO guarantees of Mojo: in general, if you have two different Mojo interface pointers, there's no guarantee of FIFO ordering between them, right? How will this interact with things that are sensitive to the order of operations, such as cleanup when a frame is detached?
Correct -- no FIFO ordering between independent pipes. The bindings layer does support
associated interfaces which is a way of sharing a single message pipe between multiple bindings endpoints that need relative FIFO.
Daniel
Greetings chromium-dev!
TL;DR: IPC::Message is deprecated. All new IPC in Chrome should use
Mojo.
Mojo has been baking for a long while and is now ready enough for widespread use. In order to avoid having Two Ways to do IPC forever and ever, the Old Way is now deprecated and the New Way is Mojo.
Some compelling features of Mojo which make it better than the legacy alternative:
- Generated bindings capable of supporting all of Chrome's IPC needs including passing around file handles, shared buffers, etc.
- Intuitive abstraction around message routes. What requires a routing ID today can instead be accomplished by creating individual pipes.
- Builtin request-response logic reduces boilerplate around tracking request IDs.
- Support for generating C++, JS, and Java bindings ensures a consistent, write-once messaging protocol everywhere. Services and clients can be written in any of these languages.
There are some great opportunities to improve Chrome in light of this transition, and several projects are under way, including:
- Porting all existing IPC surfaces to Mojo and in the process reconsidering some fundamental architectural choices in the browser to improve security, stability, code health, and user experience.
- Consuming browser services directly from WebUI using Mojo JS bindings, eliminating all the custom messaging that's done today.
- Refactoring the Apps & Extensions system to be built on shared services, deleting lots of redundant code in the process.
- Supporting Mojo clients in the Blink platform layer, also deleting lots of redundant code (and ultimately all of content/renderer and much of content/child) in the process.
There are also a number of meta-efforts under way to ease the transition, including the ability to re-purpose existing IPC::ParamTraits definitions to quickly lift non-mojom types into Mojo messages, as well as providing a means to retain FIFO ordering between certain Mojo interfaces and legacy IPC during the transitional period.
We have a very basic
Mojo in Chromium primer available as a light practical introduction to Mojo, and the
chromium-mojo@chromium.org list is a great place to get quick answers for any Mojo-related questions you may have.
Cheers!
Ken
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev