淺析Wasm-bpf架起Webassembly和eBPF內(nèi)核可編程的橋梁

Wasm 最初是以瀏覽器安全沙盒為目的開發(fā)的，發(fā)展到目前為止，WebAssembly 已經(jīng)成為一個用于云原生軟件組件的高性能、跨平臺和多語言軟件沙箱環(huán)境，Wasm 輕量級容器也非常適合作為下一代無服務(wù)器平臺運(yùn)行時。另一個令人興奮的趨勢是 eBPF 的興起，它使云原生開發(fā)人員能夠構(gòu)建安全的網(wǎng)絡(luò)、服務(wù)網(wǎng)格和多種可觀測性組件，并且它也在逐步滲透和深入到內(nèi)核的各個組件，提供更強(qiáng)大的內(nèi)核態(tài)可編程交互能力。

Wasm-bpf 是一個全新的開源項(xiàng)目[1]，它定義了一套 eBPF 相關(guān)系統(tǒng)接口的抽象，并提供了一套對應(yīng)的開發(fā)工具鏈、庫以及通用的 Wasm + eBPF 運(yùn)行時平臺實(shí)例，讓任意 Wasm 虛擬機(jī)或者 Wasm 輕量級容器中的應(yīng)用，有能力將使用場景下沉和拓展到內(nèi)核態(tài)，獲取內(nèi)核態(tài)和用戶態(tài)的幾乎所有數(shù)據(jù)，在網(wǎng)絡(luò)、安全等多個方面實(shí)現(xiàn)對整個操作系統(tǒng)層面的可編程控制，從而極大的拓展 WebAssembly 生態(tài)在非瀏覽器端的應(yīng)用場景。

基于 eBPF 的系統(tǒng)接口，為云原生 WebAssembly 帶來更多可能

Wasm & WASI

也許你也已經(jīng)看過 Solomon Hykes (Docker的創(chuàng)始人之一)這句話：

如果在2008年已經(jīng)有了 WASM + WASI，我們根本不需要創(chuàng)建 Docker。Wasm 就有這么重要。服務(wù)端的 WebAssembly 是計算的未來。

2022 年，WebAssembly（通?？s寫為 Wasm）成為了焦點(diǎn)：新的 Wasm 初創(chuàng)企業(yè)出現(xiàn)，老牌公司宣布支持 Wasm，Bytecode Alliance 發(fā)布了許多 Wasm 標(biāo)準(zhǔn)，Cloud Native Computing Foundation 舉辦了兩次 WasmDay 活動，而其中最大的 Wasm 用戶之一 Figma 被 Adobe 以驚人的 200 億美元的價格收購[2]。

Wasm 是一種二進(jìn)制格式。許多不同的語言都可以編譯為相同的格式，并且該二進(jìn)制格式可以在大量操作系統(tǒng)和體系結(jié)構(gòu)上運(yùn)行。Java 和 .NET 在這方面也很相似，但是 Wasm 有一個重要的區(qū)別：Wasm 運(yùn)行時不信任執(zhí)行的二進(jìn)制文件。Wasm 應(yīng)用程序被隔離在沙盒中，只能訪問用戶明確允許的資源（如文件或環(huán)境變量）。Wasm 還有許多其他理想的特性（例如非常出色的性能），但正是它的安全模型使 Wasm 在廣泛的環(huán)境中使用，從瀏覽器到邊緣和 IoT，甚至到云端[3]。

因?yàn)闊o法依賴瀏覽器中現(xiàn)有可用的 JavaScript 引擎接口，所以目前大多數(shù)在瀏覽器外運(yùn)行的 Wasm 輕量級容器需要使用 WASI（WebAssembly 系統(tǒng)接口）。這些運(yùn)行時允許 Wasm 應(yīng)用程序以與 POSIX 類似（但不完全相同）的方式與其 host 操作系統(tǒng)交互。

