eBPF 為 Linux 內(nèi)核提供了可擴展性，使開發(fā)人員能夠?qū)?Linux 內(nèi)核進行編程，以便根據(jù)他們的業(yè)務(wù)需求快速構(gòu)建智能的或豐富的功能。

我們的 LMP（Linux Microscope） 項目^[1]^ 是為了充分挖掘 ebpf 的可能性而建立的，項目以構(gòu)建 eBPF 學(xué)習(xí)社區(qū)、成為 eBPF 工具集散地、孵化 eBPF 想法和項目為目標，正在大力建設(shè)中。之前我們在 LMP 其中的 eBPF 超市 中包含了大量由個人開發(fā)者編寫的 eBPF 工具，覆蓋了網(wǎng)絡(luò)、性能分析、安全等多種功能，我們正在嘗試把其中的一些程序遷移到 eBPF Hub，一些規(guī)范化的 eBPF 程序庫，可以隨時下載運行，或嵌入大型應(yīng)用程序中作為插件使用。

我們嘗試在 eBPF Hub 中，基于 eunomia-bpf 開發(fā)框架創(chuàng)建符合 OCI 標準的 WASM 和 eBPF 程序，并利用 ORAS 簡化擴展 LMP 的 eBPF 分發(fā)、加載、運行能力。

快速使用

如果您想快速開始 eBPF，可以使用我們開發(fā)的輕量級框架之上的命令行程序 lmp-cli。當使用腳本安裝好我們的框架之后，您只需要一條命令，無需任何編譯，即可體會到 eBPF 的強大之處：

如果您使用過 bcc 等 eBPF 開發(fā)工具，您一定會驚喜于 LMP 的便捷性。LMP 中包含了各種各樣的 eBPF 程序，這種便捷的運行，離不開我們基于的底層框架 eunomia-bpf，它完全實現(xiàn)了“一次編譯，處處運行”的 eBPF 跨平臺目標。在 eunomia-bpf 框架下，LMP 開發(fā)的 eBPF 應(yīng)用不僅可以適配任意架構(gòu)和不同內(nèi)核版本，而且還具有輕量級、良好的隔離性等優(yōu)點，可以作為插件到嵌入大型應(yīng)用之中。

eunomia-bpf：結(jié)合 eBPF 和 WASM 的輕量級開發(fā)框架

作為一個 eBPF 程序的輕量級開發(fā)加載框架，eunomia-bpf 基于 WASM 運行時和 BTF 技術(shù)，包含了一個用戶態(tài)動態(tài)加載框架/運行時庫，以及一個簡單的編譯 WASM 和 eBPF 字節(jié)碼的工具鏈容器。

Wasm 是為了一個可移植的目標而設(shè)計的，可作為 C/C+/RUST 等高級語言的編譯目標，使客戶端和服務(wù)器應(yīng)用程序能夠在 Web 上部署。目前已經(jīng)發(fā)展成為一個輕量級、高性能、跨平臺和多語種的軟件沙盒環(huán)境，被運用于云原生軟件組件。eunomia-bpf 將 eBPF 用戶態(tài)的所有控制和數(shù)據(jù)處理邏輯全部移到 WASM 虛擬機中，通過 WASM module 打包和分發(fā) eBPF 字節(jié)碼，同時在 WASM 虛擬機內(nèi)部控制整個 eBPF 程序的加載和執(zhí)行，將二者的優(yōu)勢結(jié)合了起來。

在 WASM 模塊中編寫 eBPF 代碼和通常熟悉的使用 libbpf 框架或 Coolbpf 開發(fā) eBPF 程序的方式是基本一樣的，WASM 的復(fù)雜性會被隱藏在 eunomia-bpf 的編譯工具鏈和運行時庫中，開發(fā)者可以專注于 eBPF 程序的開發(fā)和調(diào)試，不需要了解 WASM 的背景知識，也不需要擔(dān)心 WASM 的編譯環(huán)境配置。

