ResourceHosts that need other ResourceHosts

[David Michael]

Hi,

I've been working on refactoring the ImageData proxy to the "new" resource model, and I'm running in to a little trouble. In the "new" model, ResourceHosts are not reference-counted; the intent is that PpapiHost owns them in its resource_hosts_ map. They get deleted when the plugin releases its last ref-count.

(CCing Brett since this is your baby; if you don't care, you can stop reading).

However, PepperGraphics2DHost currently holds a queue of PPB_ImageData_Impls via scoped_refptr. The plugin may e.g., do one or more calls to PaintImageData or ReplaceContents, and release the IamgeData resource prior to Flush()ing. So the problem is, the ImageData hosts have to live as long as the Graphics2D host needs them, even if the plugin is finished with them.

The straightforward way to solve this is to make ResourceHost inherit RefCounted and start owning them by scoped_refptr in PpapiHost. This is simple to implement, but the perils of RefCounted are well known.

I thought of another approach so that PpapiHost can still own all ResourceHosts. The idea is to allow 1 ResourceHost to "pin" another ResourceHost in memory. We'd make it a rule that any ResourceHost can only ever "pin" or be "pinned", but never both. This guarantees:

• No cycles
  
• The "graph" of lifetime dependencies is only 1 level deep.

Here's an untested draft CL for what it might look like: https://codereview.chromium.org/454433002/

The advantage is that lifetime is easier to underand:

• PpapiHost outlives all ResourceHosts.
  
• No cycles, no deep lifetime dependency graph.
  
• Only ResourceHosts may pin each other (with scoped_refptr, any body who gets a raw pointer to a Host can take a reference).
  

The big disadvantage is that the code is harder to understand, because it's a new concept with non-trivial new supporting code.

So what do you all think, which one are you more willing to help maintain? scoped_refptr or a new "Pin/Unpin" thing? Or do you have something better?

[Bill Budge]

Another way to keep resources alive beyond the time the plugin is using them is to hold a reference to the resource on the plugin side. An example of this is the FileIOResource, which holds a reference to the FileSystemResource.

-Bill

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

[David Michael]

Ha, I wish I'd have thought of that.

Downsides:

- Adds a little complexity to Graphics2DResource.

- A malicious plugin could "lie" about resource deletion while a Graphics2D host is still referencing the ImageData host. I don't think that the use-after-free in the renderer would be exploitable, but we could protect against it anyway with WeakPtr.

But it still sounds better to me than my suggestions, so I'll go with that, unless anybody has any reason not to.

Thanks!

[Raymes Khoury]

That's the typical way we have been doing it :) It does have some
downsides but its probably the simplest thing for now.

[Brett Wilson]

On Thu, Aug 7, 2014 at 12:54 PM, David Michael <dmic...@google.com> wrote:
> Ha, I wish I'd have thought of that.
>
> Downsides:
> - Adds a little complexity to Graphics2DResource.
> - A malicious plugin could "lie" about resource deletion while a Graphics2D
> host is still referencing the ImageData host. I don't think that the
> use-after-free in the renderer would be exploitable, but we could protect
> against it anyway with WeakPtr.

I would assume all use-after-frees are exploitable. Better use a weak
pointer if this is possible.

Brett

[Raymes Khoury]

I believe we do use weak pointers on the host side in all these types
of situations currently.