但是，相對于傳統(tǒng)的容器中可以使用幾乎所有的系統(tǒng)調(diào)用，目前 WASI 所能提供的系統(tǒng)資源非常有限，目前僅僅在文件系統(tǒng)、socket 網(wǎng)絡(luò)連接等方面提供了一些基本的支持，對于操作系統(tǒng)底層資源的訪問、控制和管理能力仍然存在大量空白，例如對 Wasm 模塊或者外部其他進(jìn)程的執(zhí)行資源限制與行為觀測，對網(wǎng)絡(luò)包的快速轉(zhuǎn)發(fā)和處理，甚至和 wasm 沙箱外的其他進(jìn)程進(jìn)行通信，訪問外設(shè)等，都沒有一個比較成熟的解決方案。這也使得大多數(shù)的 Wasm 輕量級容器在實(shí)際應(yīng)用中還是主要集中于純粹的計算密集型應(yīng)用，而在網(wǎng)絡(luò)、安全等方面，還是需要依賴于傳統(tǒng)的容器技術(shù)。

這也是我們希望建立 Wasm-bpf 項(xiàng)目的初衷：借助當(dāng)前內(nèi)核態(tài) eBPF 提供的系統(tǒng)接口以及和用戶態(tài)交互的能力，拓展整個 WASI 的生態(tài)藍(lán)圖，為 Wasm 應(yīng)用帶來更多可能的使用場景，同時也能在用戶態(tài)增強(qiáng) eBPF 程序的能力。

或者換句話說，類似于瀏覽器中運(yùn)行的 Wasm 程序，可以通過 JavaScript 引擎接口訪問瀏覽器提供的各種系統(tǒng)資源，Wasm-bpf 的方案就是借助 eBPF 虛擬機(jī)接口訪問操作系統(tǒng)的各類資源；得益于 eBPF 目前在 Linux 內(nèi)核甚至 Windows 等其他操作系統(tǒng)中的廣泛支持，以及不同內(nèi)核版本和架構(gòu)之間的可移植性，和內(nèi)核 BPF 驗(yàn)證引擎的可靠性，我們?nèi)匀豢梢栽谝欢ǔ潭壬媳ＷC應(yīng)用的可移植性和安全邊界。

Wasm-bpf：超輕量級 Wasm + eBPF 通用運(yùn)行時平臺

Wasm-bpf 項(xiàng)目已經(jīng)實(shí)現(xiàn)了內(nèi)核態(tài) eBPF 虛擬機(jī)和用戶態(tài)之間系統(tǒng)接口完整的抽象機(jī)制，并提供了對應(yīng)的工具鏈以將 eBPF 應(yīng)用編譯為 Wasm 模塊，幫助進(jìn)行內(nèi)核態(tài) eBPF 和用戶態(tài) Wasm 之間無序列化，共享內(nèi)存的高效雙向通信，并通過代碼生成技術(shù)，提供和其他用戶態(tài) eBPF 開發(fā)框架幾乎一致的、簡單便捷的開發(fā)體驗(yàn)。借助 Wasm 組件模型不斷完善的生態(tài)支持，我們也可以為 eBPF 社區(qū)帶來更多用戶態(tài)開發(fā)語言，不同語言實(shí)現(xiàn)的可觀測性、網(wǎng)絡(luò)等 eBPF 應(yīng)用和數(shù)據(jù)處理插件也可以被輕松集成、復(fù)用、統(tǒng)一管理。

在幾乎已經(jīng)成為 eBPF 用戶態(tài)事實(shí)上的 API 標(biāo)準(zhǔn)的 libbpf 庫，和 WAMR(wasm-micro-runtime) 之上，只需要 300+ 行代碼即可構(gòu)建完整的通用 Wasm-eBPF 運(yùn)行組件，并支持大多數(shù)的 eBPF 使用場景 -- 任何人用任何主流 Wasm 運(yùn)行時，或者任何 eBPF 用戶態(tài)庫，以及任何編程語言，都可以輕松添加對應(yīng)的虛擬機(jī)支持，并復(fù)用我們的工具鏈輕松實(shí)現(xiàn) Wasm-eBPF 程序的編寫和開發(fā)。

