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.
- 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
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
- The broker process:
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.
will use a single broker process that will launch loader processes as
needed. The broker process will be managed by a singleton object of
- 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
- 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.
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
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
- 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
is the target that builds the 64-bit version of chrome.dll (a smaller
version since it includes only a small subset of code).
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.
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.
- 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
- The fastest option available
- Most of the changes are required also for building Chrome as 64-bit executable
- 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
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:
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
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.
- Create 64-bit Chrome
- v8 may gain in performance
- Will have to do it in the future anyway
- 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.
- This will work with 32-bit Chrome
- 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