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

On Thu, Dec 15, 2011 at 9:33 AM, Rik Cabanier <cabanier@gmail.com> wrote:

> Would it be possible to revert to the older shading language which wasn't
> as rich but still allowed simple conditionals?


Someone pointed out it's probably only conditionals that are based on the
contents of a texture lookup so it's possible all those features could
stay. The GLSL validator would just have to check that no value derived
from a texture used any conditionals or functions that don't complete in
constant time.



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