之前在 eunomia-bpf 項(xiàng)目中，已經(jīng)有一些將 eBPF 和 Wasm 結(jié)合的探索[4]，但它并不是為了 Wasm 原生應(yīng)用和輕量級容器的場景設(shè)計的，不符合 Wasm-eBPF 的通用編程模型，只是將 Wasm 作為數(shù)據(jù)處理插件，性能也較為低下。因此我們創(chuàng)建了一個新的開源倉庫，讓 Wasm-bpf 項(xiàng)目專注于利用 eBPF 增強(qiáng)和擴(kuò)展 WebAssembly 使用場景，并進(jìn)一步完善對應(yīng)的工具鏈和開發(fā)庫支持：https://github.com/eunomia-bpf/wasm-bpf 。反過來，一個通用的 Wasm-eBPF 開發(fā)框架，借助 Wasm 相關(guān)的生態(tài)也可以為 eBPF 相關(guān)社區(qū)在用戶態(tài)的進(jìn)一步深入拓展，提供更多的可能性。

eBPF：安全和有效地擴(kuò)展內(nèi)核

eBPF 是一項(xiàng)革命性的技術(shù)，起源于 Linux 內(nèi)核，可以在操作系統(tǒng)的內(nèi)核中運(yùn)行沙盒程序。它被用來安全和有效地擴(kuò)展內(nèi)核的功能，而不需要改變內(nèi)核的源代碼或加載內(nèi)核模塊。eBPF 通過允許在操作系統(tǒng)內(nèi)運(yùn)行沙盒程序，應(yīng)用程序開發(fā)人員可以在運(yùn)行時，可編程地向操作系統(tǒng)動態(tài)添加額外的功能。然后，操作系統(tǒng)保證安全和執(zhí)行效率，就像在即時編譯（JIT）編譯器和驗(yàn)證引擎的幫助下進(jìn)行本地編譯一樣。eBPF 程序在內(nèi)核版本之間是可移植的，并且可以自動更新，從而避免了工作負(fù)載中斷和節(jié)點(diǎn)重啟。

今天，eBPF被廣泛用于各類場景：在現(xiàn)代數(shù)據(jù)中心和云原生環(huán)境中，可以提供高性能的網(wǎng)絡(luò)包處理和負(fù)載均衡；以非常低的資源開銷，做到對多種細(xì)粒度指標(biāo)的可觀測性，幫助應(yīng)用程序開發(fā)人員跟蹤應(yīng)用程序，為性能故障排除提供洞察力；保障應(yīng)用程序和容器運(yùn)行時的安全執(zhí)行，等等。可能性是無窮的，而 eBPF 在操作系統(tǒng)內(nèi)核中所釋放的創(chuàng)新才剛剛開始[3]。

eBPF 的未來：內(nèi)核的 JavaScript 可編程接口

對于瀏覽器而言，JavaScript 的引入帶來的可編程性開啟了一場巨大的革命，使瀏覽器發(fā)展成為幾乎獨(dú)立的操作系統(tǒng)?，F(xiàn)在讓我們回到 eBPF：為了理解 eBPF 對 Linux 內(nèi)核的可編程性影響，對 Linux 內(nèi)核的結(jié)構(gòu)以及它如何與應(yīng)用程序和硬件進(jìn)行交互有一個高層次的理解是有幫助的[4]。

Linux 內(nèi)核的主要目的是抽象出硬件或虛擬硬件，并提供一個一致的API（系統(tǒng)調(diào)用），允許應(yīng)用程序運(yùn)行和共享資源。為了實(shí)現(xiàn)這個目的，我們維護(hù)了一系列子系統(tǒng)和層，以分配這些責(zé)任[5]。每個子系統(tǒng)通常允許某種程度的配置，以考慮到用戶的不同需求。如果不能配置所需的行為，就需要改變內(nèi)核，從歷史上看，改變內(nèi)核的行為，或者讓用戶編寫的程序能夠在內(nèi)核中運(yùn)行，就有兩種選擇:

實(shí)際上，兩種方案都不常用，前者成本太高，后者則幾乎沒有可移植性。

