Google Native Client

From Infogalactic: the planetary knowledge core
Jump to: navigation, search
Not to be confused with Networking and Cryptography library.
Google Native Client
Google Chrome for Android Icon 2016.svg
Developer(s) Google, others
Initial release September 16, 2011; 12 years ago (2011-09-16)[1]
Stable release SDK: Pepper 45 (10 July 2015; 8 years ago (2015-07-10)), Client:
Windows, OS X, Linux 51.0.2704.63 (May 25, 2016; 7 years ago (2016-05-25)[2]) [±]
Android 50.0.2661.87 (April 26, 2016; 7 years ago (2016-04-26)[3]) [±]
iOS 50.0.2661.95 (May 3, 2016; 7 years ago (2016-05-03)[4]) [±]
Development status Production (NaCl, PNaCl[5])
Written in C, C++
Operating system Cross-platform: Windows, Linux, OS X, Chrome OS
Platform x86, x86-64, ARM, MIPS
Type Sandbox in web browsers for native code
License New BSD
Website developer.chrome.com/native-client

Google Native Client (NaCl) is a sandboxing technology for running a subset of Intel x86/x86-64, ARM or MIPS native code in a sandbox. It allows safely running native code from a web browser, independent of the user operating system, allowing web-based applications to run at near-native speeds, which aligns with Google's plans for Chrome OS. It may also be used for securing browser plugins, and parts of other applications or full applications[6] such as ZeroVM.[7]

To demonstrate the readiness of the technology, on 9 December 2011, Google announced the availability of several new Chrome-only versions of games known for their rich and processor-intensive graphics, including Bastion (no longer supported on the Chrome Web Store). NaCl runs hardware-accelerated 3D graphics (via OpenGL ES 2.0), sandboxed local file storage, dynamic loading, full screen mode, and mouse capture. There are also plans to make NaCl available on handheld devices.[8][9]

Portable Native Client (PNaCl) is an architecture-independent version. PNaCl apps are compiled ahead-of-time. PNaCl is recommended over NaCl for most use cases.[10] The general concept of NaCl (running native code in web browser) has been implemented before in ActiveX, which, while still in use, has a legacy of DLL hell and security problems. Native Client avoids these issues by using sandboxing.

An alternative of sorts to NaCl is asm.js, which also allows applications written in C or C++ to be compiled to run in the browser (at more than half the native speed), and also supports ahead-of-time compilation, but is a subset of JavaScript and hence backwards-compatible with browsers that do not support it directly. Another alternative (while it may initially be powered by PNaCl) is WebAssembly.

Overview

Native Client is an open-source project being developed by Google.[11] To date, Quake,[12] XaoS, Battle for Wesnoth,[13] Doom,[14] Lara Croft and the Guardian of Light,[15] From Dust[16] and MAME, as well as the sound processing system Csound, have been ported to Native Client. Native Client has been available in the Google Chrome web browser since version 14, and has been enabled by default since version 31, when the Portable Native Client (PNaCl, pronounced: pinnacle) was released.[17][18][19]

An ARM implementation was released in March 2010.[20] x86-64, IA-32 and MIPS are also supported.

To run an application portably under PNaCl, it must be compiled to an architecture-agnostic and stable subset of the LLVM intermediate representation bytecode.[21] The executables are called PNaCl executables (pexes). In Chrome, they are translated to architecture-specific executables so that they can be run.

NaCl uses software fault detection and isolation for sandboxing on x86-64 and ARM.[22] The x86-32 implementation of Native Client is notable for its novel sandboxing method, which makes use of the x86 architecture's rarely used segmentation facility.[23] Native Client sets up x86 segments to restrict the memory range that the sandboxed code can access. It uses a code verifier to prevent use of unsafe instructions such as those that perform system calls. To prevent the code from jumping to an unsafe instruction hidden in the middle of a safe instruction, Native Client requires that all indirect jumps be jumps to the start of 32-byte-aligned blocks, and instructions are not allowed to straddle these blocks.[23] Because of these constraints, C and C++ code must be recompiled to run under Native Client, which provides customized versions of the GNU toolchain, specifically GNU Compiler Collection (GCC), GNU Binutils, and LLVM.

Native Client is licensed under a BSD-style license.

Native Client uses Newlib as its C library, but a port of GNU C Library (GNU libc) is also available.[24]

Pepper

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

Sodium chloride (NaCl) denotes table salt; as a pun, the name of pepper was also used. Pepper API is a cross-platform, open-source API for creating Native Client modules.[25] Pepper Plugin API, or PPAPI[26][27] is a cross-platform API for Native Client-secured web browser plugins, first based on Netscape's NPAPI, then rewritten from scratch. It is currently used in Chromium and Google Chrome to enable the PPAPI version of Adobe Flash[28] and the built-in PDF viewer.[29]

PPAPI