大致來說，eunomia-bpf 在 WASM 運行時和用戶態(tài)的 libbpf 中間多加了一層抽象層，使得一次編譯、到處運行的 eBPF 代碼可以從 JSON 對象中加載動態(tài)。JSON 對象會在編譯時被包含在 WASM 模塊中，因此在運行時，我們可以通過解析 JSON 對象來獲取 eBPF 程序的信息，然后動態(tài)加載 eBPF 程序。通過 WASM module 打包和分發(fā) eBPF 字節(jié)碼，同時在 WASM 虛擬機內(nèi)部控制整個 eBPF 程序的加載和執(zhí)行，eunomia-bpf 就可以將二者的優(yōu)勢結(jié)合起來，讓任意 eBPF 程序能有如下特性：

• 可移植：讓 eBPF 工具和應(yīng)用不需要進行重新編譯即可以跨平臺分發(fā)，省去了復(fù)雜的交叉編譯流程;

• 隔離性：讓 eBPF 程序的加載和執(zhí)行、以及用戶態(tài)的數(shù)據(jù)處理流程更加安全可靠。

• 包管理：完成 eBPF 程序或工具的分發(fā)、管理、加載等工作。

• 敏捷性：使每個人都可以使用官方和未經(jīng)修改的應(yīng)用程序來加載自定義擴展，任何 eBPF 程序的錯誤修復(fù)和/或更新都可以在運行時推送和/或測試，而不需要更新和/或重新部署一個新的二進制。

• 輕量級：與 Linux 容器應(yīng)用相比，WASM 微服務(wù)冷啟動的時間是 1%，可以實現(xiàn) eBPF as a service，讓 eBPF 程序的加載和執(zhí)行變得更加輕量級、快速、簡便易行。

我們已經(jīng)測試了在 x86、ARM 等不同架構(gòu)不同內(nèi)核版本的 Linux 系統(tǒng)上，eunomia-bpf 框架都可以使用同一個預(yù)編譯 eBPF 程序二進制，從云端一行命令獲取到本地之后運行。之后 eunomia-bpf 還會添加 RISC-V 等更多架構(gòu)的支持。

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【891587639】整理了一些個人覺得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實戰(zhàn)項目及代碼)? ?

使用 lmp-cli 構(gòu)建一個 eBPF 項目

如果您是一個 eBPF 工具的使用者，您可以無需任何編譯流程，也不需要了解任何 eBPF 和 WASM 的相關(guān)知識，使用 就可以直接運行 LMP 倉庫的小程序，其中會調(diào)用命令從云端從庫中下載對應(yīng)的小程序。lmp run <name>``lmp pull <name>

如果您是一個 eBPF 程序的開發(fā)者，讓我們開始創(chuàng)建、編譯并運行一個簡單的程序。在這里，我們使用基簡單命令行工具 lmp-cli，概述如何從四個步驟開始構(gòu)建。

1. 準備你的環(huán)境

eBPF 本身是一種 Linux 內(nèi)核技術(shù)，因此任何實際的 BPF 程序都必須在 Linux 內(nèi)核中運行。我建議您從內(nèi)核 5.4 或更新的版本開始。從 SSH 終端，檢查內(nèi)核版本，并確認您已經(jīng)啟用了 CONFIG_DEBUG_INFO_BTF：

你會看到類似這樣的輸出：

安裝命令行工具 lmp-cli：

2. 創(chuàng)建項目的內(nèi)核部分

使用創(chuàng)建一個項目模板，來初始化你的內(nèi)核程序，快速地投入到代碼的編寫中：lmp init

成功創(chuàng)建項目后，您將看到如下類似的輸出：

它實際上創(chuàng)建了一個項目名對應(yīng)的文件夾，里面有這些文件：

內(nèi)核程序模板 bootstrap.bpf.c 中默認的跟蹤點為 和，用來跟蹤新程序的執(zhí)行和退出，這里不做修改。tp/sched/sched_process_exec``tp/sched/sched_process_exit

構(gòu)建內(nèi)核項目，如下所示。保存您的更改，使用 構(gòu)建內(nèi)核程序，這會創(chuàng)建一個名為 package.json 的對象文件。sudo lmp build

3. 運行內(nèi)核程序

