Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google nabs Square Enix and other game developers for native client Chrome games

venturebeat.com

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Google nabs Square Enix and other game developers for native client Chrome games

#41

Post by daeken »

pmjordan wrote: post #24
daeken wrote: post #5

Earlier quoted context omitted.

I'm not the least bit concerned about NaCl's involvement here, but I'm still deeply scared by the potential for things to go very badly in the lower levels (but not enough so that I'm willing to disregard the benefits of these APIs, mind you). What it comes down to is that current GPUs do whatever you want with no concern for security; that part depends on the driver and userspace 3d stack. This isn't necessarily bad…

Virtualisation's rise in popularity has caused IOMMUs to start showing up even in some consumer chipsets. Do you think an IOMMU and a driver that supplies it appropriately restrictive page tables for the GPU will be enough or do we realistically need GPUs with some kind of native memory protection support that can somehow be intertwined with the CPU's process model?

Yes and no. So, it really depends on what you're defending against: if your concern is solely about an attacker using the GPU to compromise the CPU, then IOMMUs get you a lot in terms of restricting what's possible -- sure, an attacker could find some buffer somewhere in the accessible address space that they can use to attack the CPU, but it's another barrier. But if you think about what's on the GPU itself -- all your UI elements (in many cases), your webpages, etc -- it suddenly makes that data seem very important; if I can get you to go to a page that will let me grab all of your running windows, then suddenly I may very well have things like your passwords, credit card info, etc (all depending on when I grab the data and how often that data gets flushed out).

I think that proper protections should be put in from the hardware on up through the drivers, but it's going to take a lot of work and a lot of research to get it right.

Re: Google nabs Square Enix and other game developers for native client Chrome games

#42

Post by daeken »

nkassis wrote: post #22
daeken wrote: post #5

Earlier quoted context omitted.

I'm not the least bit concerned about NaCl's involvement here, but I'm still deeply scared by the potential for things to go very badly in the lower levels (but not enough so that I'm willing to disregard the benefits of these APIs, mind you). What it comes down to is that current GPUs do whatever you want with no concern for security; that part depends on the driver and userspace 3d stack. This isn't necessarily bad…

It's a concerned but it's something GPU vendors are claiming they are working on. There has been moves to improve driver security through the ARB_robustness extension and for the browser vendors there is the ANGLE's project as you have said but also plain blacklisting dangerous cards or drivers. The reality is that web 3D's time seems to have arrived. It doesn't matter if it's through WebGL, Flash, Unity the issue yo…

> There has been moves to improve driver security through the ARB_robustness extension

IMO, GL_ARB_robustness is almost completely worthless. The one thing it gives you is the ability to time out rendering, in effect, which of course prevents certain types of DoS attacks. There are many other provisions in the extension, but those are already universally implemented in ANGLE and the like; they don't do anything to help with the security of the lower level.

> The reality is that web 3D's time seems to have arrived. It doesn't matter if it's through WebGL, Flash, Unity the issue you raised is present in all those solutions. Even Native client has that potential if the sandbox is not watertight.

NaCl has the same issues regardless of the sandbox, but I agree entirely: hardware accelerated 3d on the web is worth the risk we'll be dealing with for the first couple of years. I've stopped writing desktop 3d software/demos entirely in favor of WebGL simply because I believe so much in it, but it's not stopping me from doing security research into it as well.

At the end of the day, I'm convinced that a reasonably skilled attacker could do terrible, terrible things to my system via WebGL. But the benefits outweigh the risks for me.

Re: Google nabs Square Enix and other game developers for native client Chrome games

#43

Post by DonnyV »

VikingCoder wrote: post #39
kevingadd wrote: post #17

Earlier quoted context omitted.

Replying to provide follow-up detail: I dug into the executables and it looks like it uses OpenTK for rendering and FMod to sound, instead of using a port of XNA. Both are freely available, so that's a pretty simple path to doing a similar port for other XNA games. Neat.

Wow, wow, wow. So, can someone write a tutorial about how to develop a C# OpenTK + FMod application, and get it running on Mono, in Native Client? That would be awesome to see.

I have been looking everywhere and can't find one. Please post if someone finds one.

Re: Google nabs Square Enix and other game developers for native client Chrome games

#44

Post by bradchen »

daeken wrote: post #7
natfriedman wrote: post #6

Earlier quoted context omitted.

Bastion runs on Mono, and Mono runs on native client (including the JIT, which required some special work in native client itself). Actually all three apps they demo'd running on native client were also running on Mono!

Oh wow, nice. The original version of NaCl didn't allow any runtime codegen -- when did that change?