On 12 August 2009, a page on Google Code introduced a new project, Pepper, and the associated Pepper Plugin API (PPAPI),[30] "a set of modifications to NPAPI to make plugins more portable and more secure".[31] This extension is designed specifically to ease implementing out-of-process plugin execution. Further, the goals of the project are to provide a framework for making plugins fully cross-platform. Topics considered include:

  • Uniform semantics for NPAPI across browsers.
  • Execution in a separate process from the renderer-browser.
  • Standardize rendering using the browser's compositing process.
  • Defining standardized events, and 2D rasterizing functions.
  • Initial attempt to provide 3D graphics access.
  • Plugin registry.

The continuously evolving Pepper API also supports Gamepads (version 19) and WebSockets (version 18).[32]

As of 13 May 2010, Google's open source browser, Chromium, was the only web browser to use the new browser plug-in model.[33] Mozilla Firefox will not support Pepper, as there is no full specification of the API beyond its implementation in Chrome, which itself is designed for use with Blink layout engine only, and has private APIs specific to the Flash Player plugin which are not documented.[34] As of 2015, Pepper is supported by Chrome, Chromium and Blink layout engine-based browsers such as Opera.

Applications

One website[35] uses NaCL to let users experiment with the Go programming language in their browsers.

Reception

Some groups of browser developers support the Native Client technology, but others do not.

Supporters: Chad Austin (of IMVU) praised the way Native Client can bring high-performance applications to the web (with about 5% penalty compared to native code) in a secure way, while also accelerating the evolution of client-side applications by giving a choice of the programming language used (besides JavaScript).[36]

Id Software's John D. Carmack praised Native Client at QuakeCon 2012, saying: "if you have to do something inside a browser, Native Client is much more interesting as something that started out as a really pretty darn clever x86 hack in the way that they could sandbox all of this in user mode interestingly. It's now dynamic recompilation, but something that you program in C or C++ and it compiles down to something that's going to be not your -O4 optimization level for completely native code but pretty damn close to native code. You could do all of your evil pointer chasings, and whatever you want to do as a to-the-metal game developer."[37]

Detractors: Other IT professionals are more critical of this sandboxing technology as it has substantial or substantive interoperability issues.

Mozilla's vice president of products, Jay Sullivan, said that Mozilla has no plans to run native code inside the browser, as "These native apps are just little black boxes in a webpage. [...] We really believe in HTML, and this is where we want to focus."[38]

Mozilla's Christopher Blizzard criticized NaCl, claiming that native code cannot evolve in the same way that the source code-driven web can. He also compared NaCl to Microsoft's ActiveX technology, plagued with DLL hell.[6]

Håkon Wium Lie, Opera's CTO, believes that "NaCl seems to be 'yearning for the bad old days, before the web'", and that "Native Client is about building a new platform – or porting an old platform into the web [...] it will bring in complexity and security issues, and it will take away focus from the web platform."[6]

See also

References

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found.
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Lua error in package.lua at line 80: module 'strict' not found.
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. 6.0 6.1 6.2 Lua error in package.lua at line 80: module 'strict' not found.
  7. Lua error in package.lua at line 80: module 'strict' not found.
  8. Lua error in package.lua at line 80: module 'strict' not found.
  9. Lua error in package.lua at line 80: module 'strict' not found.
  10. Lua error in package.lua at line 80: module 'strict' not found.
  11. Lua error in package.lua at line 80: module 'strict' not found.
  12. Lua error in package.lua at line 80: module 'strict' not found.
  13. Lua error in package.lua at line 80: module 'strict' not found.
  14. Lua error in package.lua at line 80: module 'strict' not found.
  15. https://chrome.google.com/webstore/detail/lara-croft-and-the-guardi/dcfdbmpeeihbpddkneaploeinlbaaodn
  16. Lua error in package.lua at line 80: module 'strict' not found.
  17. Lua error in package.lua at line 80: module 'strict' not found.
  18. Lua error in package.lua at line 80: module 'strict' not found.
  19. Lua error in package.lua at line 80: module 'strict' not found.
  20. Lua error in package.lua at line 80: module 'strict' not found.
  21. Lua error in package.lua at line 80: module 'strict' not found.
  22. Lua error in package.lua at line 80: module 'strict' not found.
  23. 23.0 23.1 Lua error in package.lua at line 80: module 'strict' not found.
  24. Lua error in package.lua at line 80: module 'strict' not found.
  25. Lua error in package.lua at line 80: module 'strict' not found.
  26. Lua error in package.lua at line 80: module 'strict' not found.
  27. Lua error in package.lua at line 80: module 'strict' not found.
  28. Lua error in package.lua at line 80: module 'strict' not found.
  29. Lua error in package.lua at line 80: module 'strict' not found.
  30. Lua error in package.lua at line 80: module 'strict' not found.
  31. Lua error in package.lua at line 80: module 'strict' not found.
  32. Lua error in package.lua at line 80: module 'strict' not found.
  33. Lua error in package.lua at line 80: module 'strict' not found.
  34. Lua error in package.lua at line 80: module 'strict' not found.
  35. Lua error in package.lua at line 80: module 'strict' not found.
  36. Lua error in package.lua at line 80: module 'strict' not found.
  37. Lua error in package.lua at line 80: module 'strict' not found.
  38. Lua error in package.lua at line 80: module 'strict' not found.

External links

Examples

  1. REDIRECT Template:Google LLC