Forgot your password?
typodupeerror
Google Programming Virtualization

Google x86 Native Browser Client Maybe Not So Crazy After All 332

Posted by CmdrTaco
from the because-you-can dept.
GMGruman writes "Google's experimental technology to run native x86 binaries in the browser shows lots of potential, writes Neil McAllister. He's previously said it was a crazy idea, but a new version of Native Client (NaCl) caused McAllister to take a fresh look, which has led him to conclude the technology is crazy like a fox. McAllister explains what NaCl is useful for, how to use it, and why it's not a Java or a Flash or a JavaScript replacement, but something else."
This discussion has been archived. No new comments can be posted.

Google x86 Native Browser Client Maybe Not So Crazy After All

Comments Filter:
  • by Anonymous Coward on Thursday February 24, 2011 @01:19PM (#35301694)

    Hopefully Google will make this more secure than ActiveX.

    If Android is any indication of Google's commitment to security, a free wallpaper application will be able to read all your text messages and track your location in real-time.

  • Light on details (Score:5, Informative)

    by pclminion (145572) on Thursday February 24, 2011 @01:25PM (#35301782)

    The article is light on details, but they do say that the executables are contained in .nexe files which are apparently NOT your run-of-the-mill PE format, so they can't just execute from a double click. And they do say that there's this annoying multi-second lag as the thing fires up. From this, I assume they are doing dynamic code instrumentation to implement whatever security measures they have in place.

    If done correctly, this can be secure. I've been working with Intel's Pin [pintool.org] library a lot lately, mostly for security-related projects. With these sorts of things you can intercept all memory accesses, function calls, system calls, instrument and analyze arbitrary instructions in arbitrary ways, etc. Again, if done correctly a dynamic instrumentation approach could make this idea viable. But you'd need a very skilled team to do it right.

  • by TheRealMindChild (743925) on Thursday February 24, 2011 @01:32PM (#35301874) Homepage Journal
    That is because ActiveX is just a DLL. Loading an ActiveX library is just loading a DLL. It isn't ActiveX that is the problem, but the fact that you are allowing any site to install and run a DLL. You don't even need to load your own anymore. Just have a handy exploit for Adobe Flash, load random flash object to make sure the browsing party has the DLL(s) installed and loaded, then exploit Flash. Same goes for Java. And that zynga "helper" you have from Facebook...
  • by coolmoose25 (1057210) on Thursday February 24, 2011 @01:33PM (#35301878)
    I use it all the time... I put it on french fries. I spread a lot of it on my driveway and sidewalk this year. The only real drawback is the high blood pressure that can result if you consume too much of it.
  • by Anonymous Coward on Thursday February 24, 2011 @01:43PM (#35302050)

    If you follow up on what this actually means in practice, the way these native modules are loaded is in a sandboxes process that disables all access to system calls (file read write, dll hooks, new process execution, etc). The modules interact through a "simple IPC" mechanism that is allegedly easy(er) to secure than arbitrarily complicated code.

    ActiveX had no such sand boxing restrictions. ActiveX was closer to browser plugins in that they have complete, pretty much unrestricted access to the system.

    Start here on the sandbox process:
              - http://www.chromium.org/developers/design-documents/sandbox
              - http://www.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ

    If this works as advertised (is actually safe), I would expect the general architecture to be adopted across any piece of software that speaks on the network (i.e. complex protocol parsers and validators in a sandbox).

  • by Animats (122034) on Thursday February 24, 2011 @01:48PM (#35302128) Homepage

    That's been around for a while. x86 machine code has to be written in a special way which prevents certain problems, such as buffer overflows into return addresses. Google has a modified GCC for this. Read the research paper [chromium.org]. It uses the rarely-used segmentation protection features of x86 CPUs to help provide an inner section of sandboxing. That's not enough, though; static analysis of the code, to check that all branches go to valid instructions, is necessary. This works much like the Java byte code verifier, the checker that runs as Java code loads. All returns and calls have to go through some extra code to insure that control goes where it is supposed to.

    The 64-bit extensions to the x86 instruction set don't have the segmentation machinery. The AMD designer of that mode once told me "nobody uses that". So this approach doesn't translate well to 64-bit code, and all code under this system runs in 32 bit mode.

    This comes with an API and an OS shim. Executable modules can make about a hundred system calls, which are portable across Windows and Linux. In the original version, you couldn't get at the graphics hardware, so it wasn't a suitable delivery mechanism for games. But now, Google has a connection to OpenGL in the thing. That makes it more useful. Games with full system performance could be delivered through this approach, while appearing to run within the browser. The performance is about 90 to 98% of unprotected code.

    It's very clever, and a good idea from a security standpoint. Untrusted processes communicating through narrow interfaces are always a good thing from a security perspective. The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.

  • Re:Like ActiveX? (Score:5, Informative)

    by drspliff (652992) <harry.roberts@NOSPAM.midnight-labs.org> on Thursday February 24, 2011 @01:50PM (#35302168)

    The Java sandbox was at the interpreter level and did not provide protection at the OS level. The google native client stuff sandboxes it at the OS level and only allows for communication via RPC calls to the parent app (e.g. drawing on a canvas), much like the seccomp [lwn.net] approach for Linux which is a true sandbox

  • by Enderandrew (866215) <enderandrew@noSPam.gmail.com> on Thursday February 24, 2011 @01:51PM (#35302190) Homepage Journal

    Chrome is extremely sandboxed. Scripts running in Chrome don't have permission to randomly alter files, install software, etc. like ActiveX did.

    I imagine they'll keep NaCl in a similar sandbox.

  • Re:Light on details (Score:4, Informative)

    by Trepidity (597) <.delirium-slashdot. .at. .hackish.org.> on Thursday February 24, 2011 @02:00PM (#35302346)

    Doing it optimally probably isn't possible, but you can statically transform code so it's guaranteed safe by doing somewhat pessimistic transformations, things like replacing every store instruction with a sequence of "safely store" instructions. As long as the analysis and transformations are at the assembly level and don't require recognizing higher-level patterns, obfuscated code isn't really an issue; the main issue is making sure you correctly analyze what safe and unsafe asm instructions are, and what transformations are guaranteed to result in safe code.

    There's a nice writeup here [chromium.org] of how they do the transformations on ARM.

  • by simula (1032230) on Thursday February 24, 2011 @02:10PM (#35302526) Homepage
    Native Client was designed to easily allow portability across all popular current platforms using cross-compilation. On a single development machine you can currently build executables for x86-32, x86-64, and arm. There is currently support for Windows, Linux, and OSX. Here is an article [chromium.org] on the generals.

    Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf [llvm.org] concerning that effort.

    You are also significantly underestimating the effort that they have put into this BSD licensed project [google.com].
  • Re:NaCl? (Score:5, Informative)

    by Tr3vin (1220548) on Thursday February 24, 2011 @02:18PM (#35302656)
    While I appreciate the funny mod, it wasn't meant as a joke. http://code.google.com/chrome/nativeclient/docs/reference/pepperc/index.html [google.com]
  • by Goaway (82658) on Thursday February 24, 2011 @03:04PM (#35303294) Homepage

    Chrome sandboxes its own native executable code, not just Javascript.

    Also, NaCl is even more strictly controlled than just a sandbox.

It is better to give than to lend, and it costs about the same.

Working...