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

Re: Summary of CSS shader security issues and proposals

From: Ralph Thomas <ralpht@gmail.com>
Date: Fri, 16 Dec 2011 19:59:36 -0800
Message-ID: <CAAYQYDRyJ50t+i_VGAPu70BuT6Z9_4=vUqh6T-FvS0dy0g=Kgg@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: "Gregg Tavares, (wrk)" <gman@google.com>, public-fx@w3.org, Vincent Hardy <vhardy@adobe.com>
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:00:05 GMT

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