Native Client: A Sandbox
for Portable, Untrusted x86
By Bennet Yee, David Sehr, Gregory Dardyk, J. Bradley Chen, Robert Muth, tavis ormandy, Shiki okasaka,
neha narula, and nicholas fullagar
Native Client is a sandbox for untrusted x86 native code.
It aims to give browser-based applications the computational performance of native applications without compromising safety. Native Client uses software fault isolation
and a secure runtime to direct system interaction and side
effects through interfaces it controls. It further provides
operating system portability for binary code while supporting performance-oriented features generally absent
from Web application programming environments, such
as thread support, instruction set extensions such as SSE,
and use of compiler intrinsics and hand-coded assembler.
We combine these properties in an open architecture that
encourages community review and third-party tools.
1. inTRoDuc Tion
As an application platform, the modern Web browser
brings together a remarkable combination of resources,
and the richness of the Document Object Model (DOM) for
graphics presentation and user interaction. While these
strengths put the browser in the forefront as a target for
new application development, it remains handicapped in
a critical dimension: computational performance. Thanks
to Moore’s Law and the zeal with which it is observed by the
hardware community, many interesting applications get
adequate performance in a browser despite this handicap.
But there remains a set of computations that are generally
infeasible for browser-based applications due to performance constraints, for example, simulation of Newtonian
physics, computational fluid-dynamics, and high-resolution scene rendering. The current environment also tends
to preclude the use of large bodies of high-quality code
Modern Web browsers provide extension mechanisms such as ActiveX7 and Netscape Plugin Application
Programming Interface (NPAPI)
19 allowing native code to
be loaded and run as part of a Web application. Such architectures allow plug-ins to circumvent the security mechanisms otherwise applied to Web content, while giving them
access to full native performance, perhaps as a secondary
consideration. Given this organization, and the absence of
effective technical measures to constrain these plug-ins,
browser applications that wish to use native code must rely
on nontechnical measures for security, for example, manual establishment of trust relationships through pop-up
dialog boxes or manual installation of a console application. Historically, these nontechnical measures have been
inadequate to prevent execution of malicious native code,
leading to inconvenience and economic harm.
3, 22 As a consequence we believe there is a prejudice against native
code extensions for browser-based applications among
experts and distrust among the larger population of computer users.
While acknowledging the insecurity of the current systems for incorporating native code into Web applications,
we also observe that there is no fundamental reason why
native code should be unsafe. In Native Client, we separate
the problem of safe native execution from that of extending trust, allowing each to be managed independently.
Conceptually, Native Client is organized in two parts: a
constrained execution environment for native code to prevent unintended side effects and a runtime for hosting
these native code extensions through which allowable side
effects may occur safely.
The main contributions of this work are
•;An;infrastructure;for;OS-;and;browser-portable;sand-boxed x86 binary modules
as threads, SSE instructions, compiler intrinsics, and
compilers and languages
• Refinements to CISC software fault isolation, using
x86 segments for improved simplicity and reduced
We combine these features in an infrastructure that supports safe side effects and local communication, while preventing arbitrary file system and network access. Overall,
Native Client provides sandboxed execution of native code
and portability across operating systems, delivering native
code performance for the browser.
The remainder of the paper is organized as follows.
A previous version of this paper was published in
Proceedings of the 2009 IEEE Symposium on Security and
Privacy, May 2009.