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

[Anonymous Coward]

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.

Why not? It just means that the permissible instruction sequences are limited to a subset that can be statically analyzed and verified to be safe. The Java VM has similar verification algorithms that are run whenever untrusted code is first loaded.

It's true that this does not allow all x86 code to run; it's at least practically (and probably theoretically) impossible to correctly determine whether or not a piece of code is safe, but as long as the VM errs on the side of caution, there shouldn't be any problems with this approach.

I will grant that this makes it unclear what the advantage is over (say) Java applets. What can this technology do that the Java VM couldn't? As far as I'm concerned, the failure of Java in the browser has more to do with the lack of a standard library for high-performance multimedia applications (think: Flash) than with shortcomings in the bytecode language.

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

[AKAImBatman]

Why not? It just means that the permissible instruction sequences are limited to a subset that can be statically analyzed and verified to be safe. The Java VM has similar verification algorithms that are run whenever untrusted code is first loaded.

One of the key differences is that Java code and data are separated to the point of paranoia. I cannot load a classfile as data and pass through execution to the native system. With the x86 instruction set, I can load a data file and execute a jump to a data segment without the code having passed through any sort of system loader. A VM would have to take this into account. Not to mention common issues of stack smashing, heap overflows, and other common memory tricks to execute unwanted code.

When you're managing native code, it only takes one slip-up to hand over the keys to the kingdom. That slip-up may be as simple as a two byte exploit, but it's a slip-up none the less. One must be VERY careful with native code because there is no way to prove that it is safe to execute natively.

Hypervisor features in modern processors simplify the issue somewhat, but it is still not proven that hypervisors are without exploits. Not to mention the overhead of running dozens of simultaneous hypervisor environments.

Java and Javascript have it right. Java bytecode is provably correct because it targets an ideal machine. Thus the code can be translated into well-behaved native code with the linkage between data and code managed during or after translation. Javascript is just as good because it provides an abstract execution environment that must rely on exposed APIs to accomplish any interaction with the system. It is provable not possible (shy of an underlying flaw in the browser) for Javascript to break through its execution engine into a native runtime.

The two platforms may be paranoid, but when you're dealing with security on the scale of the World Wide Web, "better safe than sorry" is a good motto.

Re:doesn't sound too secure yet

[Chyeld]

Isn't Java run in an emulated fashion on all platforms? Isn't that part of the 'slow' image that it cultivated in it's early years, that it was too slow due to the emulation of the java 'virtual machine'?

Is the problem here that this could mean some machines won't be as slow as others or just that its x86?

What exactly is the difference, outside of one having a much larger code base to 'exploit' and the potential for a huge speedup on machines that can natively handle x86 code?

Re:doesn't sound too secure yet

[LordKazan]

that and applets are slow as shit. The National Weather Service still uses a java applet for their single-radar radar loops (uses animated gifs for larger views).. takes forever to load because the JVM is initializing, whereas the animated gif takes exactly as long as it takes to download.

Java failed in the browser.. because java is slow.

Re:doesn't sound too secure yet

[H0p313ss]

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

Given that Java started as a poor re-implementation of other VM based OO languages that just makes me want to weep.

Re:doesn't sound too secure yet

[online-shopper]

x86 does not run natively on 90% of the processors out there. ARM beats it by a bit.

Re:doesn't sound too secure yet

[poot_rootbeer]

x86 code runs natively on 90% of the processors out there.

Among desktop PCs, maybe. But have you heard that they've started putting the web on devices such as cellular phones and set-top boxes? You're not going to find a lot of x86 CPUs in those.

Of course, the way to do it is to define what instruction sequences are safe and allow only those. I assume that's what they are doing and 'modules may not contain certain instruction sequences' is just the one-line summary.

Doesn't change the fact that there's no practical and all-encompassing way of whitelisting "safe x86 code" nor blacklisting "dangerous x86 code".

Re:doesn't sound too secure yet

[Free the Cowards]

Seeing how JIT-compilation means that the code is compiled to native code just before being executed, this is clearly rubbish. JIT-compilation results in native code, just like any other compilation; the program is simply stored in some intermediate form (bytecode) rather than in the final compiled form.

...

Yes, this is true. Emulation is horrible for performance. This whole idea is ludicrous.

You contradict yourself here. JIT is one way to perform emulation. Either JIT isn't as fast as native code or emulation isn't horrible for performance, you can't have it both ways!

Re:doesn't sound too secure yet

[cmacb]

Thanks for your comment and the links. Every time I run across an article like this and sigh, wishing I had the technical cojones to explain why it is that we were doing things like this on mainframes in the 80s with complete safety... and continuing to wonder why Intel couldn't just COPY the damned concepts if they can't figure out how to implement them from scratch.

