開源尤拉 openEuler 將推動建立 eBPF 軟體釋出標準

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

如今 eBPF 被廣泛應用在雲原生、可觀測、效能調優、安全、硬體加速等領域，並且其應用場景還在快速擴充套件。

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

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

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

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

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

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

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

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

目前 eBPF 的開發、釋出方式

這兩種技術路線都存在弊端，隨著 eBPF 技術的發展，出現 BumbleBee 、eunomia-bpf 等專案致力於綜合這兩類技術路線的優點，但依舊缺乏對 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 形態

IT之家瞭解到，openEuler 可程式設計核心 SIG 希望標準化 eBPF 軟體相關基礎技術（包括打包、釋出、安裝、升級等），

方便 eBPF 技術在各行業、場景的推廣

。為此，由多家企業 / 高校在 openEuler 社群倡議建立行業標準，透過標準化釋出將核心定製能力、硬體解除安裝能力向社群使用者提供效能加速、安全加固、智慧觀測等服務。

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

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

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

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

openEuler 可程式設計核心 SIG 目標

openEuler 可程式設計核心 SIG 目標之一將推動 eBPF as Service 標準化工作，將核心能力、硬體加速能力服務化、集市化，惠及更多的社群使用者。與此同時，openEuler 社群會將行業標準內的一些基礎軟體、技術標準推送至 Linux 上游社群，加強 eBPF 技術生態建設。