翻译 并理解Native Client: A Sandbox for Portable, Untrusted x86 Native Code

可以参考 http://www.cnblogs.com/phinecos/archive/2008/12/12/1353816.html

摘要：
本文章主要描述 Native Client（一个运行跨平台、不可信x86平台代码的沙盒环境）的设计思想、实现原理以及相应评价。Native Client的目的，是让基于浏览器的APP，在不用牺牲安全性的前提下，有着与native app相同的性能。Native Client利用软件故障隔离技术和一个secure runtime来隔离直接的系统调用，所带来的副作用就是必须通过Native Client提供的接口来进行调用。Native Client提供二进制码的操作系统可移植性，支持一些在脱离Web app编程环境下性能类的特性，比如线程支持、指令集扩展比如SSE（Streaming SIMD Extensions，单指令多数据流扩展），同时可以使用编译器内联函数和手工编写的汇编程序（hand-coded assembler）。我们把这些特性结合到一个开源的架构上，这样可以鼓励community review以及第三方工具的出现。

1. 介绍

作为一个APP平台，现代的web浏览器汇集了一个很好的资源集合为了图像展现和用户交互，包括无缝访问因特网资源，高效的编程语言如JavaScript，以及丰富的Document Object Model (DOM) 。这些优势将浏览器放在被选择的前沿，作为新APP开发的目标平台，它在一个关键点上有缺陷：computational performance。感谢摩尔定律和硬件社区的热忱，尽管有上述障碍，许多有趣的应用在浏览器中仍然获得了足够多的性能。但是由于性能限制，对于基于浏览器的应用来说依旧有一些不可行的大计算。例如:  牛顿物理学的模拟，流体动力学的计算和高分辨率场景渲染。目前的环境趋向于排除利用大段的高效的代码除了JavaScript。

 现代Web浏览器提供了可扩展机制，比如ActiveX和NPAPI来运行本地代码可像web app一样被载入及运行。这些架构可能作为备选方案，他们允许plugins去绕过原本会应用于Web内容的安全机制，同时给了plugins全部的访问权限。鉴于这种组 织和缺失有效的技术来限制这些plugins，浏览器应用希望利用本地代码必须依赖非科技的措施来保证安全；比如，通过弹出框手动设置信任关系，或者手动 安装一个控制台应用。从历史看来，这些非技术性的措施已不足以抵挡恶意本地代码的执行，并导致了不方便和经济上的危害。因此我们相信对于基于 browser的应用的本地代码的扩展存在广泛的偏见。

 承认了当前的结合了native-code的web app系统的不安全性，我们也观察到没有一个实质性理由可以解释为什么native code是不安全的。在Native Client中，我们将安全的本地执行问题从被信任的扩展模块中分割出来，让各自独自管理。概念上，Native Client被分割成两块：一块是被限制的执行环境提供给native code，避免意外的影响，另一块是一个运行时，用来托管这些native code的扩展，通过这个，允许发生的side effects可能会产生的更少一点。

主要的工作如下：

1)  一个提供给 OS和 browser-portable 沙盒 x86字节模块 的基础设施

2)  支持一些先进的性能， 比如 threads、SSE架构、Compiler Intrinsics(固有的编译？)及硬编码汇编

3) 一个开发的系统，设计给简单的重定向和新的编译器及语言

4) CISC（Complex Instruction Set Computer）复杂指令系统计算机软件缺陷隔离技术的改良，利用x86的分割块来改善简化性和降低系统开销。

我们将这些特性结合在一个基础架构上，支持安全的副作用和本地通信。总的来说，Native Client提供了沙盒安全的native code的执行，以及操作系统间的可移植性，为浏览器提供了本地代码的性能。

本文的结构如下。1.1节描述了我们的模型。第 2章研究了一些NaCl系统架构的基本概念和编程模型。第3章介绍了一些额外的实现细节，主要是关于重要的系统组件。第4章提供了定量的系统评估，利用更 多现实的APP和APP组件。第5章，我们讨论这项工作的一些含义。第6章讨论相关先前的及当代的系统。第7章总结。

1.1 Threat Model

Native Client必须处理一些 来自任何站点的不被信任的模块，并要保证有比得上被接受的系统如JavaScript的安全性。当展现给系统时，一个不被信任的模块可能包含随意的代码和数据。所以NaCl runtime必须能够确认模块遵守我们的合法性规则（具体下面描述）。不遵守的模块会被系统拒绝执行。

