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

Re: [Public WebGL] Shader validation and limitations



If "It will not ensure that shaders are safe" (ie if it leaves loopholes
for the malicious) then all you're doing is needlessly restricting the
good-guys.  Shaders that get stuck in infinite loops are
super-spectacularly rare in ordinary development and are almost always
found during basic debugging.  For any measurable number of them to show
up in the wild, they'll have to be malicious - and then any loophole,
however tiny is as bad as leaving the gate wide open.  IMHO, we should
only really care about this in the context of malicious people
deliberately trying to shut down people's computers.   If we can't tweak
the spec to make it utterly impossible for infinite loops (or even
ridiculously long but finite loops) - then we might as well not bother
since we'll need a timeout/kill mechanism anyway.

The timeout approach is a good one because it directly applies a limit
to user-inconvenience - no matter how it's inflicted.  If people are
using CPU-based software-emulated shaders then the number of loops that
will annoy a user is much lower than for those with an honest to
goodness GPU.   So a fixed (say) 1 second timeout is "The Right Thing". 

As far as most people are concerned, a computer that's "locked up" for
even 30 seconds is as bad as a locked-up-forever computer because
they're going to push the big red button before they ever find out that
it would eventually have completed.

  -- Steve

Chris Marrin wrote:
> If you look at section A.4 of the SLES spec:
>
> 	http://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf
>
> you'll see the minimal requirements of GLSL ES shaders, specifically control flow. I think we should adopt these rules in their entirety. It will not ensure that all shaders are safe, but it will avoid obvious mistakes like infinite loops. It also reduces the floorplan of the shader language a bit to make it easier to to do a better job of validation.
>
> I also like Vlad's suggestion of restricting loop indices to ints (as opposed to ints plus floats). This will allow us to accurately determine the number of iterations a for loop will perform so we can choose to reject those that go over some limit.
>
> I believe this solves the halting problem issue, (although I suspect Ken disagrees with me). But doesn't necessarily prevent a shader from running for an extremely long time, which I suppose is the same thing in most cases.
>
> I think we should be as restrictive as possible in the first release. It is much easier to relax restrictions than to tighten them.
>
> -----
> ~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:
>
>   

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