Google x86 Native Browser Client Maybe Not So Crazy After All 332
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."
Not Java, more like Active X (Score:3, Informative)
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)
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.
Re:ActiveX revisited? (Score:5, Informative)
NaCl is very useful... (Score:4, Informative)
Re:ActiveX revisited? (Score:4, Informative)
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).
Like Java, without the JVM (Score:5, Informative)
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)
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
Re:Not Java, more like Active X (Score:5, Informative)
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)
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.
Crazy smart ISA portability (Score:4, Informative)
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)
Re:Not Java, more like Active X (Score:4, Informative)
Chrome sandboxes its own native executable code, not just Javascript.
Also, NaCl is even more strictly controlled than just a sandbox.