一旦一个遵守规则的NaCl模块被接受执行 了，NaCl runtime必须限制他的行为，防止无意识的副作用，比如可能通过不加节制的访问，获得到native操作系统的系统调用接口。NaCl模块可能随意的 结合了整个多种多样的，被NaCl执行环境批准的行为，来试图损害系统。它可能会执行任何可获得的指示来阻碍生效的text segment(代码段)。它可能用尽方法来运用NaCl App的字节接口访问runtime services，比如传递非法参数等。它也可能通过我们的模块间的通信接口，来传递任意的数据，这个通信每次回应都会验证输入。NaCl模块也会根据资 源的限制来分配内存和spawn线程。它可能试图利用race condition来破坏系统。

我们在下面的文章里，表明了我们的架构和代码验证规则，在没有沙盒的情况下是怎么样限制NaCl模块的。

2. System Architecture

一个NaCl App由一组可信及不可信的模块组成。图一展示了一个假设的，基于NaCl的，用来管理和分享图片的App的架构。它包括了两个组件：一个用户接口，用JavaScript实现在web浏览器中执行，以及一个图片进程库（imglib.nexe）, 实现成一个NaCl模块。在这个假定的情景中，用户接口和图片进程库是这个app的一部分，因此是不可信任的。浏览器组件被浏览器执行环境所限制，图片进程库被NaCl容器所限制。这两个组件都是可以跨操作系统和浏览器，可移植的，native代码由Native Client提供移植性。在运行app之前，用户必须装上Native Client作为浏览器的插件。注意，NaCl browser plugin自身并不是跨平台的，它是和操作系统和浏览器有关的。再次注意，这个插件是被信任的，它有着访问OS系统调用接口的全部权限，用户为了不被伤害而信任它。

当用户访问到有这个图片App的网站时，浏览器加载并执行App的JS组件。JS依次调用NaCl浏览器插件，来加载图片进程库到NaCl容器中。注意到native code模块是静静的载入的，没有弹出框窗口询问批准。Native Client负责限制不被信任的模块的行为。

每个模块跑在它私有的地址块内。内部组件通信是基于Native Client的可靠的数据包服务， IMC(Inter-Module Communications). 浏览器和NaCl模块之间的通信，Native Client提供了两个选择：一个简单的RPC工具，以及NPAPI（Netscape Plugin Application Programming Interface）。两者都是基于IMC实现的。IMC同时也提供了共享内存块和共享同步体，试图来避免在高容量和高频率的通信下的消息的系统开销。

NaCl模块也可以访问“service runtime”接口，这个接口提供了内存管理操作，进程创建和其他系统服务。这个接口和一个常见的操作系统的系统调用接口很相似。

本文，我们利用“NaCl module”来描述不可信的native code。注意到，然而App可以用到多个NaCl module， 可信和不可信的组件都可以利用IMC。比如利用photo App的用户可以选择利用一个假设的可信任的NaCl service，做本地图片存储，如图2所示。因为它需要权限访问local disk, 这个存储service必须安装成一个native browser插件；它不可以被实现成NaCl module。假定这个photo app被设计成可用这个稳定的存储service；用户接口就会在初始化过程中，检查

这个plugin。如果它检测到storage service plugin， 用户接口就会为它建立一个IMC通信channel， 传递一个channel的描述给image库，使得image库和storage service可以直接通过基于IMC的service（SRPC【simple RPC】、共享内存等）通信。这样的话，NaCl module通常就会把提供访问storage service程序接口的库链接进来，这个过程屏蔽了IMC级别的通信细节，比如到底是用了SRPC还是共享内存的方法。注意，storage service必须假定image库是不可信的。storage service负责确保它唯一的服务请求，要和用户的默认约定保持一致。比如，它可能对图片App所用的整个磁盘实行限制，也可能进一步限制到只能操作一个特定的目录。

Native Client是一个很理想的架构用来提供给需要纯计算的APP组件。它并不适合以下需求的模块：创建进程、直接访问文件系统以及自由的访问网络。被信任的设备比如存储设备必须在Native Client之外实现，这样可以使得独立的模块更加简易和健壮，同时也可以加强各组件的隔离性和易观察性。该设计模仿了Microkernel 操作系统的设计。

由以上的例子，我们将要更加细致的描述NaCl系统的关键的设计部分。

2.1 The Inner Sandbox

