Re: Constant-time subsets of GLSL (was Re: Documenting Timing Attacks in Rendering Engines)

Off the top of my head you'd have to remove "if", "while" and "?" and
dependent texture lookups (sampling 1 texture based of sampling of another
texture). You might be able to keep 'for' with its current WebGL limits of
only a constant integer input since with no "if" there would be no way to
break out early.

I think you'd probably be able to write many useful shaders with those
limitations

No dependent texture lookups kind of sucks but probably not needed for most
uses of CSS shaders.

I think the confusion about limited GLSL not being useful is the DOS issue
vs the timing issue. You can't limit shaders in any useful way and solve
the DOS issue. In fact you don't even need shaders for the DOS issue. Just
a large mesh. But for the timing issue, removing those 4 features might
solve it.

That assumes none of the math changes time based on input like for example

   float v = pow(1, texture2D(someTex, someUV).r * 10000.0);




On Mon, Dec 12, 2011 at 11:10 PM, Adam Barth <w3c@adambarth.com> wrote:

> On Mon, Dec 12, 2011 at 9:56 PM, Ralph Thomas <ralpht@gmail.com> wrote:
> > On the topic of "constant time GLSL", I was thinking that any value
> > derived from a texture sample read from web content would be
> > "poisoned" so it could not be used for conditionals and that the
> > poison would propagate to any dependent value in the program. You
> > could assign a poisoned value to gl_FragColor (obviously) but could
> > not branch or loop on it.
> >
> > This would still let you write blur kernels, do lighting effects and
> > warp texture coordinates, but you wouldn't be able to use any part of
> > the texture as a lookup table, for example.
>
> In principle, this approach can work.  To be fully correct, the
> program should be restricted to performing constant-time operations on
> tainted values.  However, just avoiding branches is probably a good
> place to start.
>
> > It should be possible to add a pass to ANGLE to poison values read
> > from texture and those dependent on them and then validate that no
> > selections or loops depend on a poisoned value. I think that a program
> > that passed this test would then always execute in the same time for a
> > given set of vertices regardless of the contents of any bound texture.
> >
> > I believe CSS Shaders would still be useful with these limitations
> > added to GLSL -- what did I miss?
>
> I would encourage you to implement a prototype of this scheme to see
> whether you can still write useful shaders.  Some OpenGL experts I
> talked with earlier claimed that this approach would be too
> restrictive, but that's something that's easy to experiment with.
>
> Adam
>