有了 eBPF，就有了一個新的選擇，可以重新編程 Linux 內(nèi)核的行為，而不需要改變內(nèi)核的源代碼或加載內(nèi)核模塊，同時保證在不同內(nèi)核版本之間一定程度上的行為一致性和兼容性、以及安全性[6]。為了實(shí)現(xiàn)這個目的，eBPF 程序也需要有一套對應(yīng)的 API，允許用戶定義的應(yīng)用程序運(yùn)行和共享資源 --- 換句話說，某種意義上講 eBPF 虛擬機(jī)也提供了一套類似于系統(tǒng)調(diào)用的機(jī)制，借助 eBPF 和用戶態(tài)通信的機(jī)制，Wasm 虛擬機(jī)和用戶態(tài)應(yīng)用也可以獲得這套“系統(tǒng)調(diào)用”的完整使用權(quán)，一方面能可編程地擴(kuò)展傳統(tǒng)的系統(tǒng)調(diào)用的能力，另一方面能在網(wǎng)絡(luò)、文件系統(tǒng)等許多層次實(shí)現(xiàn)更高效的可編程 IO 處理。

正如上圖所示，當(dāng)今的 Linux 內(nèi)核正在向一個新的內(nèi)核模型演化：用戶定義的應(yīng)用程序可以在內(nèi)核態(tài)和用戶態(tài)同時執(zhí)行，用戶態(tài)通過傳統(tǒng)的系統(tǒng)調(diào)用訪問系統(tǒng)資源，內(nèi)核態(tài)則通過 BPF Helper Calls 和系統(tǒng)的各個部分完成交互。值得注意的是，二者并不是競爭關(guān)系，它們的編程模型和有性能優(yōu)勢的場景完全不同，也不會完全替代對方。對 Wasm 和 Wasi 相關(guān)生態(tài)來說，情況也類似，專門設(shè)計的 wasi 接口需要經(jīng)歷一個漫長的標(biāo)準(zhǔn)化過程，但可能在特定場景能為用戶態(tài)應(yīng)用獲取更佳的性能和可移植性保證，而 eBPF 在保證沙箱本質(zhì)和可移植性的前提下，可以提供一個快速靈活的擴(kuò)展系統(tǒng)接口的方案。

目前的 eBPF 仍然處于早期階段，但是借助當(dāng)前 eBPF 提供的內(nèi)核接口和用戶態(tài)交互的能力，經(jīng)由 Wasm-bpf 的系統(tǒng)接口轉(zhuǎn)換，Wasm 虛擬機(jī)中的應(yīng)用已經(jīng)幾乎有能力獲取內(nèi)核以及用戶態(tài)任意一個函數(shù)調(diào)用的數(shù)據(jù)和返回值（kprobe，uprobe...）；以很低的代價收集和理解所有系統(tǒng)調(diào)用，并獲取所有網(wǎng)絡(luò)操作的數(shù)據(jù)包和套接字級別的數(shù)據(jù)（tracepoint，socket...）；在網(wǎng)絡(luò)包處理解決方案中添加額外的協(xié)議分析器，并輕松地編程任何轉(zhuǎn)發(fā)邏輯（XDP，TC...），以滿足不斷變化的需求，而無需離開Linux內(nèi)核的數(shù)據(jù)包處理環(huán)境。

不僅如此，eBPF 還有能力往用戶空間任意進(jìn)程的任意地址寫入數(shù)據(jù)（bpf_probe_write_user[7]），有限度地修改內(nèi)核函數(shù)的返回值（bpf_override_return[8]），甚至在內(nèi)核態(tài)直接執(zhí)行某些系統(tǒng)調(diào)用[9]；所幸的是，eBPF 在加載進(jìn)內(nèi)核之前對字節(jié)碼會進(jìn)行嚴(yán)格的安全檢查，確保沒有內(nèi)存越界等操作，同時，許多可能會擴(kuò)大攻擊面、帶來安全風(fēng)險的功能都是需要在編譯內(nèi)核時明確選擇啟用才能使用的；在 Wasm 虛擬機(jī)將字節(jié)碼加載進(jìn)內(nèi)核之前，也可以明確選擇啟用或者禁用某些 eBPF 功能，以確保沙箱的安全性。

