Re: CSS shaders DoSing the browser?

On 01/03/2012, at 1:56 PM, Gregg Tavares (勤) wrote:

> As you're probably aware, it's possible to effectively lock up certain machines by giving the GPU something that takes a long time to do.
> 
> Windows gets around this problem by resetting the GPU after a couple of seconds if it becomes unresponsive.
> Newer Linux GL drivers support the GL_ARB_robustness extension that provides a similar feature to Windows.
> In the future GPUs will be preemptive.
> 
> In particular though, XP machines, OSX, iOS and Android as far as I know all basically freeze under these conditions. I've kind of assumed that's why Apple has not shipped WebGL in Safari or nor enabled it for regular pages on iOS yet. (Yes, I know I'm assuming that's the reason though I have no actual word from Apple)
> 
> Anyway, CSS shaders have this same problem and I'm not sure if people are aware of the issue.
> 
> I think most people believe you need complex shaders to DoS the GPU. In fact you need no shaders. You can DoS even a fixed function GPU just by giving it lots of very large polygons to draw.
> 
> As an example here's a sample that demonstrates the issue
> 
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/extra/lots-of-polys-shader-example.html
> 
> The sample draws one subdivided plane. This is analogous to using the vertexMesh attribute in CSS shaders. The vertex shader then, knowing the resolution of the mesh, expands each sub-quad to the full size of rendering surface. The fragment shader is minimal effectively the same that would be used for CSS shaders with no extra effects applied.
> 
> In this particular case I set the subdivision to 1000 which is equivalent to vertexMesh: 1000, 1000 but I believe even a setting of 100x100 would be enough to DoS many slower GPUs.
> 
> There may be work arounds, you can limit each draw call to only 100 polygons for example and that might solve the problem. On the other hand that might be fairly limiting in terms of speed for more interesting effects. For example if you used a monospace font you should be able to do something like this with CSS shaders
> 
> http://www.html5rocks.com/en/tutorials/webgl/million_letters/million_letters.html
> 
> But that only runs smoothly if it's 1 draw call. Splitting it into one draw call for every 100 sub-quads on the off chance that the shader might draw every quad really large would likely kill perf for shaders that don't. 
> 
> Has this been considered?

There have been informal discussions about how we can address the issue of security (including DoS). Vincent posted a link to a wiki page.

Most of that has been considering fragment shaders, but since one of the possible outcomes is either disallowing the fragment step or providing a fixed function fragment shader (at least while the issues you allude to above are unaddressed) we're now looking at the vertex stage. Obviously we can't allow any resolution to be given for the mesh. It would also be less-than-ideal if the maximum resolution was implementation and hardware dependent, even though there will always be content that works better on some hardware.

Your example is helpful to demonstrate that even a shader with a cheap fragment stage can be problematic.

BTW, I'm interested to know why Chrome ships with WebGL enabled by default when it is so easy to freeze or crash the system. As Chris mentioned, even on newer Windows resetting the GPU is potentially very bad.

Dean