牧云插件系统技术选型之WASM运行时选哪个？不选这个竟然出大问题！

本文将讨论基于WASM 的牧云插件系统开发中WASM 运行时的选择。我们将比较不同WASM 运行时在性能、安全性、易用性等方面的优缺点，并解释我们最终选择的原因以及哪种WASM 运行时。 \r

\r

这是《**Host Agent插件引擎开发故事**》系列文章的第八篇，以后会持续更新。本系列文章将带领您深入了解长汀牧云团队的主机Agent插件引擎的开发过程。内容涵盖了技术选型、插件接口设计、组件通信框架等多个方面，并详细讲解了其背后的原理和实现方法。无论您是网络安全专业人士，还是对技术开发感兴趣的读者，您都可以从中有所收获。我们希望通过分享开发过程中面临的挑战、解决方案和实践经验，提供深入的见解和有价值的技术参考，帮助读者了解如何构建高效可靠的安全产品，共同推动安全技术社区的发展。 \r

\r

## 简介\r

\r

在上一篇文章中，我们逐步确定了插件系统的技术选型、探针的技术选型、插件的技术选型、通信框架的设计、序列化方法的选择等，下一步就是选择WebAssembly运行时。 \r

\r

在本文中，我们将详细讨论与WebAssembly 运行时相关的问题。首先，我们将解释WebAssembly 运行时需要做什么以及需要做什么类型的工作。然后我们将一般性地讨论作为主机安全的Agent引擎的相关工作。我们有什么样的期望，最后一一分析社区中流行的选择。 \r

\r

## 什么是WebAssembly 运行时\r

\r

从最简单的角度来看，WebAssembly 运行时实际上充当了一个操作系统，负责加载并执行由WebAssembly 字节码组成的程序，并管理程序执行过程中涉及的文件、网络、内存等资源。 \r

\r

扩展一下，加载过程涉及到导入导出符号的解析和映射，需要加载器；执行过程涉及解释或编译执行的步骤，需要执行器。执行过程中需要申请内存，因此需要内存管理器。在执行过程中，还需要访问文件和网络，因此需要一个桥来帮助提供和隔离对相关资源的访问。在多个WebAssembly程序执行过程中，需要管理何时执行哪个程序，因此需要调度器。 \r

\r

\r

\r