可以使用運行內(nèi)核程序，沒有用戶端程序?qū)?shù)據(jù)的處理的情況下，該框架下內(nèi)核程序?qū)敵鏊斜?output 的數(shù)據(jù)：lmp run package.json

一開始您不會看到任何數(shù)據(jù)，只有當內(nèi)核的跟蹤點被觸發(fā)時，這里是新的進程被創(chuàng)建或退出時，才會輸出數(shù)據(jù)。這里新建了一個虛擬終端，輸出了如下數(shù)據(jù)：

4. 添加用戶態(tài)程序

我們提供的是 demo 是 C 語言版本的 WASM 開發(fā)框架，在構(gòu)建好的內(nèi)核項目文件夾內(nèi)，使用 生成一個 WASM 用戶態(tài)項目模板，app.c、eunomia-include、ewasm-skel.h 這些文件會被生成。ewasm-skel.h 是被打包為頭文件的內(nèi)核程序，app.c 是用戶態(tài)程序的模板文件，我們可以修改它來進行自定義的數(shù)據(jù)處理，這里不做修改。sudo lmp gen-wasm-skel

使用構(gòu)建用戶態(tài)程序，生成 app.wasm 文件sudo lmp build-wasm

使用運行用戶態(tài)程序，json 格式的輸出為通用的數(shù)據(jù)處理做好了準備：lmp run app.wasm

另一個例子：使用 eBPF 打印進程內(nèi)存使用狀況

可以將 bootstrap.bpf.c 重命名為 procstat.bpf.c，將 bootstrap.bpf.h 重命名為 procstat.bpf.h，然后編譯運行。對應(yīng)的源代碼如下：

procstat.bpf.c

過程

具體的上報事件信息在 event 結(jié)構(gòu)體中定義：

掛載點與掛載原因分析：

• 首先，獲取進程級別內(nèi)存使用信息需要獲取到進程的 task_struct 結(jié)構(gòu)體，其中在 mm_struct 成員中存在一個保存進程當前內(nèi)存使用狀態(tài)的數(shù)組結(jié)構(gòu)，因此有關(guān)進程的大部分內(nèi)存使用信息都可以通過這個數(shù)組獲得。

• 其次，需要注意函數(shù)的插入點，插入點的選取關(guān)系到數(shù)據(jù)準確性是否得到保證，而在進程的內(nèi)存申請，釋放，規(guī)整等代碼路徑上都存在頁面狀態(tài)改變，但是數(shù)量信息還沒有更新的相關(guān)結(jié)構(gòu)中的情況，如果插入點這兩者中間，數(shù)據(jù)就會和實際情況存在差異，所有在確?？梢垣@取到進程 PCB 的前提下，選擇在進程調(diào)度代碼路徑上考慮。而 finish_task_switch 函數(shù)是新一個進程第一個執(zhí)行的函數(shù)，做的事卻是給上一個被調(diào)度出去的進程做收尾工作，所以這個函數(shù)的參數(shù)是上一個進程的 PCB，從這塊獲得上一個進程的內(nèi)存就可以確保在它沒有再次被調(diào)度上 CPU 執(zhí)行的這段時間內(nèi)的內(nèi)存穩(wěn)定性數(shù)據(jù)。

• 因此最后選擇將程序掛載到 finish_task_switch 函數(shù)上。數(shù)據(jù)來源有兩部分，一個是 mm_struc 結(jié)構(gòu)本身存在的狀態(tài)信息，另一個是在 mm_rss_stat 結(jié)構(gòu)中。

也可以在 bolipi 的平臺中在線編譯，在線體驗運行 eBPF 程序：https://bolipi.com/ebpf/home/online

完整的代碼、文檔和運行結(jié)果可以在 LMP 中 eBPF_Supermarket 處找到：eBPF_Supermarket/Memory_Subsystem/memstat/procstat^[2]^

相關(guān)背景

LMP 項目的成立初衷是：

• 面向 eBPF 初學(xué)者和愛好者，提供 eBPF 學(xué)習(xí)資料、程序/項目案例，構(gòu)建 eBPF 學(xué)習(xí)社區(qū)

