今天，我们宣布一项新的标准化工作——WASI，即 WebAssembly 系统接口。

为什么：开发人员开始将 WebAssembly 推出浏览器，因为它提供了一种快速、可扩展、安全的方式，可以在所有机器上运行相同的代码。

但我们还没有坚实的基础可以依靠。浏览器外部的代码需要一种与系统交互的方式——系统接口。而 WebAssembly 平台目前还没有。

什么：WebAssembly 是一种针对概念机器的汇编语言，而不是针对物理机器的汇编语言。这就是它可以在各种不同的机器架构上运行的原因。

正如 WebAssembly 是一种针对概念机器的汇编语言一样，WebAssembly 需要一个针对概念操作系统的系统接口，而不是任何单个操作系统。这样，它就可以在所有不同的操作系统上运行。

这就是 WASI 的作用——它是 WebAssembly 平台的系统接口。

我们的目标是创建一个系统接口，它将成为 WebAssembly 的真正伴侣，经得起时间的考验。这意味着要坚持 WebAssembly 的关键原则——可移植性和安全性。

谁：我们正在组建一个 WebAssembly 子组，专注于标准化 WASI。我们已经聚集了感兴趣的合作伙伴，并正在寻找更多合作伙伴加入。

以下是一些我们、我们的合作伙伴和支持者认为这很重要的原因。

Sean White，Mozilla 首席研发官

“WebAssembly 正在改变 Web 为人们带来新颖引人入胜的内容的方式，并赋能开发人员和创作者在 Web 上完成他们的最佳工作。到目前为止，这都是通过浏览器实现的，但有了 WASI，我们可以将 WebAssembly 和 Web 的优势带给更多用户、更多地点、更多设备以及更多体验。”

Tyler McMullen，Fastly 首席技术官

“我们将 WebAssembly 推出浏览器，作为在我们的边缘云中快速、安全地执行代码的平台。尽管我们的边缘和浏览器之间的环境存在差异，但 WASI 意味着 WebAssembly 开发人员无需将他们的代码移植到每个不同的平台。”

Myles Borins，Node 技术指导委员会主任

“WebAssembly 可以解决 Node 中最大的问题之一——如何获得接近本机的速度并重用用其他语言（如 C 和 C++）编写的代码，就像使用原生模块一样，同时保持可移植性和安全性。标准化此系统接口是迈向实现这一目标的第一步。”

Laurie Voss，npm 联合创始人

“npm 对 WebAssembly 的潜力感到非常兴奋，它可以扩展 npm 生态系统的功能，同时极大地简化在服务器端 JavaScript 应用程序中运行原生代码的过程。我们期待此过程的结果。”

所以，这就是重大新闻！🎉

目前有 3 种 WASI 实现。

• wasmtime，Mozilla 的 WebAssembly 运行时
• Lucet，Fastly 的 WebAssembly 运行时
• 一个浏览器 polyfill

您可以在此视频中看到 WASI 的实际应用。

如果您想详细了解我们关于此系统接口工作方式的建议，请继续阅读。

什么是系统接口？

许多人谈论像 C 这样的语言让你直接访问系统资源。但这并不完全正确。

这些语言没有直接访问权限来执行诸如在大多数系统上打开或创建文件之类的操作。为什么不呢？

因为这些系统资源——如文件、内存和网络连接——对于稳定性和安全性来说太重要了。

如果一个程序无意中弄乱了另一个程序的资源，那么它可能会使该程序崩溃。更糟糕的是，如果一个程序（或用户）故意弄乱了另一个程序的资源，它可能会窃取敏感数据。

因此，我们需要一种方法来控制哪些程序和用户可以访问哪些资源。人们很早就意识到了这一点，并想出了一个提供这种控制的方法：保护环安全。

使用保护环安全，操作系统基本上会在系统资源周围设置一个保护屏障。这就是内核。内核是唯一可以执行诸如创建新文件或打开文件或打开网络连接之类的操作的东西。

用户的程序在用户模式下运行，在内核外部。如果一个程序想做任何事情，比如打开一个文件，它必须请求内核为它打开文件。

这就是系统调用的概念的来源。当一个程序需要请求内核执行这些操作之一时，它会使用系统调用请求。这使内核有机会找出是谁发出的请求。然后，它可以查看该用户是否有权访问该文件，然后再打开它。

在大多数设备上，这是代码访问系统资源的唯一方式——通过系统调用。

操作系统使系统调用可用。但是，如果每个操作系统都有自己的系统调用，难道你不必为每个操作系统准备一个不同的代码版本吗？幸运的是，你不必。

这个问题是如何解决的？抽象。

大多数语言都提供一个标准库。在编码时，程序员不需要知道他们要针对哪个系统。他们只需要使用接口。

然后，在编译时，你的工具链会根据你所针对的系统选择要使用的接口实现。此实现使用来自操作系统 API 的函数，因此它是针对特定系统的。

这就是系统接口的来源。例如，printf 在 Windows 机器上编译时可以使用 Windows API 与机器交互。如果它在 Mac 或 Linux 上编译，它将使用 POSIX。

