eBPF的前世今生？eBPF在使用中遇到的問題有哪些？

前世BPF

在介紹eBPF (Extended Berkeley Packet Filter)之前，我們先來了解一下它的前身－BPF (Berkeley Packet Filter)伯克利數據包過濾器。

BPF最早由Van Jacobson在1992年開發，用于在Unix操作系統中過濾和捕獲網絡數據包。它運行在內核中，通過提供一個簡單而強大的虛擬機，可以在網絡協議層上進行高效的數據包處理操作。BPF通過把過程轉換成指令序列來實現，這些指令直接在內核中執行，從而避免了用戶空間和內核空間之間頻繁的切換。

基于BPF開發的工具庫有libpcap、tcpdump等工具。

BPF在網絡性能監測和安全策略實施方面具有廣泛的應用。然而，由于其指令集的限制和功能的局限性，它無法支持更加復雜和靈活的數據包處理需求。

今生eBPF

正是為了克服BPF的限制，eBPF應運而生。eBPF于2014年（3.18版本）年首次引入Linux內核，并在此后的幾年中經歷了快速的發展和完善。

eBPF是一個高度可擴展的、運行在內核中的虛擬機，具備與傳統BPF相似的指令集，但功能更加強大且更加靈活。eBPF可以在運行時即時編譯，從而能夠處理更加復雜和動態的數據包處理任務，如網絡流量分析、安全檢測和性能優化等。

eBPF的靈活性和可擴展性體現在它可以與各種用戶空間程序（如tcpdump、Wireshark、Suricata等）和工具（如網絡監控、調試器等）無縫集成。eBPF還可以與系統的其他組件（如網絡協議棧、調度器等）交互，從而實現更加細粒度的性能優化和安全策略。

此外，eBPF的開發和使用也得到了廣泛的支持和推動。社區中有許多致力于eBPF的開發者和貢獻者，他們不斷改進和擴展eBPF的功能。同時，一些知名的大型技術公司，如Facebook、Netflix和Google等，也在其產品和基礎設施中廣泛使用eBPF。

eBPF的發展史

2014 年初，Alexei Starovoitov 實現了eBPF。新的設計針對現代硬件進行了優化，所以eBPF生成的指令集比舊的 BPF 解釋器生成的機器碼執行得更快。擴展版本也增加了虛擬機中的寄存器數量，將原有的 2 個 32 位寄存器增加到10 個 64 位寄存器。由于寄存器數量和寬度的增加，開發人員可以使用函數參數自由交換更多的信息，編寫更復雜的程序?？傊?，這些改進使eBPF版本的速度比原來的 BPF 提高了 4 倍。

eBPF是一項具有革命性的技術，源自于Linux內核，可以在特權環境中運行受沙盒保護的程序，例如操作系統內核。它被用于安全有效地擴展內核的功能，而無需更改內核源代碼或加載內核模塊。

在歷史上，操作系統一直是實現可觀察性、安全性和網絡功能的理想場所，這是因為內核具有特權能力，可以監督和控制整個系統。與此同時，由于內核在系統中的核心地位以及對穩定性和安全性的高要求，操作系統內核的演進往往很困難。因此，與操作系統外部實現的功能相比，操作系統層面的創新速度傳統上較低。

eBPF從根本上改變了這個共識。通過在操作系統內運行受沙盒保護的程序，應用開發人員可以在運行時運行eBPF程序，為操作系統添加額外的功能。操作系統會利用即時編譯器和驗證引擎的幫助來保證安全性和執行效率，就像本地編譯一樣。這導致了一系列基于eBPF的項目的涌現，涵蓋了各種用例，包括下一代網絡、可觀測性和安全功能。

如今，eBPF被廣泛應用于驅動各種用例：在現代數據中心和云原生環境中提供高性能的網絡和負載均衡，以低開銷提取細粒度的安全可觀測性數據，幫助應用開發人員追蹤應用程序、提供性能故障排除的見解，進行預防性應用程序和容器運行時安全執行等等?？赡苄允菬o限的，eBPF正在釋放出的創新力量才剛剛開始。

Hook Overview

eBPF程序是事件驅動的，當內核或應用程序通過某個掛鉤點時運行。預定義的掛鉤點包括系統調用、函數入口/退出、內核追蹤點、網絡事件等等。

eBPF使用中遇到的問題

1

內核適應性，老版本是否某些功能不可用？

eBPF 最低要求版本為LInux 4.1，eBPF的最低內核版本要求是 Linux 4.1，這是在 2015 年發布的內核版本。在這個版本之前的內核不支持 eBPF。

對于Linux4.1版本之前的監控

擎創對于Linux 4.1.0 之前的版本采用BPF采集HTTP 1數據以及DNS解析請求，進行可觀測統計。

對于Linux4.1版本之后的監控

為了保證eBPF程序在各個linux內核版本之間的可移植性，我們編寫eBPF程序的時候采用了CORE技術,CORE技術目前只有在 Linux 4.9.0 之后才會支持。

如果用戶內核版本低于4.9.0或者內核未開啟CO-RE, 我們能夠提供linux內核升級包。

2

權限、安全要求