所有的這些場景都不需要離開 Wasm 輕量級容器：不像傳統(tǒng)的使用 Wasm 作為數(shù)據(jù)處理或者控制插件的應(yīng)用中，這些步驟由 Wasm 虛擬機(jī)外的邏輯實(shí)現(xiàn)，現(xiàn)在可以在 Wasm 輕量級容器中實(shí)現(xiàn)對 eBPF 以及 eBPF 能訪問的幾乎所有系統(tǒng)資源，完整的控制和交互，甚至實(shí)時生成 eBPF 代碼改變內(nèi)核的行為邏輯，實(shí)現(xiàn)整個系統(tǒng)從用戶態(tài)擴(kuò)展到內(nèi)核態(tài)的可編程性。

Wasm 對 eBPF 的用戶態(tài)增強(qiáng)：組件模型

標(biāo)準(zhǔn)很少是一個生態(tài)系統(tǒng)中最令人興奮的部分。而且，隨著 “組件模型” 這樣的名字，激起興奮感確實(shí)是一項(xiàng)艱巨的任務(wù)。但是，在這個乏味的名字背后是 Wasm 為軟件世界帶來的最重要的創(chuàng)新。

組件模型描述了 Wasm 二進(jìn)制文件之間如何交互的方式。更具體地說，兩個組件可以告訴對方它們提供的服務(wù)以及需要履行的期望。然后，Wasm 模塊可以利用彼此的能力。這為軟件開發(fā)人員提供了一種新的建立應(yīng)用程序的方式。開發(fā)人員可以聲明應(yīng)用程序所需的組件（或者更抽象地說，應(yīng)用程序所需的功能），然后 Wasm 運(yùn)行時可以代表用戶組裝正確的組件集合。組件模型正在迅速成熟，已經(jīng)出現(xiàn)了參考實(shí)現(xiàn)。2023 年將是組件模型開始重新定義我們?nèi)绾尉帉戃浖囊荒闧10]。

借助 Wasm 的相關(guān)生態(tài)，尤其是基于 Wasm 的輕量級容器技術(shù)、組件模型，我們同樣也可以給 eBPF 的應(yīng)用賦予如下特性：

可移植：讓 eBPF 工具和應(yīng)用完全平臺無關(guān)、可移植，不需要進(jìn)行重新編譯即可以跨平臺分發(fā)；

隔離性：借助 Wasm 的可靠性和隔離性，讓 eBPF 程序的加載和執(zhí)行、以及用戶態(tài)的數(shù)據(jù)處理流程更加安全可靠；事實(shí)上一個 eBPF 應(yīng)用的用戶態(tài)控制代碼、數(shù)據(jù)處理代碼的部分通常遠(yuǎn)遠(yuǎn)多于內(nèi)核態(tài)；

包管理：借助 WASM 的生態(tài)和工具鏈，完成 eBPF 程序或工具的分發(fā)、管理、加載等工作，目前 eBPF 程序或工具生態(tài)也缺乏一個通用的包管理或插件管理系統(tǒng)；

跨語言：目前 eBPF 程序由多種用戶態(tài)語言開發(fā)（如 GoRustCC++Python 等），超過 30 種編程語言可以被編譯成 WebAssembly 模塊，可以允許各種背景的開發(fā)人員（C、Go、Rust、Java、TypeScript 等）用他們選擇的語言編寫 eBPF 的用戶態(tài)程序，而不需要學(xué)習(xí)新的語言，甚至我們可以將 Wasm 動態(tài)翻譯為 eBPF 程序，加載進(jìn)入內(nèi)核，或者在 Wasm 輕量級容器中直接生成 eBPF 字節(jié)碼；

敏捷性：對于大型的 eBPF 應(yīng)用程序，可以使用 WASM 作為插件擴(kuò)展平臺：擴(kuò)展程序可以在運(yùn)行時直接從控制平面交付和重新加載。這不僅意味著每個人都可以使用官方和未經(jīng)修改的應(yīng)用程序來加載自定義擴(kuò)展，而且任何 eBPF 程序的錯誤修復(fù)和/或更新都可以在運(yùn)行時推送和/或測試，而不需要更新和/或重新部署一個新的二進(jìn)制；對于可觀測性應(yīng)用來說，需要更新數(shù)據(jù)處理插件，也無需經(jīng)歷重新編譯部署整個應(yīng)用程序的過程；