不过，这对 WebAssembly 来说是一个问题。

使用 WebAssembly，你甚至在编译时也不知道你正在针对哪种操作系统。因此，你无法在 WebAssembly 的标准库实现中使用任何单个操作系统的系统接口。

我之前谈过 WebAssembly 是 针对概念机器的汇编语言，而不是真实机器。同样，WebAssembly 需要一个针对概念操作系统的系统接口，而不是真实操作系统。

但是，即使没有这个系统接口，已经有一些运行时可以运行浏览器外部的 WebAssembly。它们是怎么做到的？让我们来看看。

WebAssembly 如何在今天在浏览器外部运行？

第一个用于生成 WebAssembly 的工具是 Emscripten。它在 Web 上模拟了一个特定的操作系统系统接口，POSIX。这意味着程序员可以使用来自 C 标准库 (libc) 的函数。

为了做到这一点，Emscripten 创建了自己的 libc 实现。此实现被分为两部分——一部分被编译到 WebAssembly 模块中，另一部分在 JS 粘合代码中实现。然后，此 JS 粘合代码会调用浏览器，然后浏览器会与操作系统进行交互。

大多数早期的 WebAssembly 代码都是使用 Emscripten 编译的。因此，当人们开始想要在没有浏览器的情况下运行 WebAssembly 时，他们首先开始让 Emscripten 编译的代码运行。

因此，这些运行时需要为所有这些存在于 JS 粘合代码中的函数创建自己的实现。

不过，这里有一个问题。这个 JS 粘合代码提供的接口并不是为了成为标准，甚至不是面向公众的接口。它没有解决这个问题。

例如，对于一个在面向公众的 API 中称为 read 的函数，JS 粘合代码改为使用 _system3(which, varargs)。

第一个参数 which 是一个整数，它始终与名称中的数字相同（在本例中为 3）。

第二个参数 varargs 是要使用的参数。它被称为 varargs，因为你可以传递数量可变的参数。但是，WebAssembly 没有提供将数量可变的参数传递给函数的方法。因此，参数是通过线性内存传递的。这不是类型安全的，而且比使用寄存器传递参数更慢。

对于在浏览器中运行的 Emscripten 来说，这很好。但现在，运行时将其视为事实上的标准，实现自己的 JS 粘合代码版本。它们正在模拟 POSIX 模拟层的内部细节。

这意味着它们正在重新实现一些选择（例如，将参数作为堆值传递），这些选择在 Emscripten 的约束条件下是合理的，即使这些约束条件在其环境中并不适用。

如果我们要构建一个持续数十年之久的 WebAssembly 生态系统，我们需要坚实的基础。这意味着我们不能将事实上的标准作为模拟的模拟。

但我们应该应用哪些原则？

WebAssembly 系统接口需要坚持哪些原则？

WebAssembly 中包含了两个重要的原则

• 可移植性
• 安全性

当我们迁移到浏览器外部用例时，我们需要保持这些关键原则。

实际上，POSIX 和 Unix 的访问控制安全方法并没有完全满足我们的要求。让我们看看它们有哪些不足之处。

可移植性

POSIX 提供源代码可移植性。你可以在 libc 的不同版本上编译相同的源代码以针对不同的机器。

但 WebAssembly 需要超越这一步。我们需要能够编译一次，并在许多不同的机器上运行。我们需要可移植的二进制文件。

这种可移植性使代码分发给用户变得更加容易。

例如，如果 Node 的原生模块是用 WebAssembly 编写的，那么用户在安装带有原生模块的应用程序时就不需要运行 node-gyp，开发人员也不需要配置和分发几十个二进制文件。

安全性

当一行代码请求操作系统执行一些输入或输出操作时，操作系统需要确定是否可以安全地执行代码所请求的操作。

操作系统通常使用基于所有权和组的访问控制来处理这种情况。

例如，该程序可能会请求操作系统打开一个文件。用户有一组特定的文件可以访问。

当用户启动该程序时，该程序代表该用户运行。如果用户有权访问该文件——无论是因为他们拥有该文件，还是因为他们属于一个有权访问该文件的组——那么该程序也拥有相同的访问权限。

这可以保护用户免受彼此的侵害。当早期操作系统开发时，这很有意义。系统通常是多用户系统，管理员控制安装什么软件。因此，最主要的威胁是其他用户偷看你的文件。

情况发生了变化。现在系统通常是单用户系统，但它们运行的代码会引入大量来自第三方且信任度未知的代码。现在最大的威胁是，你自己运行的代码会反过来攻击你。

例如，假设你在应用程序中使用的库有了新的维护者（这种情况在开源项目中很常见）。这位维护者可能真心实意地为你的利益着想…… 也可能是一个坏人。如果他们有权访问你的系统上的任何东西——例如，打开你的任何文件并将其发送到网络——那么他们的代码就可以造成很大的破坏。

这就是为什么使用能够直接与系统通信的第三方库存在风险的原因。

WebAssembly 的安全机制有所不同。WebAssembly 是沙盒化的。

