Re: Summary of CSS shader security issues and proposals

On Fri, Dec 16, 2011 at 6:18 PM, Gregg Tavares (wrk) <gman@google.com> wrote:
> I don't see how your Method A is supposed to work.
>
> 1) how do you do effective timing? Any change to any parameters can
> massively influence timing. Set the Z to something far way it gets rendered
> 2x2 pixels, then set it close so it's 1000x1000 pixels.  Even if you could
> some how keep a timing for every set of inputs it's unclear how the thing
> would get any descent perf. Every time you go to page expect lots and lots
> of hiccups as timing is done for every set of inputs on every element using
> CSS shaders.
>
> 2) You can't allow variation in timing. In your Method A you give 120%
> leeway. All the attacker needs is ANY difference in timing. How does giving
> them 100% to 120% fix this problem? I'll just make my shader take 100% and
> 101% for some other and find the difference.

Method A is not an upper bound.  It's an exact bound.  Shorter
executions are padded to that value and longer executions are
truncated.

There's a potential issue with Method A and caches on the GPU.  If a
shader can heat up different cache lines depending on sensitive
information, it's likely that other GPU operations (e.g., by WebGL)
can detect which cache lines are hot and extract the information.

Adam


> The first paragraph to Method B seems unrelated to anything that's been
> discussed. It's certainly not related to the 2nd paragraph.
>
>
> On Fri, Dec 16, 2011 at 5:29 PM, Ralph Thomas <ralpht@gmail.com> wrote:
>>
>> Hi Vincent,
>>
>>  Could it be possible to use WebGL (timing rendering continuously to
>> texture) to observe page composition times in Method A in spite of
>> rounding rAF up to MSET?
>>
>> Ralph
>>
>>
>> On Fri, Dec 16, 2011 at 5:05 PM, Vincent Hardy <vhardy@adobe.com> wrote:
>> > Hello,
>> >
>> > We have put a summary of the CSS shaders security issues at:
>> >
>> > http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security
>> >
>> > I hope this captures the problem properly and that the proposed methods
>> > will
>> > provide a way forward on the issues. If issues are not summarized
>> > properly
>> > or fail to represent a particular point of view, please comment so that
>> > we
>> > can improve this summary and/or proposal.
>> >
>> > Feedback from other implementors and GPU experts on "Method A" would be
>> > very
>> > helpful.
>> >
>> > Thanks to all who have commented on the issue and in particular to Adam
>> > Barth for working with Dean and I to put together this summary and
>> > proposal
>> > together.
>> >
>> > Kind regards,
>> > Vincent Hardy
>> >
>> > P.S: I will be out of the office for the next two weeks and will have a
>> > limited or no ability to respond to email during that period.
>> >
>>
>

Received on Saturday, 17 December 2011 03:29:09 UTC