[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Microsoft Weighs in on WebGL Security Issue





On Fri, Jun 24, 2011 at 2:48 PM, Chris Marrin <cmarrin@apple.com> wrote:


On Jun 23, 2011, at 3:00 PM, Gregg Tavares (wrk) wrote:

>
>
> On Thu, Jun 23, 2011 at 7:17 AM, Chris Marrin <cmarrin@apple.com> wrote:
>
>
> On Jun 21, 2011, at 2:33 PM, Patrick Baggett wrote:
>
> > They claim to have fixed it in Silverlight 5 RTM. So retest when it comes out and if it isn't fixed (which it probably won't be) then reopen/refile. Hold them accountable for what they claim to have done, which is prevent DoS attacks using the GPU despite GPU/drivers not having explicit support for this. If they have, then they are a step ahead of the competing technologies and should be praised. If they haven't, then they are quite clearly lying (considering they have a test case that reproduces the problem 100% of the time).
>
> It's very possible to avoid DoS attacks with proper handling of GPU reset. This requires support in the graphics driver and I'm sure some do a better job than others. So it's important to test on a variety of drivers. But the bigger issue for Apple is the handling of "innocent victims". What happens to other apps using the driver when the guilty app causes a DoS? DirectX supposedly has a way to inform the innocent apps so they can clean themselves up properly.
>
> So the more interesting test, IMHO, is to have a windowed Direct3D based game or two running in another window. Get them to an interesting state (running in the middle of a level) and then generate the DoS in Silverlight running in a browser. What happens to the games? Are they unaffected? Do they reset to the start of the level? Do they crash? Any of these would be an indication to me that the bug is surely not fixed. Furthermore, it's a bug that can't be fixed in Silverlight. It has to be fixed in the game or the driver. If one game is found with a problem then you could say this is simply a bug in the game. But if it happens in many, then it's really a system problem.
>
> I can try this but at least through DirectX9, Windows GPU apps always had to deal with lost context.  The structure for all sample apps in the SDK made this very clear. Their sample framework provided several callbacks you filled out with your own code 2 of which were releasing your resources when you lose the context and creating your resources then you get it.

That's true. But in the past, this was typically as the result of closing the lid wasn't it? I wonder if a gamer (or any other DX app user) expects the apps to return to the exactly right spot after waking their laptop up. If I were playing a game, I think I'd save before putting my system to sleep. Seems like a more serious scenario to be surfing the web while waiting for your crops to grow and then return to the game to find you've been kicked and the last hour of crop growth is gone. Maybe that never happens, but it sure annoy me if it ever did.

Actually, the most common reason I've noticed for a lost device event is the screensaver kicking in.