Native Client 是建立在一个X86内部进程“inner sandbox" 之上的。我们虽然相信“the inner sandbox”是健壮的，无论如何，为了弥补深度的不足，我们也开发了第二个“outer sandbox",that mediates system calls at the process boundary. "outer sandbox" 大体上近似于之前的架构，所以我们将不会在这篇文章里讨论它。

内部沙盒利用静态分析来检测不被信任的x86代码中的安全问题。之前这种对于任意的x86代码进行的分析是被人们质疑的，因为self-modifying code和overlapping instructions。在Native Client中，我们通过一系列队列和结构上的规则禁止了这些，当然保证了native code可以被完全反编译，这样所以的指令在反编译的过程中可以被识别。将反编译作为工具，我们的验证器可以确保可执行文件只包含了合法指令的子集，禁止了不安全的机器码。

inner sandbox进一步利用了x86 分段存储(segmented memory)的方法来限制数据和指令的内存引用。促进目前的硬件去实现这些检查，就可以极大的简化需要限制内存引用的运行时检测，相应的也减少了安全机制的消耗。

inner sandbox用来创建一个包含一个native操作系统进程的安全的子域。有了这个，我们可以将一个trusted service runtime子系统放置在和untrusted app module相同的进程中， 同时有一个安全的trampoline/springboard 机制用来允许安全的从trusted到untrusted以及反向的转化。尽管有时候，一个process boundary可以有效的克制内存及系统调用的副作用，我们相信inner sandbox可以提供更多的安全性。我们通常认为操作系统不是完美无缺的，比如进程屏障可能有缺陷，更深一层，操作系统可能故意将共享库映射到所有进程的地址空间上，像Microsoft windows上发生的一样。事实上，我们的inner sandbox不仅仅从native module中隔离中系统，也从操作系统中隔离出了native module。

2.2. Runtime Facilities

沙盒是用来阻止有害的副作用的，但是有的副作用经常对native module有用的。对于进程中的通信，Native Client提供了一个可信的报文抽象，“Inter-Module Communications” service or IMC。IMC允许trusted和untrusted模块去收发报文，报文由隐式的字节数组以及可选的“NaCl 资源叙词”组成，可以增强跨越进程边界的文件的共享，内存共享以及通信信道等。IMC 

可以被可信和不可信的两种模块使用，并且它是两种更高级别的抽象基础。第一个是Simple Remote Procedure Call（SRPC），提供了方便的语法来定义和在NaCl boundaries用子程序？，包括从浏览器中的JS调用到NaCl的代码。第二个，NPAPI，提供一个被大家熟知的接口与浏览器 state 互动， 包括公开URLS和访问DOM，这都符合了已存在的为了内容安全限制。其中的任一个机制都可以被用来与常规的浏览器内容做交互，包括content修改、处理鼠标键盘事件以及获取额外的site content; 实质上，所有的一般性的资源对于JavaScript都是开放的。

综上所述，service runtime是负责提供container， NaCl modules可以通过它与其他module及浏览器进行交互。service runtime提供了一系列的system services, 且通常与一个应用程序的环境有关联。它提供了sysbark()、mmap()系统调用，基本物体去支持malloc()/free()接口及其他内存分配的抽象。它提供了 一个POSIX线程接口的子集，包括一些NaCl的扩展，线程的创建和销毁，条件变量，互斥器，管道和信号灯和本地线程存储。我们的线程技术已经完成的允许在Native Client上的Intel's Thread Building Blocks（TBB）。service runtime也提供了POSIX文件I/O接口，用来操作通信信道和基于web的只读内容。因为本地文件系统的名空间不可以被这些接口访问，所以本地的漏洞攻击是不可能的。

为了阻止非故意的网络访问，网络系统调用如connect() accept()之类的是被简单忽略的。NaCl模块可以通过JaveScript在浏览器中访问网络。这个的访问限制和其他JaveScript的一样，也不会对网络安全产生威胁。

NaCl开发环境很大程度上是基于Linux开源系统，这对于大多数的Linux/Unix开发者是很熟悉的。我们发现移植已有的Linux库是很干脆的，因为大多数的库都不需要做改变。

2.2. Attack Surface

总体来说，我们发现下列作为系统组件是有可能被攻击者所利用：

• inner sandbox: binary validation 二进制验证
• outer sandbox: OS system-call interception 操作系统调用拦截
• service runtime binary module loader 二进制模块加载
• service runtime trampoline interfaces 
• IMC communications interface 
• NPAPI interface