Re: CSS shaders DoSing the browser?

Hi Gregg,

As Dean mentioned, we are in the process of figuring out how to reduce the attack surface for CSS shaders and one of the things we are exploring is reducing the functionality of fragment shaders (for now), until the timing channel can be effectively shut down by more recent GPU features.

For the vertex shader, I was not aware of this particular DoS scenario, so thanks for raising it. Our approach to security issues has been to focus on the ones that are unique to CSS shaders, compared to WebGL. Here, the DoS attack you describe does apply to CSS shaders, but is shared with WebGL as illustrated by your WebGL demonstration.

Since this is a shared problem between WebGL and CSS Shaders, it might be good for the two working groups to discuss this issue together? Or do you already have a solution to prevent this from happening in WebGL?

Thanks,
Kind regards,
Vincent Hardy

On Mar 1, 2012, at 10:40 AM, Dean Jackson wrote:


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