Recommended reading that provides the background for this document:

• The high-level architecture of Chromium

• Chromium plugin architecture

• The Security Architecture of the Chromium Browser

Main goals:

• Performance - turn Native Client into a built-in plugin in Chrome so it'll run inside the renderer process

• Security - adapt Native Client code (both the plugin and the service runtime) for running inside Chrome sandbox

• Reuse Chrome infrastructure:

• Rely on Chrome for distribution, auto-updates, crash-reporting etc.

• Use ChromeFrame to provide NaCl capabilities to IE users.

Description

1. Unlike other Chrome plugins that run as separate processes, Native Client will run inside the renderer process as a built-in plugin. This design has the following advantages:

• It eliminates the need in inter-process communication between the renderer and the NaCl plugin code, thus improving the performance.

• The NaCl plugin code now runs in the sandbox (other plugins are usually not sandboxed).

2. The NaCl plugin is a windowless plugin and will rely on Pepper for video and audio capabilities.

• NaCl modules will have access to Pepper API (over SRPC)

3. The NaCl loader process (aka sel_ldr) in Chrome:

• Native Client modules are loaded and executed by a separate process. The separation is required for fault isolation - an exception caused by untrusted code on x86 platform causes the process to be killed.

• NaCl processes run in the Chrome sandbox, which adds another layer of security. This is usually referred to as "outer sandbox" in NaCl documents.

• Currently only one NaCl module can run in each NaCl loader process. We will consider changing this in the future.

• The NaCl loader process is yet another Chrome process and it is based on the sel_ldr code.

• As any other Chrome process, the NaCl loader process is launched by the browser process and establishes a Chrome IPC communication channel to the browser process during startup.

• NaCl process communicates with the NaCl plugin (running in the renderer process) using IMC.

Changes made during the integration:

• Create gyp files for Native Client

• Native Client plugin for Chrome is built as a static library and linked into chrome.dll

• Native Client plugin cannot launch the sel_ldr process directly since it's now running in the sandbox, therefore it is done by sending a message to the browser process.

• Native Client modules cannot be saved as files since both the plugin and the sel_ldr process run in the sandbox and cannot access the file system. The binary is downloaded into a memory buffer by the plugin and then shared with the sel_ldr using shared memory.

• IMC used to call OpenProcess on Windows to duplicate handles between processes (in order to pass them between NaCl modules and the plugin). This call is not allowed by the sandbox, therefore a new handle passing protocol was implemented that caches handles to all NaCl processes started by each renderer.

• IMC on Windows used to use CryptoAPI to generate random pipe names. In order to make the code run inside the sandbox CryptoAPI was replaced with rand_s().

Notes:

• Since NaCl uses a different sandbox on 64-bit Windows, running NaCl in Chrome on Win64 required a more complicated design - see NaCl in Chrome on 64-bit Windows for details.