• 成為 eBPF 工具集散地，我們相信每一位 eBPF 初學(xué)者和愛好者都有無限的創(chuàng)造力

• 孵化 eBPF 想法、相關(guān)工具、項目

LMP 目前分為四個子項目：

• eBPF_Supermarket 中包含了大量由個人開發(fā)者編寫的 eBPF 工具，覆蓋了網(wǎng)絡(luò)、性能分析、安全等多種功能;

• eBPF_Hub 是規(guī)范化的 eBPF 程序庫，可以隨時下載運行;

• eBPF_Visualization 是為 eBPF 程序管理而開發(fā)的 web 管理系統(tǒng)，聚焦 eBPF 數(shù)據(jù)可視化和內(nèi)核可視化;

• eBPF_Documentation 為社區(qū)收集、梳理和原創(chuàng)的 eBPF 相關(guān)資料和文檔。

當前 LMP 項目也存在一些問題，例如對于 eBPF 工具的開發(fā)者，存在非常多而且復(fù)雜的用戶態(tài)可視化、展示方案，有許多套系統(tǒng)提供可視化的實現(xiàn)并且有多種語言混合，缺乏展示標準、也難以進行可視化的整合等。因此，我們希望嘗試借助 eunomia-bpf 提供的符合 OCI 標準的 WASM 和 eBPF 程序，提供標準化、高可擴展性的基于 eBPF 的可視化、數(shù)據(jù)展示、分析平臺，利用 ORAS 簡化擴展 eBPF 的分發(fā)、加載、運行能力，為 eBPF 工具的開發(fā)者和使用者提供更加簡單、高效的體驗。

網(wǎng)絡(luò)裝配

WebAssembly 是一種新的編碼方式，可以在現(xiàn)代的網(wǎng)絡(luò)瀏覽器中運行 - 它是一種低級的類匯編語言，具有緊湊的二進制格式，可以接近原生的性能運行，并為諸如 c\c++ 等語言提供一個編譯目標，以便它們可以在 Web 上運行。它也被設(shè)計為可以與 JavaScript 共存，允許兩者一起工作。而且，更棒的是，這是通過 W3C WebAssembly Community Group 開發(fā)的一項網(wǎng)絡(luò)標準，并得到了來自各大主要瀏覽器廠商的積極參與。

盡管 WebAssembly 是為運行在 Web 上設(shè)計的，它也可以在其它的環(huán)境中良好地運行。包括從用作測試的最小化 shell ，到完全的應(yīng)用環(huán)境 —— 例如：在數(shù)據(jù)中心的服務(wù)器、物聯(lián)網(wǎng)（IoT）設(shè)備或者是移動/桌面應(yīng)用程序。甚至，運行嵌入在較大程序里的 WebAssembly 也是可行的。通常，通過維持不需要 Web API 的非 Web 路徑，WebAssembly 能夠在許多平臺上用作便攜式的二進制格式，為移植性、工具和語言無關(guān)性帶來巨大的好處。（因為它支持 c\c++ 級語義）

WASM 的編譯和部署流程如下：

OCI（開放容器倡議）

開放容器協(xié)議(OCI)是一個輕量級，開放的治理結(jié)構(gòu)，為容器技術(shù)定義了規(guī)范和標準。在 Linux 基金會的支持下成立，由各大軟件企業(yè)構(gòu)成，致力于圍繞容器格式和運行時創(chuàng)建開放的行業(yè)標準。其中包括了使用 Container Registries 進行工作的 API，正式名稱為 OCI 分發(fā)規(guī)范（又名“distribution-spec”）。這個發(fā)布規(guī)范是基于 Docker 公司最初發(fā)布的開源注冊服務(wù)器編寫的，它存在于 GitHub 的distribution/distribution^[3]^ （現(xiàn)在是CNCF^[4]^ 項目）上。

OCI 目前提出的規(guī)范有如下這些：

其中 runtime 和 image 的規(guī)范都已經(jīng)正式發(fā)布，而 distribution 的還在工作之中。runtime 規(guī)范中介紹了如何運行解壓縮到磁盤上的 'Filesystem Bundle'[8]。在 OCI 標準下，運行一個容器的過程就是下載一個 OCI 的鏡像，將其解壓到某個 中，然后某個 OCI Runtime 就會運行這個 Bundle。Filesystem Bundle

