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

RE: [Public WebGL] Need to spec range checking for WebGL ANGLE_instanced_arrays?

The definition of robust buffer access in ARB_robustness says that the implementation may return undefined values, and these could include data that the WebGL context is not supposed to be able to access. So relying on that is insecure.

ARB_robust_buffer_access_behavior is better in terms of security, but not as widely supported. That's being looked at, but I'd prefer if this thread would just be about what to do with range checking for ANGLE_instanced_arrays. Since the underlying graphics APIs don't always give enough guarantees, some checking needs to be present on the CPU side, and so at least Chrome is currently producing errors that are not explicitly specified. I agree with your suggested minimum of specifying that INVALID_OPERATION is produced whenever an out-of-range attribute would be accessed regardless of the which draw call is made, but it might be easier to interpret the spec as an implementer if it spelled things out a bit more.
From: Florian Bösch [pyalot@gmail.com]
Sent: Tuesday, March 11, 2014 12:27 PM
To: Olli Etuaho
Cc: public_webgl@khronos.org
Subject: Re: [Public WebGL] Need to spec range checking for WebGL ANGLE_instanced_arrays?

On Tue, Mar 11, 2014 at 11:18 AM, Olli Etuaho <oetuaho@nvidia.com<mailto:oetuaho@nvidia.com>> wrote:
> Well, ARB_robustness is not a part of the WebGL spec.
I'm aware of that.

> It's a part of how WebGL is typically implemented on OpenGL, and robust buffer access in ARB_robustness is tangentially related, but it doesn't give solid security guarantees
So your answer is that ARB_robustness does not validate the vertexPointer validity on drawElements, drawArrays and neither on drawElementsInstanced and drawArraysInstanced? My reading of the ARB_robustness specification suggests that ARB_robustness does in fact do those things. Could you please clarify?

> and beyond that I don't see how ARB_robustness would come into play here. The issue is that at least one browser vendor has thought it necessary to have these unspecified checks, so it seems like a good idea to me to correct the omission in the spec and tests.

ARB_robustness comes into play these ways

 1.   if ARB_robustness specifies the checks (and enforces them) than an implementation should use that because:
 2.  Manual checking isn't free, it makes it practically infeasible to use drawElements except under very specific rarely encountered situations. Manual checking means that everytime drawElements is called, that all indices are validated on the CPU. So ARB_robustiness guarantees are of great relevance here.
 3.  Since neither the extension specifications for OpenGL, nor for OpenGL ES extensions, nor the core specification of OpenGL nor the core specification of OpenGL ES defines these checks, and the only reference to checks is to be found in ARB_robustness in the standard specifications, and in two paragraphs in the WebGL specification, it is questionable if further specification is required at all. I think at a minimum the WebGL specification could be updated not to specifically mention drawElements and drawArrays, and make it clear that appropriate range checks would have to be performed regardless of how things are drawn, and regardless of how these checks are implemented underneath.

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl