Forgot your password?
typodupeerror
Google Programming Virtualization

Google x86 Native Browser Client Maybe Not So Crazy After All 332

Posted by CmdrTaco
from the because-you-can dept.
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."
This discussion has been archived. No new comments can be posted.

Google x86 Native Browser Client Maybe Not So Crazy After All

Comments Filter:
  • by Anonymous Coward on Thursday February 24, 2011 @01:19PM (#35301694)

    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.

    • by WrongSizeGlass (838941) on Thursday February 24, 2011 @01:20PM (#35301712)
      Now all they need to do is give it full access to the Windows Registry and we'll be right back to where we started.
    • by Dunbal (464142) *
      I don't see how it could be made secure at all, unless it's a virtual machine - you are giving it execute privileges. That means at least full read access to all hardware, including the hard disk. While some OSes are picky about who gets to write where, this means your whole HD can be scanned. This is an absolutely horrible idea - from the user's perspective. But in Corporate America, program uses you!
      • by Goaway (82658) on Thursday February 24, 2011 @03:03PM (#35303258) Homepage

        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.

    • by Enderandrew (866215) <enderandrew AT gmail DOT com> on Thursday February 24, 2011 @01:51PM (#35302190) Homepage Journal

      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.

      • by ByOhTek (1181381)

        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.

      • by toastar (573882)

        I imagine they'll keep NaCl in a similar sandbox.

        I prefer to keep SiO2 in my sandbox, But whatever flips your switch.

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

    • by Trufagus (1803250)

      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.

    • by Trufagus (1803250)

      "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

    • by GooberToo (74388)

      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)

    by rumith (983060) on Thursday February 24, 2011 @01:23PM (#35301750)
    Can't wait for this thing to get hooked to App Engine once they are both stable enough. The results will likely be breathtaking, to say the least.
  • by digitalsushi (137809) <slashdot@digitalsushi.com> on Thursday February 24, 2011 @01:24PM (#35301772) Journal

    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!

    • by djbckr (673156) on Thursday February 24, 2011 @01:37PM (#35301936)
      I too am qualified to comment. I'm not fully convinced it's a great idea, but I like the idea of running "next to the hardware" code in a sandbox (the browser). It's sort-of the best of virtualization (sandbox, controlled by the browser) and C-style performance.
      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.
      • by blair1q (305137)

        pithy response either incorporating trending memes or exploiting unclosed double-entendres in parent post

  • ActiveX revisited? (Score:5, Insightful)

    by H0p313ss (811249) on Thursday February 24, 2011 @01:24PM (#35301774)

    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.

    • by TheRealMindChild (743925) on Thursday February 24, 2011 @01:32PM (#35301874) Homepage Journal
      That is because ActiveX is just a DLL. Loading an ActiveX library is just loading a DLL. It isn't ActiveX that is the problem, but the fact that you are allowing any site to install and run a DLL. You don't even need to load your own anymore. Just have a handy exploit for Adobe Flash, load random flash object to make sure the browsing party has the DLL(s) installed and loaded, then exploit Flash. Same goes for Java. And that zynga "helper" you have from Facebook...
    • by morcego (260031)

      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.

      • by H0p313ss (811249)

        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.

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

      • by Dunbal (464142) *
        Why make it secure, when there is money to be made by having it INsecure. Trust Google...
    • by Anonymous Coward on Thursday February 24, 2011 @01:43PM (#35302050)

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

    • by suy (1908306) on Thursday February 24, 2011 @02:00PM (#35302340) Homepage

      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.

    • 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

    • The ability to run these binaries must be explicitly enabled by the user, so no reason to avoid Chrome just yet ;)
  • Light on details (Score:5, Informative)

    by pclminion (145572) on Thursday February 24, 2011 @01:25PM (#35301782)

    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.

    • by JackDW (904211)

      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)

        by slart42 (694765)

        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)

          by pclminion (145572) on Thursday February 24, 2011 @01:50PM (#35302178)
          How well does the validation engine cope with code that's deliberately obfuscated? I don't know for sure, but I suspect that proving code is safe using static analysis is probably NP-complete. Dynamic instrumentation would make it much easier to implement sandboxing -- all operations which aren't explicitly permitted are forbidden, and you simply stop the code when it tries to do one of those forbidden things.
          • Re:Light on details (Score:4, Informative)

            by Trepidity (597) <.gro.hsikcah. .ta. .todhsals-muiriled.> on Thursday February 24, 2011 @02:00PM (#35302346)

            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.

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

        • by JackDW (904211)

          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

      • by pclminion (145572)
        It's not a huge investment. x86-to-x86 translators have existed for a while. Being able to use pre-existing native code is an enormously attractive possibility. This gives developers the ability to take pre-existing software and directly target it to Chrome without porting to another language or even recompiling it (I presume there will be a utility which converts .exes and .dlls into .nexe format)
    • by Carewolf (581105)

      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.

  • by coolmoose25 (1057210) on Thursday February 24, 2011 @01:33PM (#35301878)
    I use it all the time... I put it on french fries. I spread a lot of it on my driveway and sidewalk this year. The only real drawback is the high blood pressure that can result if you consume too much of it.
  • by mrjb (547783) on Thursday February 24, 2011 @01:38PM (#35301966)
    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.

    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*
    • 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.

    • by suy (1908306)

      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.

      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]?

    • by simula (1032230) on Thursday February 24, 2011 @02:10PM (#35302526) Homepage
      Native Client was designed to easily allow portability across all popular current platforms using cross-compilation. On a single development machine you can currently build executables for x86-32, x86-64, and arm. There is currently support for Windows, Linux, and OSX. Here is an article [chromium.org] on the generals.

      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].
    • by slart42 (694765)

      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

  • by advocate_one (662832) on Thursday February 24, 2011 @01:39PM (#35301970)
    I'm NOT running an x86 capable processor...
  • 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..

  • by Animats (122034) on Thursday February 24, 2011 @01:48PM (#35302128) Homepage

    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.

    • by H0p313ss (811249)

      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.

    • by pclminion (145572)

      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.

      • by Animats (122034)

        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.

  • I'm sorry, but calling it NaCl is just asking for people to be confused when it comes up in discussion. We already have enough problems with people using the intials of something where by pure happenstance those initials are the same as some more common reference. Now we have Google intentionally using the chemical abreviation for salt for this new initiative of theirs. If this was something that endusers could add to any software to amplify some aspect of the software (not that I can imagine how that could
    • by blair1q (305137)

      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)

    by Spazmania (174582) on Thursday February 24, 2011 @01:49PM (#35302150) Homepage

    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.

    • by blair1q (305137)

      Too late for that. Ask for a checkbox to disable it and you'll get the same effect you get with JavaScript now.

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

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

      • by blair1q (305137)

        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.

  • by 140Mandak262Jamuna (970587) on Thursday February 24, 2011 @01:57PM (#35302300) Journal
    Most obvious motive for doing this is to allow corporations that are stuck with old unmaintainable "applications" a way to get it running under Linux/ChromeOS/Android eventually. An escape hatch from the MS. Suddenly all those "apps" are ported to Linux, upgraded to run on the latest hardware, protected by the latest sandboxes. They can technically run IE6 under NaCl in ChromeOS. This does not have to make any money for Google.

    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.

  • 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

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

  • 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

  • This is great news! Now I can pull up that copy of VisiCalc.

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

  • by Myria (562655) on Thursday February 24, 2011 @03:20PM (#35303536)

    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.

You will be successful in your work.

Working...