Re: [Public WebGL] WebGL Shader Validation

[Alan Chaney <alan@mechnicality.com>]

Hi Daniel

On 06/18/2010 11:29 AM, Daniel Koch wrote:

Now flip down to Appendix A: Limitations for ES 2.0 (p108), where it says (among other things): 

1. OpenGL ES 2.0 implementations are not required to support the full GLSL ES 1.00 specification. ...

...

4. In general, control flow is limited to forward branching and to loops where the maximum number of iterations can easily be determined at compile time.

Hope this helps

Daniel

Yes it does. I've now studied Appendix A.


To clarify my position, I think that this thread is discussing 3 different things:

1. The requirements for shader validation.

2. The ways in which a shader could be maliciously manipulated to create a denial-of-service exploit.

3. The problems and issues connected with hardware and O/S features relating to overcoming 2. above.

My focus is on 2. I believe that for the widespread adoption of WebGL it is essential that all possible steps are taken to avoid DOS attacks.

If one of the ways of doing this is to put restrictions on the capabilities of the shaders then I would hope that:

1. Those restrictions should apply to all shader implementations
2. They should be clearly defined in the WebGL specification.

Sadly, although the points that have been discussed may help, I have a feeling that without some kind of enforceable timeout, malicious individuals will determine ways to write shaders which can pass validation but will still take an unacceptably long time to execute. Since it appears that the timeout is not going to be easy


Regards

Alan

On 2010-06-18, at 12:25 PM, Alan Chaney wrote:

I have the OpenGL ES 2 shader specification 1.00 rev 17 open in front of me:

It says: (Sec  6.3 Iteration pp57)

"Non-terminating loops are allowed. The consequences of very long or non-terminating loops are platform dependent."


It appears to me that a syntactically correct loop could be:

for ( int i = 0; i < 5; i ++) {

    i = i - 1;

    // whatever else you want to do here...
}


Regards

Alan





On 06/18/2010 09:09 AM, Cauê Waneck wrote:

Another solution could be to only allow loops that can be unrolled at compile time. Couldn't it? I actually thought that OpenGL ES 2.0 specs already had this limitation.

2010/6/18 Chris Marrin <cmarrin@apple.com>

On Jun 17, 2010, at 10:24 PM, Oliver Hunt wrote:

> On Jun 17, 2010, at 6:46 PM, Vladimir Vukicevic wrote:
>
>>
>> ----- "Steve Baker" <steve@sjbaker.org> wrote:
>>
>>> Since there is little or no practical use for shader programs that don't
>>> complete within a very small fraction of a second - a one second (or so)
>>> watchdog timer would seem to be the best - and perhaps only - pragmatic
>>> solution.  We could even allow users to set how long the timer would
>>> wait before killing the web page in some 'about:config' page just in
>>> case they want to use WebGL for some kind of non-traditional use (eg
>>> CUDA-like applications).
>>
>> If we had a way to do this (abort execution while inside a long-running shader), we wouldn't be having this conversation :-)  The problem is that in most cases your entire system is locked up waiting for the GPU to come back; Windows Vista/7 handles this case by forcibly resetting the entire graphics card (and thus killing any contexts), which is probably the best response for now.  But that functionality isn't available to any programs to use directly, and no equivalent exists on other platforms.  Something might happen on that front, but even if it does we need a solution for older (current) driver versions; that solution might be "you don't get to run complex shader programs until you upgrade your drivers", though.
>
> The other issue that exists is that even if the OS was willing to kill off the GPU insanely quickly (say 5ms), i could still write a piece of code that hammered the GPU by restarting the bad shader.  This would (effectively) produce a DoS of the entire machine.

_javascript_ will kick in its timeouts if you do this, so that's not a problem. As long as the GPU can kick the shader in a reasonable amount of time and the damage to the system due to the GPU reset is not unrecoverable, you will be able to get back control of your system.

-----
~Chris
cmarrin@apple.com

-----------------------------------------------------------
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:

---

                        Daniel Koch -+- daniel@transgaming.com

Senior Graphics Architect -+- TransGaming Inc.  -+- www.transgaming.com

!DSPAM:4c1bbd44195772051017194!