这意味着代码不能直接与操作系统通信。但它如何使用系统资源呢？宿主（可能是浏览器，也可能是一个 Wasm 运行时）会在沙盒中放置一些代码可以使用的函数。

这意味着宿主可以根据程序限制程序在系统上的操作权限。它不会让程序代表用户执行任何操作，也不会以用户的全部权限调用任何系统调用。

仅仅拥有沙盒机制并不能保证系统本身的安全——宿主仍然可以将所有功能放入沙盒中，在这种情况下，我们并没有得到任何改善——但它至少给了宿主创建更安全系统的选择。

在设计任何系统接口时，我们都需要坚持这两个原则。可移植性使软件开发和分发变得更容易，而为宿主提供保护自身或其用户的工具是绝对必要的。

这个系统接口应该是什么样的？

鉴于这两个关键原则，WebAssembly 系统接口的设计应该是什么样的？

我们将通过标准化过程来弄清楚这个问题。不过，我们确实有一个可以作为开端的提议。

• 创建一个模块化的标准接口集。
• 首先标准化最基础的模块，wasi-core。

wasi-core 中会包含什么？

wasi-core 将包含所有程序都需要的一些基本内容。它将涵盖与 POSIX 大致相同的内容，包括文件、网络连接、时钟和随机数等。

它还会对其中许多内容采用与 POSIX 非常相似的做法。例如，它将使用 POSIX 的面向文件的方案，其中包含 open、close、read 和 write 等系统调用，其他一切基本都是在此基础上进行扩展。

但 wasi-core 不会涵盖 POSIX 的所有内容。例如，进程的概念不能清晰地映射到 WebAssembly。除此之外，说每个 WebAssembly 引擎都需要支持 fork 等进程操作也没有意义。但我们也希望能够标准化 fork。

这就是模块化方法的用武之地。通过这种方式，我们可以获得良好的标准化覆盖范围，同时仍然允许利基平台仅使用对它们有意义的 WASI 部分。

像 Rust 这样的语言会直接在其标准库中使用 wasi-core。例如，Rust 的 open 在编译为 WebAssembly 时是通过调用 __wasi_path_open 实现的。

对于 C 和 C++，我们创建了一个 wasi-sysroot，它根据 wasi-core 函数实现 libc。

我们预计像 Clang 这样的编译器将能够与 WASI API 接口，而像 Rust 编译器和 Emscripten 这样的完整工具链将使用 WASI 作为其系统实现的一部分。

用户代码如何调用这些 WASI 函数？

运行代码的运行时将 wasi-core 函数作为导入传递进来。

这带来了可移植性，因为每个宿主都可以拥有自己的 wasi-core 实现，该实现专门针对其平台编写——从 Mozilla 的 wasmtime 和 Fastly 的 Lucet 等 WebAssembly 运行时，到 Node，甚至浏览器。

它还带来了沙盒化，因为宿主可以选择要传递进来的 wasi-core 函数——即，允许使用哪些系统调用——并且可以根据程序进行操作。这样就保留了安全性。

WASI 为我们提供了一种将这种安全性进一步扩展的方法。它引入了更多来自基于能力的安全性的概念。

传统上，如果代码需要打开文件，它会调用 open，并传入一个字符串，即路径名。然后操作系统会检查代码是否有权限（根据启动程序的用户）。

在 WASI 中，如果你调用需要访问文件的函数，则必须传入一个文件描述符，该文件描述符附带权限。这可以是文件本身的权限，也可以是包含文件的目录的权限。

这样，代码就不能随意要求打开 /etc/passwd。相反，代码只能操作传入的目录。

这使得我们可以安全地为沙盒化代码提供对更多不同系统调用的访问权限——因为这些系统调用的功能可以被限制。

这在模块级别进行。默认情况下，模块无法访问任何文件描述符。但如果一个模块中的代码拥有一个文件描述符，它可以选择将该文件描述符传递给它在其他模块中调用的函数。或者它可以创建文件描述符的更受限版本并传递给其他函数。

因此，运行时将应用程序可以使用文件描述符传递给顶层代码，然后文件描述符根据需要在系统其余部分传播。

这使 WebAssembly 更加接近最小特权原则，即模块只能访问完成其工作所需的资源。

这些概念来自基于能力的系统，如 CloudABI 和 Capsicum。基于能力的系统的一个问题是，将代码移植到它们中通常很困难。但我们认为这个问题可以解决。

如果代码已经使用 openat 和相对文件路径，那么编译代码将直接生效。

如果代码使用 open，而迁移到 openat 风格的成本太高，那么 WASI 可以提供一种渐进式解决方案。使用 libpreopen，你可以创建一个应用程序合法需要访问的文件路径列表。然后，你可以使用 open，但只能使用这些路径。

接下来是什么？

我们认为 wasi-core 是一个良好的开端。它保留了 WebAssembly 的可移植性和安全性，为生态系统提供了坚实的基础。

但还有其他一些问题，我们需要在 wasi-core 完全标准化后解决。这些问题包括：

• 异步 I/O
• 文件监控
• 文件锁定

这仅仅是开始，所以如果你对如何解决这些问题有任何想法，请 加入我们！