Google Native Client Puts x86 On the Web

t3rmin4t0r writes "Google has announced its Google native client, which enables x86 native code to be run securely inside a browser. With Java applets already dead and buried, this could mean the end of the new war between browsers and the various JavaScript engines (V8, Squirrelfish, Tracemonkey). The only question remains whether it can be secured (ala ActiveX) and whether the advantages carry over onto non-x86 platforms. The package is available for download from its Google code site. Hopefully, I can finally write my web apps in asm." Note: the Google code page description points out that this is not ready for production use: "We've released this project at an early, research stage to get feedback from the security and broader open-source communities." Reader eldavojohn links to a technical paper linked from that Google code page [PDF] titled "Native Client: A Sandbox for Portable, Untrusted x86 Native Code," and suggests this in-browser Quake demo, which requires the Native Code plug-in.

Comments

doesn't sound too secure yet

[alain94040]

This is not a good thing: by definition x86 code is not portable across platforms.

Secure or not, it goes against the main founding principle of the web, which is portability. There are other ways to solve the performance issue, I thought just-in-time compilers were getting pretty close anyway (50% according to http://www.mobydisk.com/softdev/techinfo/speedtest/index.html).

On the security side, I'll just quote Google's description: "modules may not contain certain instruction sequences". That doesn't sound like a robust way to detect malicious code.

http://fairsoftware.net/ where software developers share revenue from the apps they create together

Re:doesn't sound too secure yet

[larry bagina]

Those that don't understand java are doomed to repeat it.

Re:doesn't sound too secure yet

[Xargle]

x86 code runs natively on 90% of the processors out there. Java or .NET bytecode runs natively on about 0% of them (Sun did have a Java chip once but it is long dead). So it is hardly any worse than the alternatives. There are many x86 emulators and some of them have reasonable performance.

ARM Jazelle (in quite a number of the ARM revisions deployed all over the place) includes DBX for direct bytecode execution of Java. That includes the iphone and loads of other stuff.

Re:doesn't sound too secure yet

[should_be_linear]

I also noticed that Google is very aggressively trying *not* to use Java JRE anywhere, as Dalvik VM or this x86 nonsense demonstrate. I have no idea why is that, given Java and JRE are FOSS now. One thing is for sure: Their Google Docs and other office-like applications would only start to make much more sense if they use new JavaFX clients (that can be dragged from browser to desktop, becoming standalone app) alongside with improving JRE support in Chrome and Firefox.

Re:doesn't sound too secure yet

[DamageLabs]

An interpreter compiles each instruction every time it gets executed.
JIT compiles blocks of code only on first execution. Next time, the compiled code is already in memory.

Re:doesn't sound too secure yet

[prockcore]

Knock Knock.
Who's there?
.
.
.
(long pause)
.
.
.
Java.

Re:doesn't sound too secure yet

[IamTheRealMike]

Holy crap. AKAImBatman I usually enjoy your posts, but it's painfully clear nobody on this thread - including you - has actually read the paper.

If you had, you'd see that this system is secure. It's simple yet clever at the same time. By using a combination of x86 segmentation (which ironically you say is never used anymore!), alignment rules, static analysis and - crucially - masked jumps, it's possible to ensure that native code cannot synthesize unverified code in memory and then jump into it. If you can prevent arbitrary code synthesis, you can control what the program does. It's as simple as that.

Even though the verifier for this system is microscopic (compared to, say, a JVM), and so much more likely to be correct, NativeClient also includes a ptrace sandbox to provide an additional redundant level of protection.

One must be VERY careful with native code because there is no way to prove that it is safe to execute natively.

I don't blame you, because until I read the paper I also believed this. Once you read it you'll slap your forehead and say, my god, it's so simple. Why didn't I think of that?

Did they really just...

[geminidomino]

The only question remains whether it can be secured (ala ActiveX)

HAHAHAHAHAHAHAHAHAHAHAHAHAHA *gasp* HAHAHAHAHAHAHAHAHAHAHAHHAAHHAHA *wipes eyes*
HAHAHAHAHAHAAHHAAHAHAHAHAHAHAH

Re:Two steps backward

[MikeBabcock]

The only problem you seem to have with Java plugins is the load time -- this is only resolved by Javascript because JS is pre-loaded by the browser at all times (in modern browsers at least).

If other plugins were to be marked as 'frequently used' by the plugin engine and loaded at runtime instead of page load-time, they'd obviously be just as responsive as Javascript (or more so, since Java is compiled to native code in many cases).

Making a browser that integrates Java in a reasonable way and makes it work just as seamlessly as Javascript was tried already (by Netscape) but it was before we had computers with enough RAM to handle it IMHO.

GREAT IDEA

[scsizor]

BIG thanks from Russia. i hope it catches on!

A remarkably bad idea.

[John Hasler]

It will go far.

What a stupid idea

[Sloppy]

Seriously, this is even worse than saving Hitler's brain by putting into the body of a great white shark armed with lasers.

With Java applets already dead and buried

If you want crap like this, you would be a lot better off, by just exhuming Java applets.

I really hope this project dies a quiet death.

This is rather clever

[Animats]

This is a fascinating effort. Read the research paper.

This is really a little operating system, with 44 system calls. Those system calls are the same on Linux, MacOS (IA-32 version) and Windows. That could make this very useful - the same executable can run on all major platforms.

Note that you can't use existing executables. Code has to be recompiled for this environment. Among other things, the "ret" instruction has to be replaced with a different, safer sequence. Also, there's no access to the GPU, so games in the browser will be very limited. As a demo, they ported Quake, but the rendering is entirely on the main CPU. If they wanted to support graphics cross-platform, they could put in OpenGL support.

Executable code is pre-scanned by the loader, sort of like VMware. Unlike VMware, the hard cases are simply disallowed, rather than being interpreted. Most of the things that are disallowed you wouldn't want to do anyway except in an exploit.

This sandbox system makes heavy use of some protection machinery in IA-32 that's unused by existing operating systems. IA-32 has some elaborate segmentation hardware which allows constraining access at a fine-grained level. I once looked into using that hardware for an interprocess communication system with mutual mistrust, trying to figure out a way to lower the cost of secure IPC. There's a seldom-used "call gate" in IA-32 mechanism that almost, but not quite, does the right thing in doing segment switches at a call across a protection boundary. The Google people got cross-boundary calls to work with a "trampoline code" system that works more like a system call, transferring from untrusted to trusted code. This is more like classic "rings of protection" from Multics.

Note that this won't work for 64-bit code. When AMD came up with their extension to IA-32 to 64 bits, they decided to leave out all the classic x86 segmentation machinery because nobody was using it. (I got that info from the architecture designer when he spoke at Stanford.) 64-bit mode is flat address space only.