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

Would it be possible to revert to the older shading language which wasn't
as rich but still allowed simple conditionals?
It would be great if you could just tell the graphics driver to compile
according to an earlier specification.

Rik

On Wed, Dec 14, 2011 at 1:07 AM, Gregg Tavares (wrk) <gman@google.com>wrote:

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