Native Client in Chrome on 64-bit Windows

The problem: Chrome runs as a 32-bit process on 64-bit Windows systems. Native Client inner sandbox on 64-bit Windows systems uses SFI and requires running the loader as a 64-bit process. Initial integration design: for a description how things work on 32-bit Windows, Linux and Mac see Native Client integration with Chrome Design proposal: Native Client loader (aka sel_ldr) will be a 64-bit executable. This executable will include: All the capabilities present in the standalone version of the loader Chromium sandbox code (for outer sandbox) IPC code (required for communicating with Chrome's browser process) a minimal subset of Chrome code to support the functionality mentioned above When a new NaCl module has to be loaded, instead of launching another instance of Chrome as the NaCl process (see the description of the current design), the browser process will launch a 64-bit sandbox broker process.  The broker process: The Chromium sandbox architecture requires 2 processes to participate: a client that runs in the sandbox and a broker that enforces the policy. The 2 processes must be both 32-bit or both 64-bit - the latter is required for our case. The task of the broker process is to launch the loader executable and enforce a static sandbox policy. We will use a single broker process that will launch loader processes as needed. The broker process will be managed by a singleton object of NaClBrokerService class The browser will send an IPC message to the broker whenever a NaCl loader has to be started (in the 32-bit design the browser process launches the loader processes directly) The broker process will be launched on demand - when the first NaCl module needs to be launched The broker will be terminated when there are no more loaders running The broker can also be used as "the babysitter" process to monitor and constrain real-time threads in NaCl processes. The broker process and the loader processes can be launched using the same executable, just as all Chrome processes are started by launching chrome.exe. We will refer to this executable as nacl64.exe Chrome code required for nacl.exe can be linked into a 64-bit version of chrome.dll, so if needed it can easily be used for 64-bit Chrome later. In order to limit the effect of this change on the size of Chrome download we will try to make this 64-bit version of chrome.dll as small as possible. Build integration: New Win64-specific targets will be added for libraries that are required for building nacl.exe chrome_nacl_win64 is the target that builds nacl64.exe - the 64-bit executable chrome_dll_nacl_win64 is the target that builds the 64-bit version of chrome.dll (a smaller version since it includes only a small subset of code). Since our plan is to have a single version of Chrome for Windows, 64-bit targets will be built as part of the usual Chrome Windows build.  To build Chrome that works on Win64 you need to build two targets: chrome and chrome_nacl_win64. The former does not depend on the latter in order to avoid breaking the build for developers who don't have 64-bit tools installed as part of their MSVS. Distribution: nacl64.exe and the 64-bit version of chrome.dll will have to be part of the distribution All 64-bit binaries will have to be updated by Chrome updates Pros The fastest option available Most of the changes are required also for building Chrome as 64-bit executable Cons: Will (at least temporary) create different implementations for NaCl in Chrome on different OS At least one more process present in the system - the sandbox broker Note on the difference between the design for 64-bit and 32-bit: There are two main differences: we cannot use 32-bit chrome.exe to run NaCl loader code on 64-bit Windows, therefore another binary is needed the browser process cannot function as the sandbox broker for 64-bit NaCl loader as it does for 32-bit NaCl loader - therefore a separate 64-bit broker process is necessary Changing the integration design for 32-bit Windows to match the design for 64-bit Windows has no benefits: There is no reason to create a 32-bit version of nacl.exe - all the necessary code can be linked into chrome.dll, avoiding duplication of many parts of Chrome code that would be present both in the full version of chrome.dll and the compacted version that would be used by nacl.exe Launching a separate broker process also on 32-bit Windows is easy (since the code can be part of chrome.dll), but it is not clear why this is better than using the browser process as the broker (.i.e. keeping the current implementation for 32-bit Windows) Ultimately, Chrome will have separate distributions for 32-bit and 64-bit Windows, allowing us to use the current integration design on all platforms. Other options Create 64-bit Chrome Pros: v8 may gain in performance Will have to do it in the future anyway Cons: Distribution issues: need to choose the right version to install Requires much more work to port all the code The plugins are still 32-bit libraries - will need a 32-bit executable to load them. Work required: Add 64-bit support to the sandbox (as in the separate 64-bit sel_ldr solution) Port all Chrome code Solve the installation issues Develop a 32-bit plugin loader Use 32-bit SFI for NaCl's inner sandbox. Pros: This will work with 32-bit Chrome Cons: 32-bit SFI may take more time Will have higher overhead - worse performance for Native Client Work required: Develop a design for x86-32 SFI w/o memory segments Develop the tool chain: compiler + validator