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.
Re:Not Java, more like Active X (Score:5, Funny)
Re:Give it the registry. (Score:3)
That might take 10,000 lines of code. What are the chances of an error in that?
Re: (Score:2)
Re: (Score:2)
Lines not words. You need to multiply by at least two.
Re: (Score:2)
Re:Not Java, more like Active X (Score:5, Insightful)
I don't see how it could be made secure at all
This may have something to do with you not making any effort whatsoever to read up on what NaCl actually does.
Re: (Score:2)
Well, this thing is supposed to be platform-independent, so you would HAVE to go through a Google API to get any access to the hard drive. I would imagine that they would but blocks in that could stop nefarious actions. They will most likely NOT allow access to operating system calls, since the code is supposed to be able to run on any operating system.
Re: (Score:3)
It uses something called Newlib, but there's also a port of libc. And of course no OS calls are allowed.
http://en.wikipedia.org/wiki/Google_Native_Client [wikipedia.org]
Re: (Score:3)
They are actually both sandboxed and statically analyzed for safety. Of course there can still be holes in all that, but there's been a lot of effort put into breaking and fixing it already.
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: (Score:2)
There's a difference between sandboxing scripts which you facilitate the execution of/interperate yourself (Javascript, to a lesser extent Flash and Java) and native code.
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.
Re: (Score:3)
I imagine they'll keep NaCl in a similar sandbox.
I prefer to keep SiO2 in my sandbox, But whatever flips your switch.
Re: (Score:2)
Chrome is extremely sandboxed. Scripts running in Chrome don't have permission to randomly alter files, install software, etc. like ActiveX did.
Chrome extensions are even limited in the ability to alter their own files. Or at least that's seems to be the reason NotScripts needs you to edit one of its files by hand after you install it.
Re: (Score:3)
Java, Flash, Silverlight, etc. all replace web technologies in your browser.
NaCl is designed to be used with HTML, CSS, Javascript, and all the other HTML5 technologies. It essentially lets you pre-optimize pieces of performance critical pieces of Javascript such as codecs.
Re: (Score:3)
"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."
Only if you explicitly give the app permission to do those things.
And, what is wrong with that. There is a Google Maps live wallpaper that does just that - requests and uses my real-time location.
It's a bit different then the iPhone where Apple is tracking your location whether you like it or not (permission is buried in the iTunes
Re: (Score:3)
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.
Only true in the most vague of the meaning. As most people will read that statement, its implications are completely untrue. Android is extremely secure and has the best security model of all mobile OSs.
A wallpaper may read contacts and track your location but only, and I mean ONLY, if the user specifically accepts the associated permissions which very clearly say the application has such capabilities. To blame Android for user stupidity, it say you're not trolling.
Simply put, when you install an Android ap
NaCl + GAE (Score:4, Interesting)
Re: (Score:2)
Yeah I really wish there was a way to run native code on a web server [wikipedia.org].
Re: (Score:2)
There's nothing browser specific about the base technology. It's just that their main use case for it is in the browser. They could fairly easily adapt it for running code on the app engine, if they wanted.
this is a terrible idea (Score:5, Funny)
I am qualified to comment because I have skimmed the article summary. Furthermore, I know perfectly well that any time a browser allows for new features, it's a way to get hacked by eastern bloc countries. Finally, I can't remember why I was angry in the first place, but I can guarantee you that if whatever it was is also the reason the honeybees have been dying off. I am getting so sick of this stuff!
Re:this is *not* a terrible idea (Score:4)
I don't see this as something that would be extensively used on a lot of web sites, and there are potential security issues that need to be scrutinized, but it's another tool available to developers. I like it.
Re: (Score:3)
pithy response either incorporating trending memes or exploiting unclosed double-entendres in parent post
ActiveX revisited? (Score:5, Insightful)
So a proprietary, but open SDK to run native binaries on one vendors browser. What could possibly go wrong?
I hope Google put a heck of a lot more effort into security/sandbox issues than Microsoft did or I'm going to have to start telling people to never install Chrome. ActiveX was the best attack vector for Windows for the longest time, and as far as I know it's still pretty effective against the great unwashed who will click anything to make a dialog go away.
Re:ActiveX revisited? (Score:5, Informative)
Re: (Score:3)
Shouldn't we ask a different quest ? Like: is it possible to put ENOUGH effort into it to make it secure ? Remember that, not only they need to avoid exploitation of the plugin (whatever) itself, they need to avoid exploitation of the browser, Windows API etc.
Re: (Score:3)
Shouldn't we ask a different quest ? Like: is it possible to put ENOUGH effort into it to make it secure ?
Good question. I do not believe it is possible to make a native binary safe, but then I'm just a computer geek with a degree in the subject and a decade of professional experience. Who am I to question the great Google.
Re: (Score:3)
Good question. I do not believe it is possible to make a native binary safe
I highly recommend that you actually read what NaCl is all about. The idea is to use various tricks about x86, such as memory segmentation, to produce a subset of opcodes which can be statically verified to be memory-safe, or otherwise easily intercepted by the sandbox. The subset is still large enough that you can compile C code efficiently into it, but you can't just take any random binary and run it in NaCl - you need to use their own toolchain.
(I've no idea what tricks they have used on ARM)
Re: (Score:2)
Really? Because a little-known piece of computer software called an OPERATING SYSTEM makes native binaries safe THE WHOLE TIME.
ORLY?
Re: (Score:2)
Re: (Score:2)
Why make it secure, when there is money to be made by having it INsecure. Trust Google...
Do not attribute to malice that which is more adequately explained by stupidity. [wikipedia.org]
Re: (Score:3)
Why make it secure, when there is money to be made by having it INsecure. Trust Google...
Do not attribute to malice that which is more adequately explained by stupidity.
Do not attribute to stupidity that which is more adequately explained by greed.
-- Enron's razor
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).
Re:ActiveX revisited? (Score:4, Interesting)
You probably should start reading about it first, please. The browser doesn't allow you to run native binaries of the system, or native code in general. It allows you to run very constrained routines in assembler code, but a very limited set of instructions, only the ones that can be secured enough. That's why you need an specialized SDK: the generated binaries have to use a very reduced set of machine instructions.
The great benefit of this, is that the generated ".nexe" files are portable accross operating systems. Basically, is a way to run heavy routines in C/C++ instead of JavaScript. The API is limited too.
It's pretty cool in the sense that you could do fancy graphics or UIs without Flash or Silverlight. You could write them in Qt or GTK+ or SDL, and the generated executable works on every OS (you'll need a recompile for ARM phones though).
If it can be refactored to a plugin for every browser, this will be the best Flash/Silverlight killer ever.
Re: (Score:3)
So a proprietary, but open SDK to run native binaries on one vendors browser. What could possibly go wrong?
Good questions. I'm not saying that I think it's a good idea, but there are significant differences from ActiveX. First off, it's sandboxed, it doesn't have native access to the OS, only native access to the CPU and only in ring 3. Second, it's single browser, but cross platform (Runs on Chrome on Linux, Windows, and Mac OS).
Of course, the fact that 32-bit code won't run on a 64-bit system and vise-verse is a (possibly minor) disaster waiting to happen. Add ARM on Android smartphones and you've definitely c
Re: (Score:2)
Re: (Score:2)
I'm not sure what the point of this is though, if you're delivering native binaries you might as well just install the application locally. Consider (as the article mentions) a NaCl version of Photoshop. Well, you would have to download the entire app every time you use it? Why not just install Photoshop?
I suspect it's perceived to be easier to users manage and maintain. The road to hell is paved with good intentions.
I had to point out to my management years ago that any kind of software install is effectively a violation of security. As a vendor it is not a question of IF you violate security, it's a question of HOW.
I suspect that the corporate IT world will come down on end-users who use Chrome like a ton of bricks if this gets any traction.
Re: (Score:2)
Have you ever heard of caching? In theory, if the binary code hasn't changed, then if the NaCl module is cached properly, you'd only have to download it the first time. Of course, you'd have to redownload it anytime it changes on the server, but look at it this way - you get instant access to updates.
And if you read the article, Google's purpose in this is not to create huge, full applications in native code and then run them through the browser, but combine this native calculations with the cloud. In Photo
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: (Score:3)
Sounds likely, but if that's the approach, then why use native code at all? If you are going to effectively do JIT compilation on x86 code, turning it into more x86 code with extra safety checks, then why not instead do the JIT compilation on something intended to be JIT-compiled? For instance you could serve up some intermediate representation of the program, like LLVM bitcode. But that just sounds like Java or C#...
Re: (Score:3, Interesting)
NaCl in it's current implementation is not JIT compiled. It is actual compiled native x86 (or x64 or arm) code running in a secure sandbox. What causes a delay is the Validation of the code, ie, the code has to meet certain requirements to be secure. That said, Google has plans for PNaCl, "portable" nacl, which indeed uses LLVM bytecode, making it a JIT implementation. Why not just use JavaScript? Having access to a lower level language and to being able to reuse tons of existing code is a big plus. Think p
Re:Light on details (Score:4, Interesting)
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.
Re: (Score:3)
I don't know for sure, but I suspect that proving code is safe using static analysis is probably NP-complete
This is dealt with by proving that code is not unsafe instead (which is a different problem, as this allows for false positives). Which is precisely what any sandboxed VM out there, like Java or .NET, have been doing for ages. You usually start by throwing out all instructions that aren't easily verifiable.
Re: (Score:2)
Re: (Score:2)
Thanks, that's very informative. I wonder what is involved in validation, and what restrictions are imposed to ensure the code is actually safe? Sounds like a tricky problem - difficult enough that it's previously only been solved by (1) restricted languages like Java and C#, or (2) in hardware, with protected memory and access to the OS only via system calls. To do it with arbitrary x86 code is certainly interesting. I wonder if this could be useful not just for browsers, but even entire OSes where memory
Re: (Score:2)
Re: (Score:2)
Instrumented binaries are not currently faster than interpreters, they are useful for debugging and auditing, but they are not quite native in performance. With CPU having virtual machine extensions these days, virtual machines have performance similar to non-virtual machines, and would in my mind make more sense. Then again I am not sure what Google are doing. It sounds like they are just OS sandboxing it, like running the browser in chroot as the nobody user.
NaCl is very useful... (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
Yeah and too much of it can kill you...
Of course that's also true of O2 and H2O.
Crazy smart? No, just crazy (Score:3)
From where I stand, that's no better than being forced to VNC into a Windows box just so that I can access an ActiveX based site which will only run on Explorer.
ActiveX also is a nice case study to show what the tech would be used for- which is, about 50% of the time to exploit security holes, and 49% of the time, to do stuff that could just as well have been accomplished through W3C standards or (much more portable) Java.
Bad idea. *flush*
Re: (Score:3)
Basically this technology turns the browser from a platform-independent, architecture-independent development platform into an architecture-dependent one. That is, if somebody developed their little app for Intel and I'm on a Mac or Arm, the app won't work for me.
Macs for the past several years have been running Intel CPUs.
Re: (Score:2)
Wrong. The NEXE files are OS independent. You will need a recompile for ARM though. Why don't you at least read the FAQ [google.com]?
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: (Score:2)
Basically this technology turns the browser from a platform-independent, architecture-independent development platform into an architecture-dependent one. That is, if somebody developed their little app for Intel and I'm on a Mac or Arm, the app won't work for me.
While it may look like this short term, fragmentation is not the goal. Currently, NaCl has compilers for x86, x64 and arm, and in most cases code working on one should compile and work on the others without changes. Long term, the idea is to use LLVM bytecode to solve this problem for all architectures. As for browser compatibility, Google is actively encouraging other browser makers to pick up the tech, which is all open source.
While JavaScript may have it's use, it's going to be a while before the next hi
but... (Score:3)
Re: (Score:2)
I'm NOT running an x86 capable processor...
You have an Itanium, too?
Re: (Score:3)
Cell phones and tablets are mostly ARM. NaCl is mostly useless unless you want to prop up power-sucking Intel CPUs and their x86 monopoly.
Re: (Score:2)
Re: (Score:2)
No, a Phenom.
JavaScript (Score:2)
Why not just work on making JS more efficient, and if needed, give it more capability?
Applets were explored in the past and died because they were not what people wanted..
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: (Score:2)
there's little demand for higher performance apps in the browser
As much as I hate the idea of a browser that is able to run downloaded native binaries, I have to disagree here. In the corporate enterprise world there is a HUGE demand for this since it centralizes and simplifies the software distribution problem.
Re: (Score:2)
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.
It has very little to do with performance and a whole lot to do with being able to use pre-existing binary-only code safely.
Re: (Score:3)
It has very little to do with performance and a whole lot to do with being able to use pre-existing binary-only code safely.
No. The code has to be recompiled with a modified compiler, and has to use the special cross-platform API. Porting isn't a big job, but you do need the source code. Read the tech paper.
Re: (Score:2)
I imagine a Photoshop app where rendering is done server side and client side in parallel. This can also lead to cloud vendor using your computer to perform calculations for others. Can you say distributed, decentralized, cloud computing?
Re: (Score:2)
We already have this. It's called a botnet.
NaCl (Score:2)
Re: (Score:2)
Yeah, you wouldn't want to confuse anyone by saying "I'm running my Windows code in a browser window on my Apple".
They'd think you're mad, talking about windows that run inside apples.
I really wish... (Score:5, Insightful)
I really wish folks wouldn't intermix this crap with a web browser. I'm all for having some kind of a cloud browser for accessing Internet-based applications with the client running java or nacl or whatever. But when I'm surfing the web looking at untrusted sites, I don't want ANYTHING running browser-side. Not even javascript.
Re: (Score:2)
Too late for that. Ask for a checkbox to disable it and you'll get the same effect you get with JavaScript now.
The REAL Chrome OS (Score:2)
Gentlemen, let me present to you the REAL Chrome OS. Run native apps directly in your browser, straight down to a hypervisor. Windows and Linux need not apply.
Re: (Score:2)
That is what I've been saying ever since ChromeOS has been announced. Everyone said it was crazy to ship an OS that was only a browser, and basically couldn't run anything.
Consider now that the entire OS is locked down and fairly secure. Consider how the browser also keeps NaCl in a sandbox. And now you have perhaps a very simple and secure way to run all kinds of apps with the OS that no one was taking seriously.
Re: (Score:2)
Everyone said it was crazy to ship an OS that was only a browser, and basically couldn't run anything.
Not everyone. I distinctly remember reports that Bill Gates openly discissed his fear that computers would become entirely browser-based and make operating-system user interfaces obsolete, killing his company. IIRC, it was one of the things that justified developing .NET.
Missed the obvious motive. (Score:3)
Google seems to have fully realized that as long as the Windows/Office monopoly is pumping billions of dollars into the coffers of Microsoft, it can simply wait out any competitor. Unless holes are poked in that firehose Google is just one stumble away from being vaporized. So it does what it can to make sure Microsoft plays defense.
Browser as OS (Score:2)
This would run only "pure" native code, and not access any OS features of the main OS on the client's machine. Any OS features would be provided by the browser. In a sense the browser would implement a virtual machine and become an OS running on top of any other OS that Chrome runs on.
Google wants control of as much of "app space" as they can, as all the major players do... Not necessarily for dominance; it may simply be to get around the dominance of others. For maximum control, you control the OS (ideally
Re: (Score:2)
Oh. So you've met Android.
First step to being the OS (Score:2)
The blatant security issues of allowing websites to download and execute native code far outweigh any benefits. Even Google must know that.
So it seems that this is really just a first step to rid PC's of Windows OS entirely, such that the PC boots right into a browser.
As far as I'm concerned, even though the superficial concept sucks, separating the mainstream from its Microsoft addiction would be worth the price.
I may be suffering from buzzword syndrome (Score:2)
But going from this (particularly the C/C++ friendliness), you could almost run a Unix/Linux implementation across the entire cloud, with each browser being a separate 'login'?
It almost seems designed with that as a goal.
Pug
Time to dust off the old software (Score:2)
This is great news! Now I can pull up that copy of VisiCalc.
Chrome + Salt = Rust (Score:2)
Seems google took more than the tech talent from the rotting corpse of Bell Labs. They seem to have captured the marketing folks as well.
Won't work on 64-bit Windows (Score:3)
Unlike 32-bit Windows, 64-bit Windows does not provide user-mode programs the ability to create arbitrary selectors. NtSetLdtEntries returns STATUS_NOT_IMPLEMENTED in 64-bit Windows. In fact, in Vista 64 and XP 64, the kernel does "xor eax, eax \ lldt ax" and never touches LDTR again. This means that even drivers couldn't create selectors on behalf of user-mode programs, because the Windows scheduler does not save or restore LDTR during a task switch.
This is absolutely core functionality that is necessary in order for this to work - if user mode can't create selectors with shorter limits, Google's design plain doesn't work.
In contrast, even in 64-bit mode, Linux allows modify_ldt() and Mac OS allows i386_set_ldt(). In fact, this functionality is the only reason WINE is possible on these platforms.
Re: (Score:2)
Re: (Score:3)
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: (Score:3)
I read that as in "until someone finds a way around it". I give it a week.
Re: (Score:2)
Fancy a wager? I'll offer you even odds on a month for any sum up to $500.
Re: (Score:2)
It's been around for years already.
Re:NaCl? (Score:5, Funny)
Re:NaCl? (Score:5, Informative)
Re:Why???? (Score:5, Interesting)
Re: (Score:2)
Yo Dawg, I hear you liked to browse ... so I put a browser in your browser, so now you can browse while you're browsing.
Re:Dawg (Score:2)
Bowser! Come here boy!
Oh wait...
Re: (Score:2)
Re: (Score:2)
I already have an OS. It plays movies, games, and anything else I throw at it. I don't need to run a 2nd OS on top of it to replicate the functions of the original.
ChromeOS. This will allow it to have real applications. Correct me if I'm wrong, but doesn't Native Client in Chromium imply that a ChromeOS app can be written once and run on any platform with Chromium? The ability to support 4 or 5 platforms, without any effort put into porting...certainly not something to be dismissed lightly.
Re: (Score:2)
Apart from the security catastrophe this would surely cause, it's a bad idea because it's architecture-specific. Name one other web technology that is, apart from shitty ActiveX that nobody uses (and is also OS-specific and browser-specific). Go on. I'll wait.
You can talk to anyone with a PhD in computer science and they'll tell you the same thing. You can call them all short-sighted idiots too if you like.
Re: (Score:2)
It is a bad idea because of the architecture and OS specific part. It is not clear it is security problem though. It presumably runs in ring 3, so all OS traps, naughty memory traipses, etc. can be caught. What specific security problem do you expect it to cause?
I can only think of one, if there is a problem in the underlying OS....well, since we're probably talking MS here, multiple security problems in the underlying OS that can be accessed through OS traps that go to kernel mode or any that MS left out i
Re: (Score:3)
CPU microcode vulnerabilities could also be exploited, such as this one:
http://www.networkworld.com/community/node/39825 [networkworld.com]