Slashdot Mirror
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.
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
Does it run Linux??
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.
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?
Javascript + Nintendo DSi = DSiCade
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?
The only question remains whether it can be secured (ala ActiveX)
HAHAHAHAHAHAHAHAHAHAHAHAHAHA *gasp* HAHAHAHAHAHAHAHAHAHAHAHHAAHHAHA *wipes eyes*
HAHAHAHAHAHAAHHAAHAHAHAHAHAHAH
Talk about an oxymoron.
"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?
Microsoft is doing something similar and is, in fact, presenting a talk today on leveraging legacy code to deploy desktop applications on the web.
You can find more details here.
BIG thanks from Russia. i hope it catches on!
Does this mean I can run old DOS games in a browser?
Silent Service II!
It will go far.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Does Linux run on it?
(Prompting a possibly valid "In Soviet Russia" gag).
Genesis 1:32 And God typed
Nothing on Netcraft yet...
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Clearly, playing Quake in the browser is the killer app for this technology.
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.
If you had any, you'd know.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
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.
--
make install -not war
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)...
Posted from my Android phone. Oh, I can change this? There, that's better...
JIT emulation is the worst of both possible worlds! The extra overhead of the bytecode to native translations and the extra overhead of emulation!
Bad, only if it is handled bad. Logging an unhanded exception may be a good thing in showing programmers that something is happening that they didn't think of.
Paying taxes to buy civilization is like paying a hooker to buy love.
Um, a pure interpreter never "compiles" its program, in the sense of transforming the code into equivalent code in an object language. A pure interpreter usually works this way:
The easiest example to learn here would be a typical Lisp meta-circular evaulator.
A compiler, on the other hand, translates the AST into equivalent object code in a different language, which can then be run in an implementation of that second language (which can be either a real machine, a virtual machine, a language interpreter, ). For a pure interpreter to "compile each instruction every time it gets executed," there would have to be a program in the object language involved somewhere... and there isn't one, only an model of the successive states of a computation.
Are you adequate?