What is the role of wasm module?

[try-agaaain]

引入wasm模块，是因为可以通过现有的wasm工具链可以将各种语言编译为wasm字节码的形式吗？

我了解到wasm虚拟机运行在用户态，而bpf虚拟机运行在内核态。当使用wasm模块来运行bpf程序时，bpf程序是否依然被加载到内核调用的相关函数中？

在本项目中，wasm模块的作用是什么？

[yunwei37]

https://mp.weixin.qq.com/s/OhcBWvXIIrPWw1fzVWXJRA

也许可以参考这篇文章? 主要是有这些想法:

可移植：让 eBPF 工具和应用完全平台无关、可移植，不需要进行重新编译即可以跨平台分发。

隔离性：借助 WASM 的可靠性和隔离性，让 eBPF 程序的加载和执行、以及用户态的数据处理流程更加安全可靠；事实上一个 eBPF 应用的用户态控制代码通常远远多于内核态。

包管理：借助 WASM 的生态和工具链，完成 eBPF 程序或工具的分发、管理、加载等工作，目前 eBPF 程序或工具生态可能缺乏一个通用的包管理或插件管理系统。

跨语言：目前 eBPF 程序由多种用户态语言开发（如 Go++等），超过 30 种编程语言可以被编译成 WebAssembly 模块，允许各种背景的开发人员（C、Go、Rust、Java、TypeScript 等）用他们选择的语言编写 eBPF 的用户态程序，而不需要学习新的语言。

敏捷性：对于大型的 eBPF 应用程序，可以使用 WASM 作为插件扩展平台：扩展程序可以在运行时直接从控制平面交付和重新加载。这不仅意味着每个人都可以使用官方和未经修改的应用程序来加载自定义扩展，而且任何 eBPF 程序的错误修复和/或更新都可以在运行时推送和/或测试，而不需要更新和/或重新部署一个新的二进制。

轻量级：WebAssembly 微服务消耗 1% 的资源，与 Linux 容器应用相比，冷启动的时间是 1%：我们也许可以借此实现 eBPF as a service，让 eBPF 程序的加载和执行变得更加轻量级、快速、简便易行。

[try-agaaain]

新春快乐~

上图是ebpf的处理过程图，加入wasm模块后，处理过程是不是这样的：

• step1：将bpf程序编译出字节码，嵌入到json文件或wasm文件中
• step2：wasm模块提取出json或wasm文件中的ebpf字节码，并加载到内核中，对应图中的第二步；
• step3：bpf字节码通过verifier加载到BPF虚拟机，并在虚拟机中运行对内核信息进行跟踪；
• step4：wasm模块获取BPF虚拟机获取的跟踪信息，对应图中的第三步；

其中step1通过ecc完成json文件的生成，或者通过wasm工具链生成wasm文件；

step2和step4是通过wasm模块完成，这两步是在用户态下的wasm虚拟机中完成的。

[yunwei37]

新年快乐!

没错，是这样的!

但其实这其中还是有一个很关键的问题，c 语言在 ebpf 里面编译后结构体的内存布局是和 用户态 host 环境一样的，而 wasm 的内存布局和 host 以及 ebpf 是不一样的，因此需要有一种序列化方案，来保证能正确地从内核态传递结构体信息到 wasm 里面，这部分是我们主要完成的工作。

目前使用 JSON 进行结构体的序列化，但是 JSON 可能略显低效，因此我们也在探索用什么样的序列化方案会更好一点。这些可能可以参考 wamr 的一些相关做法: https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/export_native_api.md

另外还有一个问题，我们需要有更多 wasm 和 ebpf 虚拟机的 map 进行通信的 api，不仅局限于 polling 的几个，还需要有 bpf_map_update，bpf_map_delete 之类的，目前还没有完全实现；另外这些之前的 wasm 和 ebpf 进行交互和数据处理的 api 也需要重新设计，参考 #99