There's likely a bunch of work that needs to be done here. Currently the lifetimes of objects generally require co-operation for management. We should aim to fix this after bug 858914. As a first step we should just focus on areas that could be actively exploited and not worry about resource exhaustion.

My understanding is that the main specific known problem is this: The parent maintains some tree of layers that it is going to compose together. It makes some assumptions about the lifetimes of the nodes in this tree (e.g. child nodes outlive their parent or some such). However, the child can send IPC messages to cause layers to get deleted. But, since they will still be in the layer tree, the compositor will still try to use them; that is a use-after-free. My understanding that the more general problem is that "none" (to quote some graphics people) of the graphics IPC code has been designed to be a security boundary. kang: Could you please share this with the other people in b2g land who should know about this? Also, could you please comment on the relative priority of this bug in terms of B2G system security? I imagine it must be at the top.

From comment 1, it sounds like this could be a real problem as is, rather than purely a defense-in-depth desired thing.

Who can we assign this to? Jeff?

We don't have the capacity on act on this right now, so we don't have anybody to assign it to. Needs to be escalated.

Lucas do you know who could take this one?

Honestly I'm not familiar with this code. Adding jlebar as he can probably point us in the right direction.

I'm sorry to continue to kick the can, but I'm not at all familiar with this stuff, and I'm not sure who is, outside the gfx team. Maybe dzbarsky. :)

Lucas, Justin is no longer here, and this bug needs to be owned by someone. Can you help?

Per Justin's comment though this requires GFX knowledge. I suggest we pair up a GFX person with an IPC person to work through this. Next week seems like a great opportunity to kickstart the discussion. I nominate Gregor to lead (or better yet delegate) the IPC side. Also cc'ing two engineers who are ramping up on IPC, Alexandre and Cervantes.

That's a good suggestion, but I still don't see gfx being available until B2G 26 issues get taken care of. I've explicitly added the dependency on the bug 858914 that fixes the object lifetimes. That one is still in progress.

Guillaume just a nudge to make sure you saw comment 1 (or in case it fell off the radar).

it sounds like to me that while comment 0 is pretty generic, comment 1 is specifically about the graphics IPC We're working on documenting the issue in general (for any API/use of IPC) at https://wiki.mozilla.org/Security/B2G/FirefoxOSCommsHardening For the very issues mentioned in comment 1, we're trying to prioritize right now - but any such issue is going to relatively high priority to fix. If there's a use after free which can be triggered through arbitrary IPC messages in the graphics code, this _is_ top priority to fix.

Jeff, let's start talking about what would be involved with this in a bit more detail.

Do we have any fuzzing infrastructure for IPC?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #14) > Do we have any fuzzing infrastructure for IPC? Yes, see bug 777067 where Christoph is working on this.

Setting wontfix basically everywhere if this is targeted for B2G 1.4, which is based on Gecko 30.

Changing summary a bit to clarify why we think this bug is sec-critical (hackable) as opposed to sec-want (harden). (In reply to Jeff Muizelaar [:jrmuizel] from comment #14) > Do we have any fuzzing infrastructure for IPC? Our current IPC fuzzing is at the pickle layer and may not work well for fuzzing object lifetimes.

(In reply to Daniel Veditz [:dveditz] from comment #17) > Our current IPC fuzzing is at the pickle layer I know that this must sound perfectly reasonable to the specialists, but taken out of context, "Our current IPC fuzzing is at the pickle layer" is an awesome thing to say. "Les cornichons" by Nino Ferrer https://www.youtube.com/watch?v=BOGuJRUsQls

We should keep landing these if we have time, but it does not block 1.4

With bug 963790 done, we have all gfx/layers IPC protocols at least sufficiently hardened for e10s desktop linux (with OpenGL layers) to successfully complete a reftest run without any crash or Address Sanitizer error. So the only thing that remains to be done here is complete a reftest run on B2G. This is almost, but not quite the same: there are some Gfx IPC things that are specific to B2G, at least the PGrallocBuffer protocol.

After some successful manual testing on B2G, trying to run reftest with Faulty in GDB but failing because GDB+emulator is still a losing combination (tried both emulator and emulator-jb) and manually inspecting PGrallocBuffer implementation, I think we should close this bug here, i.e. bug 963790 was all what needed to be done here.

Marking [qa-] for verification based on comments 20 and 21.

driver for this was IPC in b2g [as I read c#20/21], wontfix for SeaMonkey 2.26.1 (Gecko 29-based)