eBPF權限

需要具備root權限或CAP_SYS_ADMIN能力，這意味著只有能夠加載內核模塊的用戶才能加載eBPF程序。

eBPF執行安全

在執行安全方面，eBPF 在加載之前會通過eBPF驗證器對要執行的字節碼文件進行校驗，包括但不限于以下方面：

（1）程序不包含控制循環

（2）程序不會執行超過內核允許的最大指令數

（3）程序不包含任何無法到達的指令

（4）程序不會跳轉到程序界限之外

3

uprobe 和 kprobe 差異

kprobe的優劣分析

優勢：

（1）更簡單實現和更易維護。它不依賴于其他庫的具體實現細節

劣勢：

（1）用戶程序可能會將單個請求分割成多個系統調用，重新組裝這些請求會帶來一些復雜性

（2）與TLS不兼容, 無法解包TLS

uprobe的優劣分析

優勢：

（1）我們可以訪問和捕獲應用程序上下文，如堆棧跟蹤

（2）我們可以構建uprobes以在解析完成后捕獲數據，避免在跟蹤器中重復工作

（3）可以比較容易捕獲https 請求,對TLS兼容性較好

劣勢：

（1）對于使用的底層庫版本敏感。無法在剝離了符號的二進制文件上運行

（2）需要為每個庫實現不同的探針（每種編程語言可能都有自己的一組庫）

（3）會導致額外的調用性能開銷

4

性能消耗

雖然內核社區已經對 eBPF 做了很多的性能調優，跟蹤用戶態函數（特別是鎖爭用、內存分配之類的高頻函數）還是有可能帶來很大的性能開銷。因此，我們在使用 uprobe,kprobe 時，應該盡量避免長時間跟蹤高頻函數。

我們以監控一個Golang 程序HTTP 1通信過程為例子,在分別開啟uprobe和kprobe時候對該程序進行壓力測試：

從結果可以看出，如果HTTP延遲大于1毫秒，引入的開銷可以忽略不計，在大多數情況下只是噪音。這對于kprobes和uprobes都是類似的，盡管我們重新解析了所有數據，但kprobes的性能稍微好一些。請注意，開銷有時是負值，這很可能只是測量中的噪音。在這里的關鍵要點是，如果您的HTTP處理程序正在進行任何實際的工作（大約1毫秒計算時間），引入的開銷基本上可以忽略不計。

5

能否追蹤所有用戶態/內核態函數

調用的入參和返回值

用戶態

eBPF可以追蹤指定函數調用入參和返回值。hook點可以為指定函數名稱或者地址。如果可執行文件的符號被優化，則需要使用一些逆向手段定位指定函數的地址。

內核態

我們可以使用bpftrace -l了解可以hook的鉤子點。

bpftrace是通過讀?。ㄏ路酱a）獲取kernel層所有的可跟蹤點。

/sys/kernel/debug/tracing/available_filter_functions

6

是否有丟失事件的風險

kprobe和uprobe本身的事件觸發并不會丟失

kprobe是一種內核探測機制，它允許用戶在內核函數執行前或執行后插入代碼。uprobe是一種對用戶空間函數進行探測的機制，它允許用戶在用戶空間函數的入口或出口處插入代碼。

eBPF通過將用戶編寫的處理邏輯加載到內核中，在事件發生時執行此邏輯，以實現用戶級的觀察和處理。由于eBPF的虛擬機技術提供了一種安全可隔離的方式來在內核中執行用戶代碼，因此kprobe和uprobe事件不會丟失。

bpf_perf_event會有丟失事件的風險

內核態的eBPF代碼將收集到的事件寫入 bpf_perf_event 環形緩沖區,用戶態程序進行收集上報。當讀寫速度不匹配時，就會丟失事件：

（1）寫速度過快：例如每個HTTP transaction都作為一個event寫入緩沖區，這樣比批量寫的風險更高。

（2）讀速度過慢：例如用戶態代碼沒有在專門線程中讀取緩沖區，或者系統負載過高。

bpf_map會有丟失事件的風險

eBPF map有大小限制，當map被寫滿的時，將無法寫入新的數據

（1）丟失數據：由于map已滿，新的寫入操作將無法成功，導致數據丟失。這可能會影響到程序的正確性和完整性。

（2）性能下降：當map寫滿時，寫入操作將被阻塞，導致系統的性能下降。這會影響到整體的系統響應時間和吞吐量。

展望

隨著eBPF的不斷發展和壯大，我們可以看到它在網絡和系統領域的巨大潛力。eBPF已經被證明是一種強大且高效的工具，可以用于實現各種高級網絡和系統功能。

在未來，我們有理由相信eBPF將繼續發展，并被越來越多的開發者和組織使用。隨著eBPF功能的不斷擴展和完善，我們可以期待更多創新的網絡應用和系統工具的出現，從而推動整個行業向前發展。

總之，eBPF的前世今生令人振奮，它不僅繼承了BPF的優點，還擁有更強大和靈活的功能。我們期待看到eBPF為網絡和系統帶來更多的創新和改進，為我們的數字化世界帶來更強大的支撐。

審核編輯：劉清