Re: Documenting Timing Attacks in Rendering Engines

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