[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] ARB_robustness and array bounds checking




On Oct 26, 2011, at 1:24 PM, Kenneth Russell wrote:

On Wed, Oct 26, 2011 at 11:53 AM, Chris Marrin <cmarrin@apple.com> wrote:

On Oct 25, 2011, at 10:23 AM, Gregg Tavares (wrk) wrote:

>
>
> ...Requiring driver vendors to use one-of-n fallback techniques will eventually require some vendor to go down a slow path or ignore your requirements. I think the way section 4.5 is written today is sufficient. We should make section 6.4 match that, which would make it match the ARB_robustness spec. I don't have a solution for your testability requirement, and I think testability is a nice goal, but in this case not at the expense of performance.
>
> This is a security issue. Doesn't Apple want to be able to verify that you can't read data you're not supposed to be able to read?

I don't believe testability is an overriding requirement of WebGL. It's a good goal, but I don't think it should be required in the spec. We should (continue to) strive for maximizing performance.

This thread started with me proposing we drop the requirement in section 6.4 that an out-of-bounds array access return an error, thus requiring expensive intervention at the WebGL layer. If the wording of section 6.4 matched that in section 4.5, then we could make WebGL implementations more performant if the driver can guarantee appropriate handling of out-of-range accesses. In particular, the wording from section 6.4:

-----
If a vertex attribute is enabled as an array, a buffer is bound to that attribute, and the attribute is consumed by the current program, then calls to drawArrays and drawElements will verify that each referenced vertex lies within the storage of the bound buffer. If the range specified in drawArrays or any referenced index in drawElements lies outside the storage of the bound buffer, an INVALID_OPERATION error is generated and no geometry is drawn.
-----

should be changed to:

-----
If a vertex attribute is enabled as an array, a buffer is bound to that attribute, and the attribute is consumed by the current program, then calls to drawArrays and drawElements shall ensure that no accesses outside the bounds of that vertex buffer occur. If detected when the drawArrays or drawElements call is made, an INVALID_OPERATION error is generated and no geometry is drawn. Otherwise, at runtime and invalid access may return a constant value (such as 0), or the value at any valid index of the same vertex buffer. In this case (possibly incorrect) geometry would be rendered and no error would be generated. But no accesses outside the vertex buffer bounds would occur.
-----

(typo: runtime and => runtime an)

This change wouldn't allow the use of GL_ARB_robustness' robust buffer access as specified today. Robust buffer access only guarantees the following: "indices within the vertex array that lie outside the arrays defined for enabled attributes result in undefined values for the corresponding attributes, but cannot result in application failure". See http://www.opengl.org/registry/specs/ARB/robustness.txtFor example, it might fetch other random data reachable by the context (and, hopefully, produced by that context).

Yes, I noticed that. But I also thought the text I wrote essentially matches the DX10 behavior mandated by Microsoft. If so, this should be an achievable goal for driver vendors.


What's the goal? To allow the use of robust buffer access as currently written, or to specify stronger guarantees for ARB_robustness and incorporate those into the WebGL spec? If the latter, then I think we should spec the stronger robust buffer access first, so that GPU vendors are on board, and we know what the parameters will be.

Right. We should get with the driver vendors and understand their current, DX10 motivated, behavior. Then we can hopefully mandate that behavior in ARB_robustness.


From a process standpoint I'd like to wait to make a change like this until after we've snapshotted the next version of the WebGL spec, because this is a significant change requiring a good deal of consideration.

I can live with that. The whole point of this is to allow us to eventually, on some hardware, get rid of the shadow copy of the array indices and the need to run through them on each call to drawElements.