Re: CSS shaders DoSing the browser?

Hi Greg,

when you said freeze, I didn't realize that it would BSOD my machine!

This looks pretty bad, but where should we put the blame for this issue?
This is not the fault of WebGL or the shaders; it's a driver problem. For
instance if you made a large allocation in JavaScript and your system
freezes or crashes, wouldn't you blame the operating system instead of your
JavaScript VM?

To let browser execute arbitrary OpenGL calls or shaders, the graphics
driver and the model should be enhanced so freezes never happen.
If we can't rely on the them to do a good job, the browser needs to do this
certification.

Maybe we should create a test suite that will ensure that your system is
stable regardless of what graphics calls are made. If a graphics driver
version passes the test, your browser will allow WebGL and shaders.
Otherwise, these features are turned off by default.
Maybe this test suite could also test if timing attacks are possible.
These tests would not verify if the output looks correct; they would just
verify that there are no freezes. Failing to render particular content
(because it's too complex or it allows a timing attack) is fine.

Going this route would push the issue to the graphics vendors where the
problem is actually located.
I believe it is easier to fix this at the source than upstream in the
browser...

Rik

On Wed, Feb 29, 2012 at 6:56 PM, Gregg Tavares (勤) <gman@google.com> 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?
>
>
>
>