Re: Documenting Timing Attacks in Rendering Engines

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.

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?

Ralph

On Mon, Dec 12, 2011 at 5:47 PM, James Robinson <jamesr@google.com> wrote:
>
>
> On Mon, Dec 12, 2011 at 2:56 PM, Chris Marrin <cmarrin@apple.com> wrote:
>>
>>
>> On Dec 12, 2011, at 1:06 PM, Gregg Tavares (wrk) wrote:
>>
>>
>> In this particular case I think the problem boils down to
>> requestAnimationFrame. It's only going to give you frames as fast as it
>> takes to render and one way or another you can use that to get your timing.
>> (I don't think setInterval/setTimeout would be any different). At some point
>> the JavaScript or HTML renderer will be throttled waiting for this other
>> process to do work. You just need to figure out how much work to give it to
>> find that throttling point and then use that to adjust how long rendering
>> takes.
>>
>>
>> rAF need not know anything about the rendering process. As far as the
>> author knows the system is running at 60fps no matter how complex the page.
>> In fact nothing that the author can see needs to know about it. As far as
>> the author is concerned he is rendering to a display list at 60hz (or
>> whatever the display rate is), and as long as creating that list doesn't
>> give back any timing information (which it shouldn't), there should be no
>> way to know how long a given rendering operation will actually take.
>
>
> In addition to the issues Adam has talked about, it also sounds like you are
> describing a very poor quality implementation of requestAnimationFrame.  rAF
> needs to scale with the time that the scene takes to render so that the
> author's script does not do unnecessary work.  If, for example, the page can
> only render at 15Hz on a given piece of hardware then the rAF callbacks
> should only fire 15 times a second, or the author will be doing a
> potentially large amount of work in script that will only be thrown away.
>  This is one of the key advantages of rAF over setTimeout-based scheduling
> which has no insight into the rest of the rendering pipeline which, as you
> point out,  may be deeply pipelined.  Good backpressure mechanisms are
> essential to building high-quality animated and interactive experiences.
>
> - James
>
>>
>> Maybe you're concerned that the web thread would sometimes need to block
>> on the rendering thread. By definition that would never be allowed. The
>> final rendered image would be "output only". This of course would not be
>> possible if you needed to read back the image, as you're able to do with
>> canvas. But obviously any such read back would be disallowed when the canvas
>> (or any other object whose image is processed by content code) contains
>> pixels from the rendered page.
>>
>> -----
>> ~Chris
>> cmarrin@apple.com
>>
>>
>>
>>
>

Received on Tuesday, 13 December 2011 06:04:07 UTC