Bug 218887 – [GPU Process] Make getImageData directly read the shared backend instead of sending a sync IPC

• Component: Canvas
• Status: RESOLVED INVALID

[Ryosuke Niwa]

We can make getImageData more efficient by flushing the context and reading off of the shared backend instead of sending a sync IPC.

[Ryosuke Niwa]

Created attachment 414004 [details]
Patch

[Tim Horton]

Does this mean we're now reading from the IOSurface mapped in the Web Content process? Because that would be a mistake going forward...

[Tim Horton]

Yes, it does. We can't do this.

[Ryosuke Niwa]

(In reply to Tim Horton from comment #3)
> Yes, it does. We can't do this.

Oh, right. That was another thing wrong with this approach. I guess I'd go back to adding new shared memory region.

[Said Abou-Hallawa]

(In reply to Tim Horton from comment #3)
> Yes, it does. We can't do this.

Can you please explain why "we can't do this"?

If IOSurface/ShareableBitmap mapped in the Web Content process is read-only, it will act exactly as any shared memory we are going to create.

Is there a threat of accessing the IOSurface from the Web Content process even if this access is read-only? Can this cause any security vulnerabilities?

[Tim Horton]

(In reply to Said Abou-Hallawa from comment #5)
> (In reply to Tim Horton from comment #3)
> > Yes, it does. We can't do this.
> 
> Can you please explain why "we can't do this"?
> 
> If IOSurface/ShareableBitmap mapped in the Web Content process is read-only,
> it will act exactly as any shared memory we are going to create.

ShareableBitmap, true. IOSurface, not true. I think you got the details elsewhere, but we won't be able to use IOSurface from the Web Content process, because it is *not* just a trivial shared memory buffer.

[Radar WebKit Bug Importer]

<rdar://problem/71617360>