在文章[《创新之路》](https://stack.chaitin.com/techblog/detail?id=72)中，我们提出了“安全业务能力和基础安全能力分离”的原则，指导解决方案在主机Agent引擎中实现灵活性和鲁棒性之间的平衡。这一原则再次发挥作用。 \r

\r

回顾[上一篇文章](https://stack.chaitin.com/techblog/detail?id=72)，使用这个原则做出的第一个重大决定是我们需要一个插件系统。在本系统中，Agent程序将提供基础安全能力，插件将提供安全业务能力。这里的插件是在WebAssembly运行时执行的，所以我们对运行时的要求就是满足插件的要求，即：实时、轻量、安全、兼容、稳定、跨平台、灵活、易用。虽然WebAssembly本身已经为我们提供了这里的大部分能力，但基于高效、轻量级和稳定性，我们肯定希望选择最高效、轻量级和稳定的。 \r

\r

## 流行的WebAssembly引擎分析\r

\r

目前（2023.6）社区最受欢迎且持续开发的项目包括：Wasmtime、Wasmer、WasmEdge、wasm3、WAMR、Deno、Bun 和Wasm2c。 \r

\r

我们将上述运行时分为四类进行讨论：解释执行、基于LLVM/Cranelift/V8、基线编译器等。 \r

\r

###解释与执行\r

\r

\r

\r

[wasm3](https://github.com/wasm3/wasm3)\r

这是他们当中唯一的翻译。其显着特点是广泛兼容各种指令集和多种编程语言。它已经通过了[WebAssembly 规范测试套件](https://github.com/WebAssembly/spec/tree/master/test/core)，并承诺较小的可执行文件大小和内存运行要求。在wasm3 的主页上，解释了为什么选择解释执行而不是其他更快的方法，答案是“很多情况下，速度并不是主要关心的问题，可执行文件大小、内存使用情况、启动延迟等都可以通过解释执行得到更好的解决”。好吧，虽然我们也关心内存使用等问题，但速度对我们来说确实很重要，而且其他资源并不像给出的示例中使用MCU 的嵌入式设备那么紧张。 \r

\r

### 基于LLVM/Cranelift/V8\r

\r

这三个类别被放在一起讨论，因为它们的效率性能和兼容性性能相似。 \r

\r

`Wasmtime`/`WasmEdge`/`Wasmer` 是三个最流行的运行时。它们都是通用运行时，但各自有不同的侧重点。 wasmtime的重点是高效（fast）和安全（secure）； WasmEdge 专注于为云原生和无服务器带来边缘计算（EdgeComputing）支持； Wasmer 的目标是提供一个通用的运行时。 \r

\r

#### Wasmtime\r

\r

\r

\r

[Wasmtime](https://github.com/bytecodealliance/wasmtime) 是字节码联盟的一个项目，字节码联盟是一个非营利组织，其目标是提供“最先进的细粒度沙箱、基于功能的安全性、模块化和标准化的基础设施”，愿景是“默认情况下对所有平台都是安全的WebAssembly 生态系统”。 \r

\r

从wasmtime项目的开发流程来看，它首先花费了大量的时间对许多提案进行标准化和公开讨论，并构建了从低级到高级的各个级别的工具和项目。当子项目逐渐成熟后，将整合到主仓库中。 \r

\r

从wasmtime的运作流程来看，它花费了大量的精力在提供供应链安全信息、模糊测试和漏洞公开披露上。与wasmtime相关的[CVE漏洞](https://www.opencve.io/cve?vendor=bytecodeallianceproduct=wasmtime)有很多，其中一些是非常严重的问题，甚至可能导致隐私泄露或任意代码执行，但这并不是一件坏事。事实上，wasmtime 是迄今为止唯一公开披露漏洞的WebAssembly 运行时。这些举动体现了字节码联盟对安全性的重视，也让我们对wasmtime的安全性充满信心。 \r

\r

一开始，wasmtime项目包含大量C++代码，因此对其安全性存在一些担忧。不过，随着Rust语言的发展，逐渐从用Nightly版本替换C++代码过渡到完全使用Rust 1.69编译的Stable版本。从4.0版本左右开始，进入了活跃、稳定的开发节奏，一些讨论已久的提案进入了接近成熟的状态。 \r

\r

如果你想在浏览器环境之外安全地运行插件代码，Wasmtime 感觉是最合适的选择。 \r

\r

#### 瓦斯默\r

\r

\r

\r

[Wasmer](https://github.com/wasmerio/wasmer) 由一家成立于2018 年10 月的独立初创公司控制。\r

\r

当时wasmtime 项目进入了一个相对沉寂的时期，因此Wasmer 的创始人觉得是时候接管领导权了。起初，两个小组共同开发了wasmtime。后来，当他们看到瓦斯默时间变慢时，他们建议一起搬到瓦斯默。然而，另一组人不同意（毕竟愿景不同），所以他们成立了自己的公司，目标不同。 \r

\r

两者的主要区别在于，Wasmer 专注于为尽可能多的CPU 架构、客户端环境和主机语言环境提供尽可能丰富的生态支持，而wasmtime 的目标仍然是最初的“快速、安全的最先进的基础”。因此，在技术选型上，Wasmer主要推荐使用LLVM作为后端进行编译，而wasmtime则专注于开发自己的cranelift编译器。 \r

\r

Cranelift 和LLVM 在某种程度上非常相似。它们都旨在提供语言中立和平台中立的IR。不同的是，cranelift实际上只提供了WASM字节码到机器码的生成，不同语言到WASM字节码的生成是由每种语言以自己的方式解决的。这提供了实现WebAssembly 一些有针对性的优化的机会。 \r

\r

有趣的是，虽然wasmer非常坚决地分离独立开发，并以比wasmtime更快的速度和更广泛的支持作为宣传噱头，但wasmer实际上仍在积极采用wasmtime团队发明的cranelift、witx等工具。 \r

\r

经过不断的针对性优化，目前WebAssembly 领域的Cranelift 生成质量和效率与LLVM 几乎相同（甚至更快，尽管Wasmer 仍然声称至少快了50%）。我相信这种在专用领域自下而上的优化最终会有更广阔的前景。 \r

\r

`witx` 和配套项目`witx-bindgen` 在演化过程中逐渐放弃了对旧实验格式的支持，转而提供了标准化的新的、更好的wit 格式和新版本的`wit-bindgen`。由于过早采用“witx”并且缺乏“wit-bindgen”的持续支持，Wasmer 不得不分叉自己的[wai](https://github.com/wasmerio/wai) 格式并维护自己的Bindgen 工具。 \r

\r

总的来说，Wasmer 确实用自己的努力扩大了WebAssembly 社区的范围和影响力，这对于整个社区来说无疑是非常有利的，但还是有点太急躁了。 \r

\r

#### WasmEdge \r

\r

\r

\r

[WasmEdge](https://github.com/WasmEdge/WasmEdge) 是云原生计算基金会（CNCF，云原生计算基金会）的一个项目。自然，它从诞生之日起就一直服务于云原生场景。 \r

\r

在云原生场景中，WebAssembly的主要场景是Sidecar、Serverless和边缘计算，而在Serverless领域，基于WebAssembly的容器最受欢迎。前段时间，Docker支持运行基于WasmEdge运行时的WebAssembly容器的消息着实让相关领域的从业者兴奋不已。在Docker Desktop 的第二个相关技术预览版中，一次性添加了另外三个运行时，其中包括Wasmtime。 \r

\r

WasmEdge 的显着优势包括提供网络功能以及对“wasi-nn”和“wasi-crypto”的早期支持，这非常适合其定位。 \r

\r

\r

\r

#### WAMR \r

\r

[WAMR](https://github.com/bytecodealliance/wasm-micro-runtime) 是`WebAssembly Micro Runtime`，编译后的可执行文件名为`iWasm`。这是W3C Wasm 标准的最小可行产品(MVP)。它体积最小、速度最快、支持最成熟，但生态较差。从易用性和持续维护的角度来看，这不是我们想要选择的项目。 \r

\r

#### 德诺\r

\r

\r

\r

[Deno](https://deno.com/runtime)和[Node](https://nodejs.org)均采用V8引擎，直接继承了Chrome浏览器对WebAssembly的成熟支持，并拥有领先的WASI能力和目前唯一的WASM GC实现支持。但是，如果想要集成V8引擎，就必须集成整个V8引擎，这是一个非常庞大且复杂的依赖关系。如果您还需要JavaScript 支持，这是完全合理的，但对于您只需要WebAssembly 的情况来说，它太重量级了。 \r

\r

#### 面包\r

\r

\r

\r

[Bun](https://bun.sh/)是一个新兴的JavaScript执行引擎，基于JavaScriptCore（Safari的JS引擎），主要使用Zig语言实现。号称比Deno 更快，并且可以通过[wasmer-js](https://github.com/wasmerio/wasmer-js) 完美模拟WebAssembly 的WASI 特性。但不幸的是，JavaScriptCore 对WebAssembly 的支持不如对JavaScript 的支持。尤其是wasmer-js在兼容层的性能也很差，因此不会是当前理想的选择。 \r

\r

#### wasm2c\r

\r

[wasm2c](https://github.com/WebAssembly/wabt/tree/main/wasm2c) 是一个WASM 到C 的转换器，在这些运行时中绝对是一个异常值。其工作原理是将`*.wasm`文件翻译成`*.c`文件，然后使用zig语言提供的构建工具链进行编译。因此，它的运行速度无疑是最快的，但也是最不安全的。 \r

\r

## 结论\r

\r

回顾以上引擎的背景和特点，我们可以发现，虽然WebAssembly运行时看起来有很多选项，但每一个都有非常鲜明的特点，并不适合所有场景。 \r

\r

我们不想放弃速度，我们不想放弃安全，我们不想放弃易用性，我们不想沉重的负担，更重要的是我们要迎合未来的发展。如果考虑到WebAssembly Interface Type 和WebAssembly GC 的支持日益成熟，我认为主要值得担心的是选择Deno 还是Wasmtime。 Deno 没有接口类型，因此编写插件绑定将是一项繁琐的任务。 Wasmtime 还没有GC，无法高效执行更用户友好的语言。虽然预计Wasmtime 将在今年内提供GC 标准的实现，但预计任何其他运行时都不会添加对接口类型的支持。因此，在我们权衡之下，只有Wasmtime 成为最佳选择。 \r

\r

## 推荐相关博文\r

\r

上一篇：1. **[【牧云插件系统技术选型：大家都会抱怨的序列化方法选型争论]](https://stack.chaitin.com/techblog/detail?id=97)**\r

\r

系列文章目录：【【预览】主机Agent插件引擎开发故事总结】(https://stack.chaitin.com/techblog/detail?id=82)\r

\r

1. **[[揭秘牧云插件开发者的创新之路：从无法解决的问题到“充满乐趣”]](https://stack.chaitin.com/techblog/detail?id=72)**\r

2. **[【牧云插件系统面向未来的设计原则]](https://stack.chaitin.com/techblog/detail?id=73)**\r

3. **[【牧云插件系统选择之争]](https://stack.chaitin.com/techblog/detail?id=77)**\r

4. **【【牧云插件系统技术选型中探针开发用什么？ 】](https://stack.chaitin.com/techblog/detail?id=83)**\r

5. **【【牧云插件系统技术选型及插件开发？ 】](https://stack.chaitin.com/techblog/detail?id=85)**\r

6. **[【牧云插件系统技术选型插件通信框架大PK]](https://stack.chaitin.com/techblog/detail?id=94)**\r

7. **[【牧云插件系统技术选型：大家都会抱怨的序列化方法选择之争]](https://stack.chaitin.com/techblog/detail?id=97)**\r

8. **[【牧云插件系统技术选型：应该选择哪种WASM运行时？如果不选择这个，就会出大问题！ 】](https://stack.chaitin.com/techblog/detail?id=105)**