伴隨著 image spec 與分發(fā) spec 的演化，人們開始逐步認識到除了 Container Images 之外，Registries 還能夠用來分發(fā) Kubernetes Deployment Files， Helm Charts， docker-compose， CNAB^[9]^ 等產(chǎn)物。它們可以共用同一套 API，同一套存儲，將 Registries 作為一個云存儲系統(tǒng)。這就為帶來了 OCI Artifacts 的概念，用戶能夠把所有的產(chǎn)物都存儲在 OCI 兼容的 Registiry 當中并進行分發(fā)。為此，Microsoft 將 oras^[10]^ 作為一個 client 端實現(xiàn)捐贈給了社區(qū)，包括 Harbor 在內(nèi)的多個項目都在積極的參與。

ORAS（OCI 注冊表作為存儲）

Registries 正在逐漸演變?yōu)橥ㄓ玫慕M件存儲庫。為了實現(xiàn)這一目標，ORAS 項目提供了一種將 OCI Artifacts 從 OCI Registries 提交和拉取的方法。正在尋求通用 Registries 客戶端的用戶可以從ORAS CLI^[11]^ 中得到幫助，而開發(fā)人員可以在ORAS 客戶端的開發(fā)庫^[12]^ 之上構(gòu)建自己的客戶端。

ORAS 的工作原理與您可能已經(jīng)熟悉的工具（如 docker）類似。它允許您向 OCI Registries 推送（上傳）和提?。ㄏ螺d）內(nèi)容，并處理登錄（身份驗證）和令牌流（授權(quán)）。ORAS 的不同之處在于將焦點從容器映像轉(zhuǎn)移到其他類型的組件上。

因此，鼓勵新的 OCI Artifacts 的作者定義他們自己的組件媒體類型，以使得他們的用戶知道如何對其進行操作。

如果您希望立即開始發(fā)布 OCI Artifacts，請查看ORAS CLI^[13]^ 。希望提供給自己用戶體驗的開發(fā)人員應(yīng)該使用一個 ORAS 客戶端開發(fā)庫。

未來的發(fā)展方向

未來 LMP 會專注于更多的基于 eBPF 的應(yīng)用工具和實踐的開發(fā)：

1. 進一步完善 ORAS 和 OCI 鏡像相關(guān)的支持;

2. 重構(gòu)并遷移現(xiàn)有的 eBPF 工具，提供完整的、開箱即用的分析工具組件，例如性能工程等方面;

3. 探索和孵化更多的 eBPF 想法、相關(guān)工具、項目;

我們所基于的 eunomia-bpf 項目也會繼續(xù)完善，專注于提供一個底層的 eBPF 開發(fā)平臺和運行時基礎(chǔ)設(shè)施，力求帶來更好的開發(fā)和移植體驗：

1. 測試更多平臺和內(nèi)核版本的支持，目前已經(jīng)在 和 上成功移植并運行，接下來會對低內(nèi)核版本、Android、RISC-V 等平臺，以及嵌入式、邊緣計算相關(guān)的設(shè)備進行更進一步的測試;也許在未來，我們還可以提供 Windows 上的 eBPF 程序支持和類似的開發(fā)體驗;ARM64``x86_64

2. 提供標準化、穩(wěn)定的 JSON 和 WASM 接口協(xié)議規(guī)范以及 OCI 鏡像規(guī)范，不和任何的供應(yīng)商或云服務(wù)綁定。如果不使用 eunomia-bpf 相關(guān)的底層運行時，或使用自定義的 WASM 運行時，也可以通過標準化的接口來使用 LMP 中已經(jīng)有的大量 eBPF 程序生態(tài)。

3. 提供更友好的用戶態(tài)開發(fā)接口，以及更多的用戶態(tài)開發(fā)語言 SDK，例如 Go、Rust、Python 等;

4. 進行更多關(guān)于 WASM 和 eBPF 結(jié)合的探索;

原文作者：技術(shù)簡說