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

I think you could still branch on anything that wasn't derived from a
texture sample of HTML content -- branching on uniforms/fragment
position/other GL state wouldn't change runtime based on texture
contents. If you remove VTF then you only have the limitations in the
fragment shader. Out of curiosity, how would a dependent texture
lookup change runtime based on contents? Is it faster to sample edge
texels when using GL_LINEAR or something like that?

Internally pow has a conditional branch on a value derived from the
second argument, which in your example would be tainted, so that
should generate an error -- but a good point that the internal
functions would need to be considered too.

And yes, this doesn't address any DOS concerns. You'd need something
else to cancel a frame if it's taking too long to rasterize.

Ralph

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

Received on Thursday, 15 December 2011 04:56:04 UTC