Our world continues to be saddled with a half assed operating system running on a third rate architecture and for no other reason that technology takes a back seat (or maybe it's more like back of the bus) to marketing, bribery and collusion (with an unhealthy dose of buyer ignorance thrown in for good measure).

I continue to hope that good technology will win out eventually, although I'm almost convinced at this point that it will have to come from some country that hasn't been bought out by the Borg.

I wonder though, and maybe you know, why isn't the Power-PC mentioned in the Wikepedia article. I would assume because of its origin that it is closer to the 370 than to the Intel architecture in being fully virtualizable, a concept apparently not on the "roadmap" that Steve Jobs kept referring to in his rationale for Apple's switch to Intel. The Power-PC represented our best hope of escaping the Intel monoculture and I'd like nothing better than to once again have a mainstream non-Intel (and non-Intel-like) choice when I pick my next laptop.

Of course if Intel had a deserved (I'm being generous) third of the market then what Google is doing with this initiative would be dead in the water (as it probably should be).

Re:doesn't sound too secure yet

[Lokitoth]

Thanks to Microsoft's known influence to corrupt all the standard bodies the "(applet)" tag is now depreciated. ITs been depreciated since html 3 last century.

Realize that the <object> tag is vastly superior to the <applet> tag in that it can be used for other things, like Adobe's Flash and Microsoft's Silverlight, as well as new technologies yet to be developed. It is that Java was very slow (pre-JIT), loaded very slowly (pre-"New Bytecode Verifier") and was a pain to do anything good looking or active in - see Flash and Silverlight - added to the fact that Javascript was easier and faster to write and gave developers a platform nearly as robust that killed applets. The tag has nothing to do with it.

Two steps backward

[AKAImBatman]

Google has announced its Google native client, which enables x86 native code to be run securely inside a browser.

Because all that we need is to further promote an archaic instruction set that won't die because of all the pre-existing code compiled for it. An instruction set that was finally starting to loosen its grip as the industry worked toward more abstract solutions.

With Java applets already dead and buried

And with good reason!!! Plugin engines do not provide a very smooth browsing experience. You must wait for them to download and activate before you can start using the widget. Meanwhile, Javascript is designed for execution as the page is loading.

The heavyweight JVM was probably the worst offender, but look at Flash for another example of an engine that most developers would rather eliminate. While it was hip to create entire websites out of Flash for a while, the platform was very user-unfriendly and almost died out. Thanks to infighting over video standards however, Flash was able to hold on as a video delivery platform and even gained a margin of success as a web-gaming platform. (About the only area where Java Applets really shined back when they were popular.)

My personal opinion* is that this is a step in the wrong direction. Javascript engines are getting good. Damn good. I'd like to see more R&D poured into these engines and the underlying technologies rather than reinventing ActiveX and Java. If researchers wanted to invent a more efficient or usable browser language other than JS, I'd be all for it. But I don't run a browser to become a part of a compute farm. I run a browser to access web information and applications. Very little of which is compute-intensive enough to require a new execution engine over a more advanced set of APIs.

* ...and 50 cents won't buy you a cup of coffee anymore, so take it for what it's worth.

** As an aside, C/C++ is an incredibly complex build environment. Why anyone would want to continue subjecting developers to the angst of compiler differences, makefiles, configure scripts, and other irritants is beyond me. As is typical with such platforms, I can't even get the examples running on my machine. The run.py script dies with an "Invalid Argument" on line 42 and the nacl-gcc compiler fails with syntax errors a-plenty. I'm sure I'll figure it out eventually, but WHY oh why do we want to promote such a complicated method of compiling code?

Re:Two steps backward

[AKAImBatman]

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).

The Java runtime was compiled into early browsers like Netscape. So the load time is not caused by the plugin itself. (Though that does play a role in the first activation.) The load time is the time it takes to download the complete application, dearchive the components, load the components into an interpreter or JIT, initialize the environment and/or APIs used, and finally present the application to the user.

Javascript fits in better with the way web browsers are designed in that the browser executes each individual module during the page load. The makes page loading more asynchronous and thus a better experience for the web user. The web developer can still throw up a "loading" progress bar for applications must preload, but they are the exception rather than the rule.

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.

There is more to the issue than meets the eye. Besides the synchronous aspect I mentioned, the client Java runtime has also grown to meet the expansion in system memory and complexity. Which is a good thing from the perspective of writing rich applications for deployment on the server or desktop. It's a bad thing when we're talking about the time-sensitive environment of the web browser. If you want an ideal JVM for the browser, Sun is going to have to strip it down again and make the platform a better fit than it has been in the past. (A version that relies heavily on the DOM for APIs would be preferable.)

They're also going to have to work out a good method of solving the load problem. Even Flash allows for partial execution prior to the load being complete. (This is how most Flash games show a LOADING screen.) Java was not designed with this in mind and the platform shows it. There are ways a developer could work around it using dynamic class loading, but this requires a great deal of knowledge, effort, and skill on the part of the developer.

My own feeling is that it's best to let sleeping dogs lie. I love the Java platform, but it currently has a higher calling. Best to let it work where it excels and focus on the aspects of the browser that currently excel. (e.g. Javascript)

Re:Two steps backward

[AKAImBatman]

Strong typing means 1 + "2" is nonsense, and you have to explicitly convert the types.

That example has nothing to do with strong typing, but rather operator overloading. Both Java and Javascript understand "+" to be a string concatenation symbol when dealing with strings. Thus they attempt to coerce the values into strings. In Java's case, the resulting output looks something like this:

new StringBuffer().append(String.valueOf(1)).append("2");

Javascript does have implicit type casting (e.g. '1' - 1 = 0), but this is a feature that can be found in quite a few strongly languages. (e.g. int x = 10; char val = 10; x += val) Javascript is actually STRONGER than C when it comes to typing. When I cast a variable to a new type, its original type information is redefined and/or completely lost. This can create problems when programmers start using (void *) pointers for everything. Javascript remembers the underlying type of a value at all times. Values are never modified or destroyed, but can be coerced to create a new value with an implicitly cast type.

Re:Two steps backward

[cowwoc2001]

No, you're thinking of Java6 (no updates). Java6 update 10 introduced many client-side enhancements, such as preloading of the browser plugin so the first time you hit applets they load instantaneously.

I can see the appeal; but it sucks.

[fuzzyfuzzyfungus]

Yeah, as the title suggests, I can see why this would be attractive. x86s are everywhere, as is code for them, sidesteps the hassle of working it out in javascript, etc, etc. That said, though, it seems really, really gross. For those applications where dealing with an embedded add-on is an acceptable tradeoff for higher performance, we already have java, which is designed for platform independence(JVM), sandboxability, etc. and has had years of development and wide support. Particularly given the increasing popularity of web on embedded(read non-x86) devices, "sorta-kinda-quasi-java-that-only-runs-on-x86s" seems like an enormous step back. Why would you do that?

Re:I can see the appeal; but it sucks.

[0xABADC0DA]

we already have java, which is designed for platform independence(JVM), sandboxability, etc. and has had years of development and wide support. Particularly given the increasing popularity of web on embedded(read non-x86) devices, "sorta-kinda-quasi-java-that-only-runs-on-x86s" seems like an enormous step back. Why would you do that?

Isn't it obvious? Google standardized on C++, Java, and Python. As you point out, Java is already there. This 'any x86' lets them use their other two languages, C and Python. It kills two birds with one stone, and securing x86 is a hell of a lot easier than securing C++.

Of course, if they just straight up told people they wanted to choose the wrong tool for the job just because it's what they know they would have been laughed off the web.

"secured (ala ActiveX)"

[fgaliegue]

Talk about an oxymoron.

Beta

[rodrigoandrade]

"We've released this project at an early, research stage to get feedback from the security and broader open-source communities."

Just slap a "Beta" on it and move on, that's the Google way, right?

Re:Beta

[ionix5891]

Nope the google way is:

1. slap "Ads by Google" on everything
2. ???
3. PROFIT !

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.

WTF? Do you know what you're talking about?

[gbutler69]

class Main implements Object {

    public staic void main ( String[] args ) {

        try {
            // Do a bunch of stuff and call whatever
            ...
        }
        catch ( Throwable T ) {
            // Handle any exception that is not otherwise handled
           ...
        }
    }
}

Only an AC needs to ask...

[Tenebrousedge]

If you had any, you'd know.

Java Not Dead

[Doc Ruby]

Java applets are not "dead and buried". Neither on the Web, nor on mobile phones (with the distinction increasingly meaningless), or on embedded devices, like DVD players and settop boxes (most of which have Java VMs in them, especially Blu-Ray players and other HD players for menus).

What is "dead and buried" is ActiveX, which is x86 code running in a browser's "sandbox". But even that is clearly no barrier to resurgence, as this story shows.

x86 is a lousy architecture for modern purposes. Its design was determined by optimizations for executing Pascal programs, which was the primary programming market for the IBM PC when it was originally designed. That was a long time ago, and only the huge legacy of existing apps (and their forward momentum maintained by huge backwards compatibility design and sacrifices) keeps x86 code popular. I'm all for a SW x86 emulator, especially for newer CPUs so they don't have to be shackled to design compromises just to run the legacy code, instead of doing it newer and better ways with a more modern instruction set. Just like I'm all for the game emulators that will play old Atari 2600 games on Core Duo PCs and ARM mobile phones. Let's just not enslave ourselves to 1980 design priorities optimizing for a really dead language for yet another decade of programming, now going on 30 years, which is 20 generations under Moore's Law.

Emulation speed

[Rob Y.]

The problem with Virtual PC on the G5 is that it needs to emulate the X86 application code plus the Windows OS.

Since most apps strike a pretty reasonable balance between application logic and library calls, most emulators only need to emulate a relatively small portion of the code. They can drop down into native implementations as soon as the app calls library code. That's why script languages are viable at all.

Where I work, we had a large set of applications written in assembler (don't ask) for an '80s vintage minicomputer that was discontinued. Rather then junk the whole thing, we wrote a machine emulator and reimplemented key libraries in C on unix. The result was faster than the original minis, since modern unix hardware was so much faster and the app/library mix was skewed toward the native libraries.

I think one of the problems with traditional desktop Java apps was that major libraries (like Swing?) were not available on all platforms as native code. Again, that leaves you essentially emulating the application plus the platform, which shouldn't be necessary. Don't know if that's still an issue with Java. Certainly Eclipse seems to perform pretty well (once it starts up)...