Changes some of the dependencies to remove...

Changes some of the dependencies to remove
client side arrays. 

TEST=none
BUG=71717
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=74392

[greggman, 2011-02-09 01:39:16]

not sure who to ask about this.

There was a bug in the WebGL code that effectively allowed JavaScript to call
OpenGL and cause an arbitrary memcpy to get called.

Mo has supposedly fixed the bug but the security team wanted me to take more
steps.

In this particular case the bug was a call glDrawElements that used a client
side array (an array in client memory). The Command Buffer does not directly
support this but there is code on the client side that emulates this feature of
OpenGL. The feature is not needed by Chrome nor by WebGL. It is only needed by
Pepper and the OpenGL ES 2.0 conformance tests to be 100% compatible.

So, I attempted make 2 versions of the client side libraries. One has support
for client side arrays to be used by Pepper. One does not, used for Chrome and
WebGL.

I was under the impression this wouldn't be a problem because code running in
Pepper has to be compiled for NaCl which includes the plugin client side
interface code.

But, I'm not sure where that happens. I thought it was in webkit_glue.gypi, the
'glue' target seemed to be about pepper to me but I guess I was wrong. In
Windows if I link with support for client side arrays there I get support
everywhere :-(

As it is, if Pepper is using 'glue' in webkit_glue.gypi this CL will probably
break most 3rd party pepper programs.

So, solutions?

1) Is there a way to use a different version of this library with Pepper?

2) Or, should I make this a runtime switch in GLES2Implementation?

3) ??

[brettw, 2011-02-10 06:48:26]

Was this reviewed by anybody?

+neb

So the problematic code is in the producer side of the command buffer. I think
we assume that everything writing to the command buffer is untrusted. In NaCl,
(this is where Neb should correct me) I think this code is run in the insecure
side of the boundary. So bugs in this layer that crash or do weird things should
be fine.

In-process Pepper plugins can already write to any code in the renderer so
aren't secure in this way.

So I'm not sure anything needs to be done to address this problem.