輕量級：WebAssembly 微服務(wù)消耗 1% 的資源，與 Linux 容器應(yīng)用相比，冷啟動的時間是 1%；對于大量的小型 eBPF 程序需要快速部署和停止的場景，Wasm 的輕量級特性可以大大降低系統(tǒng)的資源開銷。

我們已經(jīng)在 LMP 項(xiàng)目的 eBPF Hub 中，有一些創(chuàng)建符合 OCI 標(biāo)準(zhǔn)的 Wasm-eBPF 應(yīng)用程序，并利用 ORAS 簡化擴(kuò)展 eBPF 應(yīng)用開發(fā)，分發(fā)、加載、運(yùn)行能力的嘗試[11]，以及基于 Wasm 同時使用多種不同語言開發(fā) eBPF 的用戶態(tài)數(shù)據(jù)處理插件的實(shí)踐，基于最新的 Wasm-bpf 框架，有更多的探索性工作可以繼續(xù)展開。

用戶空間和 eBPF 程序的交互流程

eBPF 程序是以函數(shù)為單位的、事件驅(qū)動的，當(dāng)內(nèi)核或用戶空間應(yīng)用程序通過某個 hook 點(diǎn)時就會運(yùn)行特定的 eBPF 程序。要使用一個 eBPF 程序，首先我們需要使用 clang/LLVM 工具鏈將對應(yīng)的源代碼編譯為 bpf 字節(jié)碼，其中包含對應(yīng)的數(shù)據(jù)結(jié)構(gòu)定義、maps 和 progs 定義，progs 即程序段，maps 可以用來存儲數(shù)據(jù)或者和用戶空間實(shí)現(xiàn)雙向通信。之后，我們可以借助用戶態(tài)的開發(fā)框架和加載框架，實(shí)現(xiàn)完整的 eBPF 應(yīng)用。

通常的用戶態(tài) eBPF 開發(fā)框架

對于一個完整的 eBPF 應(yīng)用，通常需要包含用戶態(tài)和內(nèi)核態(tài)兩部分：

用戶態(tài)程序需要通過一系列系統(tǒng)調(diào)用跟內(nèi)核進(jìn)行交互（主要是 bpf 系統(tǒng)調(diào)用），創(chuàng)建對應(yīng)的 map 以在內(nèi)核態(tài)保存數(shù)據(jù)或和用戶態(tài)通信，根據(jù)配置動態(tài)選擇加載不同的程序段，動態(tài)修改字節(jié)碼或配置 eBPF 程序的參數(shù)，將對應(yīng)的字節(jié)碼信息加載進(jìn)內(nèi)核，通過驗(yàn)證器確保安全性，并通過 maps 和內(nèi)核之間實(shí)現(xiàn)雙向通信，通過 ring buffer / perf buffer 之類的機(jī)制從內(nèi)核態(tài)向用戶態(tài)傳遞數(shù)據(jù)（或者反之）。

內(nèi)核態(tài)主要負(fù)責(zé)具體的計算邏輯與數(shù)據(jù)收集。

在用戶態(tài) Wasm-eBPF 系統(tǒng)接口之上定義的全新 eBPF 開發(fā)框架

這個項(xiàng)目本質(zhì)上可以說是希望把 Wasm 沙箱當(dāng)做在操作系統(tǒng)之上建立的另一個用戶態(tài)運(yùn)行空間，讓 Wasm 應(yīng)用在沙箱中實(shí)現(xiàn)和通常用戶態(tài)中運(yùn)行的 eBPF 應(yīng)用一樣的編程模型和執(zhí)行邏輯。Wasm-bpf 會需要一個在 host（沙箱外部）構(gòu)建的運(yùn)行時擴(kuò)展，以及一些在沙箱內(nèi)部被編譯為 Wasm 字節(jié)碼的運(yùn)行時庫來提供完整的支持。

wasm

要實(shí)現(xiàn)完備的開發(fā)模型，我們需要：

一個 Wasm 模塊可以對應(yīng)多個 eBPF 程序；

