openEuler 倡議建立 eBPF 軟體釋出標準

eBPF 是一個能夠在核心執行沙箱程式的技術，提供了一種在核心事件和使用者程式事件發生時安全注入程式碼的機制，使得非核心開發人員也可以對核心進行控制。隨著核心的發展，eBPF 逐步從最初的資料包過濾擴充套件到了網路、核心、安全、跟蹤等，而且它的功能特性還在快速發展中，早期的 BPF 被稱為經典 BPF，簡稱 cBPF，正是這種功能擴充套件，使得現在的 BPF 被稱為擴充套件 BPF，簡稱 eBPF。

如今 eBPF 被廣泛應用在雲原生、可觀測、效能調優、安全、硬體加速等領域，並且其應用場景還在快速擴充套件，各種場景基於 eBPF 技術的創新 idea 呈現井噴現象，eBPF 的時代已經來臨。

eBPF 技術現狀

雖然 eBPF 技術應用呈現井噴現象，但是開發、釋出、安裝等相關的基礎技術出現碎片化現象，導致技術成果無法快速平移至行業客戶生產環境；相似 eBPF 技術應用在重複實踐。這些問題阻礙 eBPF 技術的普及與推廣。

如下圖所示，總結目前 eBPF 的開發、釋出方式基本可以劃分成 2 種技術路線：

開發態、執行態分離（典型代表 libbpf）

優點：ELF 檔案形式（或者連結進應用程式）釋出，執行時輕量化，適合生產環境大規模應用。

缺點：應用技術門檻高，且不具備可移植性（比如高核心版本的 eBPF 程式無法移植至低核心版本中）。

開發態、執行態融合（典型代表 BCC）

優點：原始碼形式釋出天然具備可移植性；封裝抽象執行時，提供高階語言 API，降低開發難度。

缺點：執行時重型化，對生產環境要求較高（需要安裝開發態一系列工具）；高度抽象後，降低使用靈活度，不適合大型應用開發。

這兩種技術路線都存在弊端，隨著 eBPF 技術的發展，出現 BumbleBee 、eunomia-bpf 等專案致力於綜合這兩類技術路線的優點，但依舊缺乏對 eBPF 基礎技術的整體規劃。

eBPF 發展展望

eBPF summit 2022 《The future of eBPF in the Linux Kernel》展望了 eBPF 的發展方向，具體的演進方向包括幾個方面：

更完備的程式設計能力：當前 eBPF 的程式設計能力存在一些侷限性（比如不支援變數邊界的迴圈，指令數量受限等），演進目標提供圖靈完備的程式設計能力。

更強的安全性：支援型別安全，增強執行時 Verifier，演進目標是提供媲美 Rust 的安全程式設計能力。

更廣泛的移植能力：增強 CO-RE，加強 Helper 介面可移植能力，實現跨體系、平臺的移植能力。

更強的可程式設計能力：支援訪問/修改核心任意引數、返回值，實現更強的核心程式設計能力。

概括其演進目標是希望將 eBPF 打造成一款針對核心（包括硬體）執行時的安全程式語言，透過該語言構建 eBPF 軟體，用來承載核心（或硬體）的能力。演進結果產生一個有趣現象：按照傳統軟體型別劃分方式，我們很難將 eBPF 軟體歸類成應用軟體或是系統軟體。所以，乾脆將其定義成一種獨立軟體形態：核心態服務（eBPF as Service）。

eBPF Service 形態

建立 eBPF 行業標準的思路

eBPF 軟體有別於系統軟體、應用軟體，從軟體自身特點而言，其應具備符合其自身特點的開發、編譯、打包、釋出、安裝、升級等工具系列。

當前 eBPF 的開發框架、釋出形式發展迅速，但也存在一些問題，包括跨版本移植能力、多場景支援能力、開發易用性、服務可獲得性等問題。openEuler 可程式設計核心 SIG 希望標準化 eBPF 軟體相關基礎技術（包括打包、釋出、安裝、升級等），方便 eBPF 技術在各行業、場景的推廣。為此，由多家企業/高校在 openEuler 社群倡議建立行業標準，透過標準化釋出將核心定製能力、硬體解除安裝能力向社群使用者提供效能加速、安全加固、智慧觀測等服務。

預計我們將在 12 月份組織一次線上 meetup，當前參與企業/組織包括天翼雲、深信服、華為、西郵、中山大學、中科馭數、信通院、銳捷等，希望國內對 eBPF 技術有訴求、規劃的廠商加入本次 meetup，建立 eBPF 技術相關標準，為 eBPF 技術應用、科研提供較好的基礎平臺。

具體討論範圍劃分成三個方向：

eBPF runtime：負責提供具備可移植性的軟體安裝能力，軟體熱升級能力，包管理等能力。

eBPF Development Kit：負責提供一站式開發、除錯、編譯工具，提供具備跨體系、平臺移植能力的軟體包釋出能力。

eBPF Service HUB：負責提供 eBPF Service 集市化管理，提供 eBPF Service 推送、分發等能力。