diff options
Diffstat (limited to 'chromium/docs/website/site/nativeclient/getting-started/getting-started-background-and-basics/index.md')
-rw-r--r-- | chromium/docs/website/site/nativeclient/getting-started/getting-started-background-and-basics/index.md | 244 |
1 files changed, 0 insertions, 244 deletions
diff --git a/chromium/docs/website/site/nativeclient/getting-started/getting-started-background-and-basics/index.md b/chromium/docs/website/site/nativeclient/getting-started/getting-started-background-and-basics/index.md deleted file mode 100644 index 588a360aee2..00000000000 --- a/chromium/docs/website/site/nativeclient/getting-started/getting-started-background-and-basics/index.md +++ /dev/null @@ -1,244 +0,0 @@ ---- -breadcrumbs: -- - /nativeclient - - Native Client -- - /nativeclient/getting-started - - '1: Getting Started' -page_name: getting-started-background-and-basics -title: 'Getting Started: Background and Basics' ---- - -This document gives a broad high-level overview of what Native Client is and how -it fits into the world of web browsers and plugins (Chrome in particular). It is -intended for anybody who wants to learn about the background and concepts behind -Native Client, from browser technology fans, to pontential project contributors, -to NaCl module developers. - -### [TOC] - -### Chrome - -Chrome is a -[multi-process](http://www.chromium.org/developers/design-documents/multi-process-architecture) -browser. It uses multiple processes to provide increased security comparing to -other single-process browsers like Firefox. -The main process is called "browser". It runs the UI (including the -[Omnibox](/user-experience/omnibox)) and manages tabs and plugin processes. It -has full permissions of the current user for accessing resources (files, -network, etc) and can fork-exec other processes. -Tabs are allocated into separate processes, typically shared per domain. These -are called “renderer” processes. Renderer interprets the HTML layout and handles -the bitmap for displaying the page. It runs in a sandbox (known as Chrome or -outer sandbox) and has limited access permissions. It cannot open files or -network connections and can only respond to communication requests by the -browser. Communication is done via a combination of -[IPC](http://www.chromium.org/developers/design-documents/inter-process-communication) -techniques. Using sandboxed renderers ensures that if one tab misbehaves or -crashes, the rest of the tabs and the browser are isolated. It also limits the -ability of malicious software running in one tab from accessing activity in -another tab or interacting with the rest of the system. - -### Plugins - -[Plugins](http://en.wikipedia.org/wiki/Plug-in_%28computing%29) are external -binaries that add new capabilities to a web browser and are loaded when content -of the type they declare is embedded into a page. They either come bundled with -the browser or get downloaded and installed by the user. The most common plugins -are [Adobe Flash](http://en.wikipedia.org/wiki/Adobe_flash), [Adobe -Reader](http://en.wikipedia.org/wiki/Acrobat_reader) and -[Java](http://en.wikipedia.org/wiki/Java_plugin). -In general, existing plugins cannot be sandboxed like the render process because -they rely on file system and network access as well as use of native fonts. -Therefore, Chrome supports [out of process -plugins](http://www.chromium.org/developers/design-documents/plugin-architecture) -that run in a separate process with full privileges (i.e. no sandbox) and -communicate with the renderer and browser via -[IPC](http://www.chromium.org/developers/design-documents/inter-process-communication). -Chrome also supports [in process -plugins](http://www.chromium.org/developers/design-documents/plugin-architecture). -They run within a render process and can use faster direct access for -communication. They have also been used as an integration mechanism for adding -new statically linked functionality to the browser. - -### Netscape Plugin API (NPAPI) (No longer used by Native Client) - -[NPAPI](https://wiki.mozilla.org/NPAPI) is a common cross-browser plugin -framework used by plugins for exchanging data with the browser. It is -implemented by Chrome, Firefox and most other web browsers, excluding MS -Internet Explorer, which stopped supporting it in favor of -[ActiveX](http://en.wikipedia.org/wiki/ActiveX_control). -Contrary to other single-process browsers, Chrome -[supports](http://code.google.com/chrome/extensions/npapi.html) NPAPI plugins -out of process. -While this improves stability, security is still an issue - even in Chrome, -NPAPI plugins have full permissions of the current user to access resources and -fork-exec new processes. -Although NPAPI is intended to be platform independent, in reality it is not -fully so. NPAPI is a weak "standard", and every browser implements it somewhat -differently. Moreover, NPAPI plugins end up relying on OS and browser specifics -for certain capabilities, such as 2D or 3D graphics events. Even keyboard and -mouse events typically use the native OS implementation. It can also be -difficult to achieve similar rendering of the plugin area within a page across -different systems. - -### Pepper Plugin API (PPAPI) - -[Pepper](https://wiki.mozilla.org/NPAPI:Pepper) started at Google as a way to -address portability and performance issues with NPAPI, particularly for out of -process plugins. The initial focused efforts eventually expanded to include -capabilities such as generic 2D and 3D graphics and audio. -The first Pepper API designs were created to minimize the changes from legacy -NPAPI, hoping to ease adoption by browser vendors and plugin developers. This -design was implemented and is available to NaCl modules in Chrome 5. The Pepper -APIs were redesigned subsequent to the initial design, deviating more -substantially from legacy NPAPI while, hopefully, also improving the interfaces. -The [revised interfaces](http://code.google.com/p/ppapi/w/list) are sometimes -referred to as “PPAPI” or “Pepper2” and should be available in Chrome 6. - -Although traditional NPAPI plugins in Chrome run only out of process, Chrome 5 -supports Pepper plugins only in process. Being a somewhat experimental feature, -the only way to load trusted Pepper plugins is through the browser command-line -options. In the future, Pepper plugins will only be supported within Native -Client. - -### Native Client (NaCl) - -[Native Client ](http://code.google.com/p/nativeclient/)is a sandboxing -technology for safe execution of platform-independent untrusted native code in a -web browser. It allows real-time web applications that are compute-intensive -and/or interactive (e.g. games, media, large data analysis, visualizations) to -leverage the resources of a client's machine and avoid costly network access -while running in a secure environment with restricted access to the host. -[Native Client SDK](http://gonacl.com) is a software development kit for -creating Native Client executables (abbreviated as nexe) from scratch or from -the existing platform-specific web-based native applications. It consists of a -[GNU](http://en.wikipedia.org/wiki/GNU_Project)-based toolchain with customized -versions of [gcc](http://en.wikipedia.org/wiki/GNU_Compiler_Collection), -[binutils](http://en.wikipedia.org/wiki/Binutils) and -[gdb](http://en.wikipedia.org/wiki/Gdb) (32-bit x86 only), precompiled API -libraries and various examples and how-tos. The two usage models include porting -desktop apps and extending web apps with fast native code. -[Naclports](http://code.google.com/p/naclports/) is a collection of ports of -various open-sourced projects (like [zlib](http://en.wikipedia.org/wiki/zlib)) -to Native Client for gradual up-streaming. It is still in early stages of -development and is intended to be modeled after -[Macports](http://www.macports.org/). -NaCl started as a downloadable NPAPI plugin for multiple browsers, including -Firefox, Safari, Opera and Chrome and was designed to transparently load and run -other NPAPI plugins compiled as nexes and embedded into the page as a source -file of an [plugin -element](https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Plug-in_Basics#Using_HTML_to_Display_Plug-ins) -with “application/x-nacl-srpc” type. -NaCl includes a "service runtime" subsystem that provides a reduced system call -interface and resource abstractions to isolate nexes from the host. It provides -a [POSIX](http://en.wikipedia.org/wiki/Posix)-like environment for nexe -execution and is used by nexes to communicate with each other and the browser. -The nexes are run using a loader program, sel_ldr (secure -[ELF](http://en.wikipedia.org/wiki/Executable_and_Linkable_Format) loader), -which is launched as a separate process. The sel_ldr process communicates with -the NaCl plugin via [SRPC](/system/errors/NodeNotFound) over IMC \[citation -needed\]. -NaCl was [integrated](/system/errors/NodeNotFound) into Chrome 5 as an -in-process Pepper plugin. The NaCl modules that it runs can utilize the Pepper -API for browser interaction. Part of the integration was to add special support -to Chrome to allow sandboxed plugins to launch the sel_ldr process. NaCl can be -enabled in Chrome 5 and later with the --enable-nacl command-line flag at -browser start-up by developers who want to develop Native Client modules. From -Chrome 14 and onwards Native Client is on by default and can be used in [Chrome -Web Store](https://chrome.google.com/webstore) apps. For development purposes -Native Client is also available to [unpacked -extensions](http://code.google.com/chrome/extensions/getstarted.html). Once we -launch Portable Native Client (PNaCl) -([PDF](http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf)), we plan to -enable Native Client for web pages in general (i.e., not limited to Chrome Web -Store apps). - -### Trusted vs Untrusted - -In the presence of a sandbox environment, trusted code runs outside of the -sandbox and can perform privileged operations while untrusted code is prohibited -from doing so by the enclosing sandbox, which isolates potentially misbehaving -or malicious software from the rest of the system. -Within the scope of Native Client, whether code is untrusted or trusted depends -on whether it will run inside of a NaCl sandbox (regardless of any outer -sandbox). The code that implements the sandbox abstraction is trusted. The code -that the sandbox hosts is untrusted. Untrusted code is built using NaCl SDK or -any other compiler that outputs binaries that honor alignment and instruction -restrictions and can be validated by NaCl. NaCl will statically verify that -nexes do not attempt privileged operations and therefore do not need to be -trusted. -To summarize, the traditional NPAPI plugins running out of process and outside -of any sandbox are considered trusted. The in process Pepper plugins running -within the Chrome sandbox are trusted with respect to NaCl. And the out of -process plugins (that must run inside Native Client) are untrusted. NaCl's -sel_ldr process is trusted and can do Chrome sandbox system calls on behalf of -the untrusted nexes running within it. - -### Diagram - -![](/nativeclient/getting-started/getting-started-background-and-basics/nacl_diagram.png) - -### Related Documentation - -Chrome - -<http://www.chromium.org/developers/design-documents/multi-process-architecture> - -<http://www.chromium.org/developers/design-documents/inter-process-communication> - -<http://www.chromium.org/developers/design-documents/plugin-architecture> - -<http://code.google.com/chrome/extensions/npapi.html> - -Plugins - -<https://developer.mozilla.org/en/Plugins> - -<https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Scripting_plugins> - -<https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Plug-in_Basics> - -<https://wiki.mozilla.org/NPAPI> - -<https://wiki.mozilla.org/NPAPI:Pepper> - -NaCl - -<http://code.google.com/p/nativeclient/wiki/Papers> - -<http://code.google.com/p/nativeclient/> - -==<http://GoNaCl.com>== - -<http://code.google.com/p/naclports/> - -<http://www.chromium.org/nativeclient/simple-rpc> - -[Native Client integration with Chrome](/system/errors/NodeNotFound) - -### Articles and Blog Posts - -*Important: this section is kept for historic purposes, but is no longer being -updated. For news and announcements see the SDK site at -[GoNaCl.com](http://GoNaCl.com) and the [announcements -list](https://groups.google.com/group/native-client-announce).* - -Google - -12/08 -<http://googlecode.blogspot.com/2008/12/native-client-technology-for-running.html> - -12/08 -<http://googleonlinesecurity.blogspot.com/2008/12/native-client-technology-for-running.html> - -Other - -01/09 -<http://blog.taragana.com/index.php/archive/google-native-client-a-detailed-discussion/> - -06/09 <http://lwn.net/Articles/335974/> - -03/10 -<http://arstechnica.com/.../google-bakes-flash-into-chrome-hopes-to-improve-plugin-api.ars> - -04/10 <http://news.cnet.com/8301-30685_3-20003527-264.html> |