一個 eBPF 程序?qū)嵗部梢员欢鄠€ Wasm 模塊所共用；

可以將 eBPF 程序從 Wasm 沙箱中動態(tài)加載進(jìn)內(nèi)核、選擇所需的掛載點(diǎn)掛載、卸載，控制多個 eBPF 字節(jié)碼對象的完整生命周期，并支持大多數(shù)的 eBPF 程序類型；

可以通過多種類型的 Maps 和內(nèi)核雙向通信，支持大多數(shù)的 Maps 類型；

通過 ring buffer 和 perf event polling 從內(nèi)核態(tài)向用戶態(tài)高效發(fā)送信息（對于 ring buffer 來說，也可以反之）；

幾乎可以適配于所有的使用 eBPF 程序的應(yīng)用場景，并可以隨著內(nèi)核功能的添加不斷演化和擴(kuò)展，同時不需要變動 Wasm 虛擬機(jī)的系統(tǒng)接口。

這就是目前 Wasm-bpf 項(xiàng)目所做的工作。我們也提出了一個新的 WASI 的 Proposal: WASI-eBPF[12].

在 Wasm-bpf 項(xiàng)目中，所有 Wasm 和 eBPF 虛擬機(jī)之間的通信都無需經(jīng)過序列化、反序列化機(jī)制，通過工具鏈中代碼生成技術(shù)和 BTF（BPF 類型格式[13]）信息的支持，我們可以實(shí)現(xiàn)在 eBPF 和 Wasm 之間可能不同的結(jié)構(gòu)體內(nèi)存布局、不同的大小端機(jī)制、不同的指針寬度之間的正確通信，在運(yùn)行時幾乎不會引入任何額外的開銷；通過 eBPF Maps 通信的時候數(shù)據(jù)可以直接由內(nèi)核態(tài)復(fù)制到 Wasm 虛擬機(jī)的內(nèi)存中，避免多次拷貝帶來的額外損耗。同時，通過自動生成 skeleton （bpf 代碼框架）和類型定義的方式，用戶態(tài)程序的 eBPF-Wasm 開發(fā)體驗(yàn)也得到了非常大的改善。

得益于 libbpf 提供的 CO-RE（Compile-Once, Run Everywhere）技術(shù)，在不同內(nèi)核版本之間移植 eBPF 字節(jié)碼對象，也不需要引入額外的重新編譯流程，運(yùn)行時也沒有任何的 LLVM/Clang 依賴[14]。

通常，一個編譯好的 eBPF-Wasm 模塊只有大約 90Kb，在不到 100ms 內(nèi)即可以完成動態(tài)加載進(jìn)內(nèi)核并執(zhí)行的過程。我們也在倉庫中提供了幾個例子，分別對應(yīng)于可觀測、網(wǎng)絡(luò)、安全等多種場景。

感謝華南理工大學(xué)賴曉錚副教授、西安郵電大學(xué)陳莉君教授團(tuán)隊(duì)和達(dá)坦科技王璞、施繼成老師對 Wasm 和 eBPF 相結(jié)合的指導(dǎo)與幫助，在接下來的工作中，我們會和參加 2023 開源畢設(shè)之旅的同學(xué)們一同針對一些 Wasm-bpf 具體的應(yīng)用場景，進(jìn)行更深入的研究與探討，并在下一篇 blog 中給出更詳細(xì)的原理解析與性能分析，以及對應(yīng)的一些代碼示例。

Wasm-bpf 編譯工具鏈與運(yùn)行時模塊等目前由龍蜥社區(qū) eBPF 技術(shù)探索 SIG[15] 中孵化的 eunomia-bpf 開源社區(qū)[16]開發(fā)與維護(hù)，感謝中科院軟件所 PLCT 實(shí)驗(yàn)室對社區(qū)的大力支持和資助，感謝社區(qū)同伴們的貢獻(xiàn)。接下來，我們也會在對應(yīng)的 eBPF 和 Wasm 相關(guān)的工具鏈和運(yùn)行時方面，進(jìn)行更多的完善和探索，并積極向上游社區(qū)反饋和貢獻(xiàn)。

審核編輯：劉清