# Native Client: A Sandbox for Portable, Untrusted x86 Native Code

## Abstract

This is a review of *Native Client: A Sandbox for Portable, Untrusted x86 Native Code*.

## Overview of Paper

This paper describes the design, implementation and evaluation of Native Client, a sandbox for untrusted x86 native code. Native Client aims to give browser-based applications the computational performance of native applications with- out compromising safety. Native Client uses software fault isolation and a secure runtime to direct system interaction and side effects through interfaces managed by Native Client. Native Client 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 ex- tensions 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 3rd-party tools.

## Analysis

In this part, I will analyze this paper from following aspects: background, solved problem, contribution, what is proposed and how does it work, and performance.

### Background

In background, I'd like to talk the reason why did google introduce NaCl. Is it necessary for people to use NaCl?
As we know from the introduction, NaCl can help us run other untrusted code in C/C++ in web browser(Chrome) securely. There are few reasons for NaCl:
1. Better performance: C/C++ code runs much much faster than JS code.
2. Reuse legacy codes: people can reuse existing C/C++ modules to web browser.
3. Other languages: people can use C/C++ to program on the web browser, no need to learn JS.

### What is the problem solved?

As we know there are convincing reasons for people to use C/C++ code in the browser, then the problem is: How to execute C/C++ code safely in web browser?

Actually, before NaCl coming out, Microsoft also has some rules for that. One native way is to ask the user to choose whether they believe the code. However, in most cases people pay more attention to implementation rather than security. So it is obvious we cannot rely on users to prevent from being compromised. Microsoft introduced a kind of trusted origin execution, so the basic idea is that Microsoft will sign some codes they "believe" secure. It sounds good but it cannot solve the problem from root cause. Another solution is to trust OS isolation, but OS could also have memory bugs(even hardware bugs). So google proposed NaCl to help people to address this problem.

### What is the contribution of this paper including its novelty to related work?

This paper proposed an infrastructure for OS and browser-portable sandboxed x86 binary modules support for advanced performance capabilities such as threads, SSE instructions, compiler intrinsics and hand-coded assembler, an open system designed for easy retargeting of new compilers and languages, and refinements to CISC software fault isolation, using x86 segments for improved simplicity and reduced overhead.

### What is proposed? how does it work?

Native Client(NaCl) is proposed in this paper. Native Client enables the execution of native code securely inside web applications through the use of advanced Software Fault Isolation (SFI) techniques. Native Client allows you to harness a client machine’s computational power to a fuller extent than traditional web technologies. It does this by running compiled C and C++ code at near-native speeds, and exposing a CPU’s full capabilities, including SIMD vectors and multiple-core processing with shared memory.

The basic idea of NaCl is to implement software fault isolation. The plan is actually not to rely on the OS to check the code at the run time rather look ahead of time that this code is safe or not for the system. Check ahead of time the binaries of the instructions whether these are safe instructions or unsafe.

If instructions are SAFE(Do computations on its own little memory, meaning it can not access the disk, network etc), just allow them to pass:
* What are actually safe instructions ? ALU, some mathematic instructions, move etc
* Do computations on its own little memory, meaning it can not access the disk, network etc

If instructions are UNSAFE, either instrument the instruction or prohibit it.
* Instrumenting instruction means to introduce for example some checks before an access. By this we do not rely on the OS
* Unsafe instructions are actually memory accesses, instructions which could invoke a system call to switch privilege levels etc.

When we are done with checking, we can run the program and by definition it will not do bad things to our system.

**TRUSTED SERVICE RUNTIME**

Now the code within the sandbox is safe, it will run absolutely fine. It would not access the disk, will not access the browser, the display, will not access the network etc. instead it would just work on its own little chunk of resources allocated

Even if the code somehow, does not function in a safe way, a special service code has been provided by GOOGLE which is called Trusted Service Runtime.

TSR actually gives the final assurance that the code is now safe

When the code inside the sandbox wants to allocate memory, spawn threads, or communicate to the browser, etc. It actually sends a call to the TSR and TSR does all things for that code

**Constraints for NaCl binaries.**

* C1 Once loaded into the memory, the binary is not writable, enforced by OS-level protection mechanisms during execution.
* C2 The binary is statically linked at a start address of zero, with the first byte of text at 64K.
* C3 All indirect control transfers use a nacljmp pseudo- instruction (defined below).
* C4 The binary is padded up to the nearest page with at least one hlt instruction (0xf4).
* C5 The binary contains no instructions or pseudo-instructions overlapping a 32-byte boundary.
* C6 All valid instruction addresses are reachable by a fall- through disassembly that starts at the load (base) address.
* C7 All direct control transfers target valid instructions.

### Performance

Overall, the performance impact of Native Client on these benchmarks is on average less than 5%. At this level, overhead compares favorably to untrusted native execution.

## Critique of the Paper

### Strengths

This paper proposed a sandbox for develops to use C/C++ in browsers, which gives safety of any native third-party code.

This paper balanced the performance and robustness of Native Client. So it is deployable and widely used now.

This paper introduced trusted service runtime which gives the final protection for any dangerous behaviours.

The browser component is constrained by the browser execution environment and the image library is constrained by the NaCl container. Both components are portable across operating systems and browsers, with native code portability enabled by Native Client.

### Limitations:

Native Client modules only support 32-bit x86 executables at that time. The more recent 64-bit executable model was not supported.

Native Client cannot support hardware exceptions including hardware exceptions (segmentation faults, floating point exceptions) and external interrupts due in part to distinct and incompatible exception models in Linux, MacOS and Windows.

## Conclusion

This paper has described Native Client, a system for incorporating untrusted x86 native code into an application that runs in a web browser. In addition to creating a barrier against undesirable side effects, NaCl modules are portable both across operating systems and across web browsers, and supports performance-oriented features such as threading and vectorization instructions. We believe the NaCl inner sandbox is extremely robust; regardless we provide addi- tional redundant mechanisms to provide defense-in-depth.
In our experience we have found porting existing Linux/gcc code to Native Client is straightforward, and that the performance penalty for the sandbox is small, particularly in the compute-bound scenarios for which the system is designed.
By describing Native Client here and making it available as open source, we hope to encourage community scrutiny and contributions. We believe this feedback together with our continued diligence will enable us to create a system that achieves a superior level of safety than previous native code web technologies.