Have a look at our 2011 PLDI paper. You can find a link here: http://www.chromium.org/nativeclient/reference/research-pape...

Re: Google nabs Square Enix and other game developers for native client Chrome games

#45

Post by azakai »

radarsat1 wrote: post #30
zobzu wrote: post #9

There you go: Google's embrace, extend, extinguish. Just like MS, but with better cover. "Its open!" Of course, no one else will implement.

There's a BIG difference between "no one else will implement" and "no one else CAN implement."

> There's a BIG difference between "no one else will implement" and "no one else CAN implement."

That's true, but is it the right question?

Browsers could also have implemented ActiveX, back in the day. There was nothing stopping them - except that it would have been very bad for the web and for non-Microsoft OSes. Thankfully, other browsers did not implement ActiveX or else it would have still been used today.

The real issue is that no one but Google thinks NaCl is good for the web. In that sense it is similar to Microsoft with ActiveX. Of course, there are big differences too - NaCl is open source, so it would be easier to implement, if another browser changed its mind. Still, that is just a matter of technical convenience - if NaCl were closed source, the other browser vendors could still reimplement it. But again, the issue is that only Google thinks it is worth implementing in a web browser.

Kudos to Google for making it open source, but open standards are just as important for the open web.

Re: Google nabs Square Enix and other game developers for native client Chrome games

#46

Post by radarsat1 »

azakai wrote: post #45
radarsat1 wrote: post #30

Earlier quoted context omitted.

There's a BIG difference between "no one else will implement" and "no one else CAN implement."

> There's a BIG difference between "no one else will implement" and "no one else CAN implement." That's true, but is it the right question? Browsers could also have implemented ActiveX, back in the day. There was nothing stopping them - except that it would have been very bad for the web and for non-Microsoft OSes. Thankfully, other browsers did not implement ActiveX or else it would have still been used today. The r…

> The real issue is that no one but Google thinks NaCl is good for the web.

Are you sure about that? I like NaCl. I don't know about depending on x86 instructions, but I like the idea of NaCl. I think it's pretty clear that the web needs some kind of low-level VM that's closer to the metal than JavaScript. It's been argued that LLVM isn't the answer, so maybe PNaCl is on the way out, but overall I think NaCl makes sense in Google's strategy: they want to see web apps take over. They want the web to replace Windows and OS X. Therefore it's natural that they want to download native or near-native code to the browser, and NaCl is just a way to do it safely. It's _not_ the same thing as ActiveX, I really believe that. However, it's clear that it's necessary to be extremely careful, and I'm not convinced they need to go 100% native -- I think a solution like PNaCl is more along the right lines. Web apps and games are not going away, and I think it's clear that we need something easier to statically optimize than JavaScript as the runtime system for the web.

Re: Google nabs Square Enix and other game developers for native client Chrome games

#47

Post by azakai »

radarsat1 wrote: post #46
azakai wrote: post #45

Earlier quoted context omitted.

> There's a BIG difference between "no one else will implement" and "no one else CAN implement." That's true, but is it the right question? Browsers could also have implemented ActiveX, back in the day. There was nothing stopping them - except that it would have been very bad for the web and for non-Microsoft OSes. Thankfully, other browsers did not implement ActiveX or else it would have still been used today. The r…

> The real issue is that no one but Google thinks NaCl is good for the web. Are you sure about that? I like NaCl. I don't know about depending on x86 instructions, but I like the idea of NaCl. I think it's pretty clear that the web needs some kind of low-level VM that's closer to the metal than JavaScript. It's been argued that LLVM isn't the answer, so maybe PNaCl is on the way out, but overall I think NaCl makes se…

> Are you sure about that? I like NaCl.

Sorry if I wasn't clear before, when I said "no one but Google thinks NaCl is good for the web", I was talking in the context of browser makers. I meant the fact that Google is the only browser maker that thinks NaCl is good for the web.

> Web apps and games are not going away, and I think it's clear that we need something easier to statically optimize than JavaScript as the runtime system for the web.

We can do that in a portable, standards-based way without a complete break like NaCl with its downsides.

Consider what the PyPy compiler does to RPython: It compiles RPython, a subset of Python, down to C, by statically discovering all the types and so forth. The same can be done for JavaScript, since the performance-sensitive code people are writing is almost always statically-typed (but implicitly, without writing types) anyhow, just like RPython.

In fact we are already moving towards that now, with technologies like the global type analysis in SpiderMonkey TI. With a few more years of work, that approach should make performance-sensitive JavaScript as fast as we need it to be. There is no technical impossibility here, it just takes time - we are half-way there, with things like RPython showing this is definitely feasible.

Post reply on HN