- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 16 Dec 2011 20:15:54 -0800
- 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 UTC