The latest news and insights from Google on security and safety on the Internet
December 8, 2008
Native Client: A Technology for Running Native Code on the Web
Most native applications can access everything on your computer – including your files. This access means that you have to make decisions about which apps you trust enough to install, because a malicious or buggy application might harm your machine. Here at Google we believe you shouldn't have to choose between powerful applications and security. That's why we're working on Native Client, a technology that seeks to give Web developers the opportunity to make safer and more dynamic applications that can run on any OS and any browser. Today, we're sharing our technology with the research and security communities for their feedback to help make this technology more useful and more secure.
Our approach is built around a software containment system called the inner-sandbox that is designed to prevent unintended interactions between a native code module and the host system. The inner-sandbox uses static analysis to detect security defects in untrusted x86 code. Previously, such analysis has been challenging due to such practices as self-modifying code and overlapping instructions. In our work, we disallow such practices through a set of alignment and structural rules that, when observed, enable the native code module to be disassembled reliably and all reachable instructions to be identified during disassembly. With reliable disassembly as a tool, it's then feasible for the validator to determine whether the executable includes unsafe x86 instructions. For example, the validator can determine whether the executable includes instructions that directly invoke the operating system that could read or write files or subvert the containment system itself.
To learn more and help test Native Client, check out our post on the Google Code blog as well as our developer site. Our developer site includes our research paper and of course the source for the project under the BSD license.
We look forward to hearing what you think!
Panayiotis
5 comments:
You are welcome to contribute comments, but they should be relevant to the conversation. We reserve the right to remove off-topic remarks in the interest of keeping the conversation focused and engaging. Shameless self-promotion is well, shameless, and will get canned.
Note: Only a member of this blog may post a comment.
Why don't you just use JPC? JPC was able to run native unmodified x86 code in Java 2 years ago. It also has the much stronger double security of the JVM and being an emulator.
ReplyDeletehttp://www-jpc.physics.ox.ac.uk
Ian, i don't think that an emulator running in a VM (Even with JIT support) could come close to native execution (With the few alignment and instructions limits here) for any processor intensive application.
ReplyDeleteJPC claim 20% of native speed, Native Client claim 95% of native speed... When speaking about anything doing with Raytracing, FFTs, image processing or video processing it's a _really_ big gap.
And for any other use, if 20% of native speed is ok, why bother with anything else than javascript ? Especially with SpiderMonkey and V8 becoming common place in the future.
Anyway good work google.
I assume you are too young to remember Active/X and all the problems it created.
ReplyDeleteI'd rather see GWT support built into the browser providing smaller downloads and faster execution.
James, I assume you didn't read the paper. If you had, you would know they use a totally different security model, and don't assume NaCl authors are trustworthy (there isn't even a digital signature to fake).
ReplyDeleteGood post
ReplyDelete