Mojo message fuzzing

[Oliver Chang]

Hi all,

I'm working on extending the existing IPC fuzzer to be able to work with Mojo interface messages, and have a few questions.

The current IPC fuzzer works by making Chrome renderers set an outgoing message filter (if ENABLE_IPC_FUZZER is defined) on each render thread's IPC channel to intercept and dump messages to disk. These messages can then be deserialized, mutated by the fuzzer and replayed back to the browser through --renderer-cmd-prefix. Generating messages out of thin air is also supported.

My questions are these (I'm completely new to Mojo):

- What would be a good place to dump Mojo interface messages coming from the renderer? Considering that we will need to serialize/deserialize these messages afterwards, and the fact that message types are scoped to their interface, it seems that the places where this can be done are limited. The generated Interface::Proxy_ seems like a good place, but I'm not sure what the best way of keeping track of which ones we're interested in dumping is (probably ones where the corresponding InterfaceRequest was passed to ConnectToRemoteService?).

- I would like to extend the IDL compiler to generate representations (i.e. fuzz bindings -- .fuzz.{cc,h} files) of interface message structs that make it easy to serialize/deserialize (to from std::tuple<ArgTypes...> for each message type). Does this seem like the right approach?

[Ken Rockot]

On Fri, May 6, 2016 at 9:26 AM, Oliver Chang <och...@chromium.org> wrote:

Hi all,

I'm working on extending the existing IPC fuzzer to be able to work with Mojo interface messages, and have a few questions.

The current IPC fuzzer works by making Chrome renderers set an outgoing message filter (if ENABLE_IPC_FUZZER is defined) on each render thread's IPC channel to intercept and dump messages to disk. These messages can then be deserialized, mutated by the fuzzer and replayed back to the browser through --renderer-cmd-prefix. Generating messages out of thin air is also supported.

My questions are these (I'm completely new to Mojo):

- What would be a good place to dump Mojo interface messages coming from the renderer? Considering that we will need to serialize/deserialize these messages afterwards, and the fact that message types are scoped to their interface, it seems that the places where this can be done are limited. The generated Interface::Proxy_ seems like a good place, but I'm not sure what the best way of keeping track of which ones we're interested in dumping is (probably ones where the corresponding InterfaceRequest was passed to ConnectToRemoteService?).

The right place to capture most incoming messages is going to be the generated Stub object. The Proxy is a message sender, but it can also receive response messages, and those would need to be captured as well.

- I would like to extend the IDL compiler to generate representations (i.e. fuzz bindings -- .fuzz.{cc,h} files) of interface message structs that make it easy to serialize/deserialize (to from std::tuple<ArgTypes...> for each message type). Does this seem like the right approach?

I'm not sure I understand this suggestion. Could you elaborate? Do you essentially just want a kind of InterfacePtr which outputs a message buffer instead of sending a message, and a Binding which receives a message buffer instead of reading from a pipe? If so, we can accommodate these things today without generating new code.

 

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAFqAZOLWpPssggpGyDAvDqsTUeyNNFg%2BiBYNWCVkW05e8i9UqQ%40mail.gmail.com.

[Oliver Chang]

Thanks for the reply!

On Fri, May 6, 2016 at 9:40 AM Ken Rockot <roc...@chromium.org> wrote:

On Fri, May 6, 2016 at 9:26 AM, Oliver Chang <och...@chromium.org> wrote:

Hi all,

I'm working on extending the existing IPC fuzzer to be able to work with Mojo interface messages, and have a few questions.

The current IPC fuzzer works by making Chrome renderers set an outgoing message filter (if ENABLE_IPC_FUZZER is defined) on each render thread's IPC channel to intercept and dump messages to disk. These messages can then be deserialized, mutated by the fuzzer and replayed back to the browser through --renderer-cmd-prefix. Generating messages out of thin air is also supported.

My questions are these (I'm completely new to Mojo):

- What would be a good place to dump Mojo interface messages coming from the renderer? Considering that we will need to serialize/deserialize these messages afterwards, and the fact that message types are scoped to their interface, it seems that the places where this can be done are limited. The generated Interface::Proxy_ seems like a good place, but I'm not sure what the best way of keeping track of which ones we're interested in dumping is (probably ones where the corresponding InterfaceRequest was passed to ConnectToRemoteService?).

The right place to capture most incoming messages is going to be the generated Stub object. The Proxy is a message sender, but it can also receive response messages, and those would need to be captured as well.

Do we actually need to capture the responses? For our purposes, we just wish to replay messages from a child process (renderer for now) to the browser, and ignore anything the browser sends back.

 

- I would like to extend the IDL compiler to generate representations (i.e. fuzz bindings -- .fuzz.{cc,h} files) of interface message structs that make it easy to serialize/deserialize (to from std::tuple<ArgTypes...> for each message type). Does this seem like the right approach?

I'm not sure I understand this suggestion. Could you elaborate? Do you essentially just want a kind of InterfacePtr which outputs a message buffer instead of sending a message, and a Binding which receives a message buffer instead of reading from a pipe? If so, we can accommodate these things today without generating new code.

What our fuzzer needs to be able to do given an arbitrary mojo::Message*, and its interface name, be able to mutate the fields such that it's still a valid message (not just e.g. blindly bitflipping the buffer). Even if the Message_Param_Data structs were exposed in the header for us, it's no use for us without reflection to know what the actual fields are.

So, I'm proposing to generate new code to expose a way of expressing parameters in a message as a std::tuple<ParamTypes...>, which lets us write template specialisations to mutate/generate the individual fields of a message, as well as functions to serialize/deserialize messages from these tuples.

This is similar to how it's done now (FuzzTraits) for the old IPC messages (where params were base::Tuple<>s whose type was part of the MessageT).

[Yuzhu Shen]

On Fri, May 6, 2016 at 9:52 AM, Oliver Chang <och...@chromium.org> wrote:

Thanks for the reply!

On Fri, May 6, 2016 at 9:40 AM Ken Rockot <roc...@chromium.org> wrote:

On Fri, May 6, 2016 at 9:26 AM, Oliver Chang <och...@chromium.org> wrote:

Hi all,

I'm working on extending the existing IPC fuzzer to be able to work with Mojo interface messages, and have a few questions.

The current IPC fuzzer works by making Chrome renderers set an outgoing message filter (if ENABLE_IPC_FUZZER is defined) on each render thread's IPC channel to intercept and dump messages to disk. These messages can then be deserialized, mutated by the fuzzer and replayed back to the browser through --renderer-cmd-prefix. Generating messages out of thin air is also supported.

My questions are these (I'm completely new to Mojo):

- What would be a good place to dump Mojo interface messages coming from the renderer? Considering that we will need to serialize/deserialize these messages afterwards, and the fact that message types are scoped to their interface, it seems that the places where this can be done are limited. The generated Interface::Proxy_ seems like a good place, but I'm not sure what the best way of keeping track of which ones we're interested in dumping is (probably ones where the corresponding InterfaceRequest was passed to ConnectToRemoteService?).

The right place to capture most incoming messages is going to be the generated Stub object. The Proxy is a message sender, but it can also receive response messages, and those would need to be captured as well.

Do we actually need to capture the responses? For our purposes, we just wish to replay messages from a child process (renderer for now) to the browser, and ignore anything the browser sends back.

The reason is that interfaces could be provided by both sides, therefore, you will have requests and responses flowing in both directions.

 

 

- I would like to extend the IDL compiler to generate representations (i.e. fuzz bindings -- .fuzz.{cc,h} files) of interface message structs that make it easy to serialize/deserialize (to from std::tuple<ArgTypes...> for each message type). Does this seem like the right approach?

I'm not sure I understand this suggestion. Could you elaborate? Do you essentially just want a kind of InterfacePtr which outputs a message buffer instead of sending a message, and a Binding which receives a message buffer instead of reading from a pipe? If so, we can accommodate these things today without generating new code.

What our fuzzer needs to be able to do given an arbitrary mojo::Message*, and its interface name, be able to mutate the fields such that it's still a valid message (not just e.g. blindly bitflipping the buffer). Even if the Message_Param_Data structs were exposed in the header for us, it's no use for us without reflection to know what the actual fields are.

So, I'm proposing to generate new code to expose a way of expressing parameters in a message as a std::tuple<ParamTypes...>, which lets us write template specialisations to mutate/generate the individual fields of a message, as well as functions to serialize/deserialize messages from these tuples.

This is similar to how it's done now (FuzzTraits) for the old IPC messages (where params were base::Tuple<>s whose type was part of the MessageT).

This seems a possible direction to me, although it is painful to maintain another binding generator. I am thinking whether it is possible to do it using the custom type mapping approach. The feature is still under development, I can think more about how to support your scenario.

 

 

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAFqAZOLWpPssggpGyDAvDqsTUeyNNFg%2BiBYNWCVkW05e8i9UqQ%40mail.gmail.com.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAFqAZOJKZM%2Bm0EO1BOR-YAybdbAFFvL2uf45xieNb_5%2BWxii_A%40mail.gmail.com.

[Yuzhu Shen]

On Fri, May 6, 2016 at 10:05 AM, Yuzhu Shen <yzs...@chromium.org> wrote:

On Fri, May 6, 2016 at 9:52 AM, Oliver Chang <och...@chromium.org> wrote:

Thanks for the reply!

On Fri, May 6, 2016 at 9:40 AM Ken Rockot <roc...@chromium.org> wrote:

On Fri, May 6, 2016 at 9:26 AM, Oliver Chang <och...@chromium.org> wrote:

Hi all,

I'm working on extending the existing IPC fuzzer to be able to work with Mojo interface messages, and have a few questions.

The current IPC fuzzer works by making Chrome renderers set an outgoing message filter (if ENABLE_IPC_FUZZER is defined) on each render thread's IPC channel to intercept and dump messages to disk. These messages can then be deserialized, mutated by the fuzzer and replayed back to the browser through --renderer-cmd-prefix. Generating messages out of thin air is also supported.

My questions are these (I'm completely new to Mojo):

- What would be a good place to dump Mojo interface messages coming from the renderer? Considering that we will need to serialize/deserialize these messages afterwards, and the fact that message types are scoped to their interface, it seems that the places where this can be done are limited. The generated Interface::Proxy_ seems like a good place, but I'm not sure what the best way of keeping track of which ones we're interested in dumping is (probably ones where the corresponding InterfaceRequest was passed to ConnectToRemoteService?).

The right place to capture most incoming messages is going to be the generated Stub object. The Proxy is a message sender, but it can also receive response messages, and those would need to be captured as well.

Do we actually need to capture the responses? For our purposes, we just wish to replay messages from a child process (renderer for now) to the browser, and ignore anything the browser sends back.

The reason is that interfaces could be provided by both sides, therefore, you will have requests and responses flowing in both directions.

 

 

- I would like to extend the IDL compiler to generate representations (i.e. fuzz bindings -- .fuzz.{cc,h} files) of interface message structs that make it easy to serialize/deserialize (to from std::tuple<ArgTypes...> for each message type). Does this seem like the right approach?

I'm not sure I understand this suggestion. Could you elaborate? Do you essentially just want a kind of InterfacePtr which outputs a message buffer instead of sending a message, and a Binding which receives a message buffer instead of reading from a pipe? If so, we can accommodate these things today without generating new code.

What our fuzzer needs to be able to do given an arbitrary mojo::Message*, and its interface name, be able to mutate the fields such that it's still a valid message (not just e.g. blindly bitflipping the buffer). Even if the Message_Param_Data structs were exposed in the header for us, it's no use for us without reflection to know what the actual fields are.

So, I'm proposing to generate new code to expose a way of expressing parameters in a message as a std::tuple<ParamTypes...>, which lets us write template specialisations to mutate/generate the individual fields of a message, as well as functions to serialize/deserialize messages from these tuples.

This is similar to how it's done now (FuzzTraits) for the old IPC messages (where params were base::Tuple<>s whose type was part of the MessageT).

This seems a possible direction to me, although it is painful to maintain another binding generator. I am thinking whether it is possible to do it using the custom type mapping approach. The feature is still under development, I can think more about how to support your scenario.

I mean, "we" can think more about how to support your scenario. :)

[Oliver Chang]

On Fri, May 6, 2016 at 10:08 AM Yuzhu Shen <yzs...@chromium.org> wrote:

On Fri, May 6, 2016 at 10:05 AM, Yuzhu Shen <yzs...@chromium.org> wrote:

On Fri, May 6, 2016 at 9:52 AM, Oliver Chang <och...@chromium.org> wrote:

Thanks for the reply!

On Fri, May 6, 2016 at 9:40 AM Ken Rockot <roc...@chromium.org> wrote:

On Fri, May 6, 2016 at 9:26 AM, Oliver Chang <och...@chromium.org> wrote:

Hi all,

I'm working on extending the existing IPC fuzzer to be able to work with Mojo interface messages, and have a few questions.

The current IPC fuzzer works by making Chrome renderers set an outgoing message filter (if ENABLE_IPC_FUZZER is defined) on each render thread's IPC channel to intercept and dump messages to disk. These messages can then be deserialized, mutated by the fuzzer and replayed back to the browser through --renderer-cmd-prefix. Generating messages out of thin air is also supported.

My questions are these (I'm completely new to Mojo):

- What would be a good place to dump Mojo interface messages coming from the renderer? Considering that we will need to serialize/deserialize these messages afterwards, and the fact that message types are scoped to their interface, it seems that the places where this can be done are limited. The generated Interface::Proxy_ seems like a good place, but I'm not sure what the best way of keeping track of which ones we're interested in dumping is (probably ones where the corresponding InterfaceRequest was passed to ConnectToRemoteService?).

The right place to capture most incoming messages is going to be the generated Stub object. The Proxy is a message sender, but it can also receive response messages, and those would need to be captured as well.

Do we actually need to capture the responses? For our purposes, we just wish to replay messages from a child process (renderer for now) to the browser, and ignore anything the browser sends back.

The reason is that interfaces could be provided by both sides, therefore, you will have requests and responses flowing in both directions.

Ah, I see.

 

 

 

- I would like to extend the IDL compiler to generate representations (i.e. fuzz bindings -- .fuzz.{cc,h} files) of interface message structs that make it easy to serialize/deserialize (to from std::tuple<ArgTypes...> for each message type). Does this seem like the right approach?

I'm not sure I understand this suggestion. Could you elaborate? Do you essentially just want a kind of InterfacePtr which outputs a message buffer instead of sending a message, and a Binding which receives a message buffer instead of reading from a pipe? If so, we can accommodate these things today without generating new code.

What our fuzzer needs to be able to do given an arbitrary mojo::Message*, and its interface name, be able to mutate the fields such that it's still a valid message (not just e.g. blindly bitflipping the buffer). Even if the Message_Param_Data structs were exposed in the header for us, it's no use for us without reflection to know what the actual fields are.

So, I'm proposing to generate new code to expose a way of expressing parameters in a message as a std::tuple<ParamTypes...>, which lets us write template specialisations to mutate/generate the individual fields of a message, as well as functions to serialize/deserialize messages from these tuples.

This is similar to how it's done now (FuzzTraits) for the old IPC messages (where params were base::Tuple<>s whose type was part of the MessageT).

This seems a possible direction to me, although it is painful to maintain another binding generator. I am thinking whether it is possible to do it using the custom type mapping approach. The feature is still under development, I can think more about how to support your scenario.

I mean, "we" can think more about how to support your scenario. :)

Thanks!