W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2011

Re: Summary of CSS shader security issues and proposals

From: Adam Barth <w3c@adambarth.com>
Date: Fri, 16 Dec 2011 20:15:54 -0800
Message-ID: <CAJE5ia9av_h=6gzq7HcUourOV1QSmgVfk5w5bjXPCO=5aDvVXA@mail.gmail.com>
To: Ralph Thomas <ralpht@gmail.com>
Cc: "Gregg Tavares, (wrk)" <gman@google.com>, public-fx@w3.org, Vincent Hardy <vhardy@adobe.com>
I'm sorry, I'm not sure I understand your question.  Are you asking
how you can mount cache timing attacks on GPU cache lines?

Adam


On Fri, Dec 16, 2011 at 7:59 PM, Ralph Thomas <ralpht@gmail.com> wrote:
> Why could you not use WebGL timings (drawing something else) to see if the
> page composed near MSET or much quicker than MSET?
>
> Also depending on the GPU driver and/or whatever else is going on on the
> machine it could be hard to accurately measure the MSET. Most GLES2 drivers
> don't provide sync fences, for example.
>
> Ralph
>
> On Dec 16, 2011 7:28 PM, "Adam Barth" <w3c@adambarth.com> wrote:
>>
>> 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 04:16:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 17 December 2011 04:16:58 GMT