eBPF 與 Rust 的強大組合

– 22 分鐘閱讀

Rust 作為一門注重記憶體安全和效能的系統程式語言，與 eBPF 技術的結合為開發者提供了強大的系統程式設計能力。在我多年的系統程式設計經驗中，發現這兩種技術的結合能夠同時滿足高效能和安全性需求，特別適合開發網路監控、安全防護和效能分析工具。

Aya：原生 Rust 的 eBPF 開發框架

Aya 是一個完全以 Rust 實作的 eBPF 框架，它讓開發者能夠直接用 Rust 編寫 eBPF 程式，而不需要像其他框架那樣依賴 C 語言。這種設計使得開發者可以充分利用 Rust 的安全特性和豐富的生態系統。

以下是一個使用 Aya 開發的 XDP (eXpress Data Path) 程式範例：

#[xdp]
pub fn myapp(ctx: XdpContext) -> u32 {
    match try_myapp(ctx) {
        Ok(ret) => ret,
        Err(_) => xdp_action::XDP_ABORTED,
    }
}

fn try_myapp(_ctx: XdpContext) -> Result<u32, u32> {
    // 記錄收到的網路封包
    info!("received a packet");
    
    // 回傳 XDP_PASS 讓核心繼續正常處理封包
    Ok(xdp_action::XDP_PASS)
}

這段 eBPF 程式使用 Rust 編寫，目的是攔截網路封包並進行簡單處理。#[xdp] 標註表明這是一個 XDP 型別的 eBPF 程式，會在網路封包剛到達網路卡時被呼叫。主函式 myapp 是程式的入口點，它呼叫 try_myapp 函式進行實際處理，並處理可能的錯誤。try_myapp 函式記錄封包接收事件，然後回傳 XDP_PASS 值，告訴核心繼續按正常路徑處理該封包。

Aya 框架會將這段 Rust 程式編譯成 ELF 目標檔，其中包含 eBPF 位元組碼。與使用 Clang 編譯 C 程式不同的是，Aya 使用 Rust 編譯器來生成目標檔。

使用者空間程式與 eBPF 程式的協作

除了 eBPF 程式本身，我們還需要使用者空間程式來載入和管理這些 eBPF 程式。以下是使用 Aya 框架載入和附加 eBPF 程式的關鍵程式碼：

// 從編譯好的 ELF 檔案載入 eBPF 位元組碼
let mut bpf = Bpf::load(include_bytes_aligned!(
    "../../target/bpfel-unknown-none/release/myapp"
))?;

// 取得名為 "myapp" 的程式並轉換為 XDP 型別
let program: &mut Xdp = bpf.program_mut("myapp").unwrap().try_into()?;

// 將程式載入核心
program.load()?;

// 將程式附加到指定的網路介面
program.attach(&opt.iface, XdpFlags::default())?;

這段程式碼展示了 eBPF 程式載入和附加的四個關鍵步驟：

  1. 從編譯產生的 ELF 目標檔讀取 eBPF 位元組碼
  2. 在該位元組碼中找到名為 “myapp” 的程式並將其轉換為 XDP 型別
  3. 將程式載入 Linux 核心
  4. 將程式附加到指定的網路介面上的 XDP 事件

這種方式讓開發者能夠完全控制 eBPF 程式的生命週期，包括載入、附加和解除安裝過程。

如果你是 Rust 程式設計師，我強烈建議深入探索 “Aya book” 中的更多範例。此外，Kong 有一篇很好的部落格文章，詳細介紹瞭如何使用 Aya 開發 XDP 負載平衡器。

Rust-bcc：BCC 的 Rust 繫結

除了 Aya，另一個值得關注的 Rust eBPF 框架是 Rust-bcc。它提供了模仿 BCC 專案 Python 繫結的 Rust 繫結，同時也包含了一些 BCC 追蹤工具的 Rust 實作。

Rust-bcc 讓熟悉 BCC 的開發者能夠使用 Rust 的優勢，同時保持 BCC 的易用性和強大功能。這對於已經熟悉 BCC 但想要利用 Rust 安全特性的開發者來說是一個很好的選擇。

eBPF 程式的測試技巧

開發 eBPF 程式時，測試是確保程式正確性和效能的關鍵步驟。以下介紹幾種測試 eBPF 程式的方法：

使用 BPF_PROG_RUN 命令進行測試

Linux 核心提供了 bpf() 系統呼叫的 BPF_PROG_RUN 命令，允許從使用者空間執行 eBPF 程式進行測試。這種方法特別適合測試網路相關的 eBPF 程式型別。

// 使用 BPF_PROG_RUN 測試 eBPF 程式的範例
struct bpf_test_run_opts opts = {0};
opts.data_in = input_data;
opts.data_size_in = input_size;
// 設定其他必要引數...

int result = bpf_prog_test_run_opts(prog_fd, &opts);

這段程式碼展示瞭如何使用 BPF_PROG_RUN 命令測試 eBPF 程式。開發者可以準備輸入資料並設定必要的引數，然後呼叫 bpf_prog_test_run_opts 函式執行測試。這種方法允許開發者在不實際佈署到生產環境的情況下驗證 eBPF 程式的行為。

監控 eBPF 程式的效能

Linux 核心也提供了監控 eBPF 程式效能的機制。可以透過以下命令啟用 eBPF 統計資訊：

$ sysctl -w kernel.bpf_stats_enabled=1

啟用後，使用 bpftool 命令檢視程式資訊時會顯示額外的統計資訊：

$ bpftool prog list
...
2179: raw_tracepoint name raw_tp_exec tag 7f6d182e48b7ed38 gpl
      run_time_ns 316876 run_cnt 4
      loaded_at 2023-01-09T11:07:31+0000 uid 0
      xlated 216B jited 264B memlock 4096B map_ids 780,777
      btf_id 953
      pids hello(19173)

上面的輸出中，run_time_ns 316876 run_cnt 4 表示該程式已執行 4 次，總執行時間約為 316,876 納秒（約 317 微秒）。這些統計資訊對於分析 eBPF 程式的效能和行為非常有用，可以幫助開發者識別潛在的效能問題或異常行為。

多個 eBPF 程式的協同工作

在實際應用中，單個 eBPF 程式往往不足以實作複雜功能，需要多個 eBPF 程式協同工作。

案例分析：opensnoop 工具

以 opensnoop 工具為例，它需要追蹤四個不同的系統呼叫追蹤點：

  • syscall_enter_open
  • syscall_exit_open
  • syscall_enter_openat
  • syscall_exit_openat

這些追蹤點分別對應 open() 和 openat() 系統呼叫的入口和出口點。為什麼需要同時追蹤入口和出口點呢？

入口點追蹤是因為系統呼叫的引數（如檔名和開啟旗標）在這時可用。但在入口點無法知道檔案開啟是否成功。出口點追蹤則可以取得系統呼叫的回傳值，知道操作是否成功。

在 libbpf-tools 版本的 opensnoop 中，一個使用者空間程式負責載入所有四個 eBPF 程式並將它們附加到相應事件。這些 eBPF 程式本質上是獨立的，但它們透過 eBPF maps 進行協調和資料分享。

動態管理 eBPF 程式

更複雜的應用可能需要在長時間執行期間動態增加和移除 eBPF 程式。某些應用甚至沒有固定數量的 eBPF 程式。例如，Cilium 會為每個虛擬網路介面附加 eBPF 程式，而在 Kubernetes 環境中，這些介面會隨著 Pod 的建立和銷毀而變化。

本文提到的大多數程式函式庫都能自動處理多個 eBPF 程式。例如，libbpf 和 ebpf-go 會生成骨架程式碼，可以透過一次函式呼叫載入目標檔中的所有程式和 map。它們也提供了更細粒度的函式，讓開發者能夠單獨操作程式和 map。

eBPF 開發框架的選擇

根據不同的需求和背景，開發者可以選擇不同的 eBPF 開發框架：

  1. bpftrace：適合快速收集追蹤資訊，特別是臨時性的除錯和效能分析任務。

  2. BCC：如果你熟悉 Python 並且不關心執行時編譯步驟，BCC 是快速構建 eBPF 工具的好選擇。

  3. 支援 CO-RE 的框架：如果你正在編寫需要廣泛分發和跨不同核心版本移植的 eBPF 程式，推薦使用支援 CO-RE（Compile Once – Run Everywhere）的框架，如：

    • C 語言：libbpf
    • Go 語言：cilium/ebpf 和 libbpfgo
    • Rust 語言：Aya

在我的實際開發經驗中，對於需要長期維護和跨版本佈署的專案，我傾向於選擇支援 CO-RE 的框架，因為它們能夠大幅減少跨核心版本的相容性問題。而對於原型開發和快速驗證概念，bpftrace 和 BCC 則提供了更快的開發速度。

實際應用：從 Hello World 開始

要開始使用 eBPF，最好的方式是從簡單的 “Hello World” 程式開始。以下是使用 Rust 和 Aya 框架實作的 Hello World 範例：

#[kprobe]
pub fn hello_exec(ctx: ProbeContext) -> u32 {
    match try_hello_exec(ctx) {
        Ok(ret) => ret,
        Err(_) => 1,
    }
}

fn try_hello_exec(ctx: ProbeContext) -> Result<u32, u32> {
    info!("process executed a program");
    Ok(0)
}

這個簡單的 eBPF 程式使用 kprobe 附加到核心的 exec 系統呼叫，每當程式執行新程式時就會觸發。程式只是記錄一條訊息表示有程式被執行，然後回傳 0 表示成功。即使是這樣簡單的程式，也展示了 eBPF 程式的基本結構和錯誤處理方式。

實作完成後，可以使用 llvm-objdump 工具檢查生成的位元組碼，並使用 strace -e bpf 觀察程式執行時的 bpf() 系統呼叫，這有助於理解 eBPF 程式的載入和執行過程。

eBPF 的未來發展

eBPF 技術仍在持續發展中，不僅在 Linux 核心中不斷演進，還被引入到 Windows 作業系統中。隨著更多程式語言和框架的支援，eBPF 的應用範圍將進一步擴大。

從技術社群的發展趨勢來看，CO-RE 技術的普及和更多高階語言的原生支援將是 eBPF 未來發展的重要方向。這將使 eBPF 程式開發變得更加簡單和可靠，進一步降低入門檻。

在實際應用方面，我預見 eBPF 將在網路安全、可觀測性和效能最佳化領域發揮越來越重要的作用。特別是在雲原生和微服務架構中，eBPF 提供的深度可見性和高效能將成為不可或缺的技術基礎。

Rust 語言與 eBPF 技術的結合為系統程式設計提供了強大的工具組合。Aya 和 Rust-bcc 等框架讓開發者能夠利用 Rust 的安全特性和效能優勢開發 eBPF 程式。透過合適的測試方法和效能監控工具，開發者可以確保 eBPF 程式的正確性和效率。

在實際應用中，多個 eBPF 程式往往需要協同工作以實作複雜功能，這需要開發者對 eBPF 程式的生命週期和資料分享機制有深入理解。隨著 eBPF 技術的不斷發展和更多框架的出現，選擇適合自己需求的開發工具變得尤為重要。

如果你對 eBPF 開發有興趣，推薦加入 eBPF Slack 社群，那裡有許多框架的維護者和經驗豐富的開發者可以提供幫助和建議。從簡單的 Hello World 開始，逐步探索這個令人興奮的技術領域，你會發現 eBPF 為系統程式設計帶來的無限可能。

eBPF的發展與跨平台擴充套件：從Linux核心到全球基金會

eBPF發展的關鍵里程碑

自從BPF被引入Linux核心以來，它已經發展成為擁有獨立郵件列表和維護者的獨立子系統。隨著eBPF的普及度增加，以及興趣擴充套件至Linux核心社群之外，建立一個能夠協調不同參與方的中立機構變得極為必要。這就是eBPF基金會成立的背景。

eBPF基金會於2021年由Google、Isovalent、Meta（當時稱為Facebook）、Microsoft和Netflix在Linux基金會的支援下成立。該基金會作為一個可以持有資金和智慧財產權的中立機構，使各種商業公司能夠相互協作。

值得注意的是，基金會的成立並不是為了改變eBPF技術由Linux核心社群和Linux BPF子系統貢獻者開發的方式。基金會的活動由BPF指導委員會引導，該委員會完全由建構這項技術的技術工作者組成，包括Linux核心BPF維護者和其他核心eBPF專案的代表。

eBPF基金會的角色與定位

eBPF基金會專注於eBPF作為一個技術平台，以及能夠促進eBPF開發的工具生態系統。那些根據eBPF構建並尋求中立所有權的專案可能會在其他基金會中找到更適合的歸屬。例如，Cilium、Pixie和Falco都是CNCF（雲原生計算基金會）的一部分，這很合理，因為它們都旨在用於雲原生環境。

這種超越現有Linux維護者合作的關鍵驅動因素之一是Microsoft對在Windows作業系統中開發eBPF的興趣。這帶來了定義eBPF標準的需求，使為一個作業系統編寫的程式可以在另一個作業系統上使用。這項工作正在eBPF基金會的主持下進行。

Windows上的eBPF實作

Microsoft正在積極推進Windows上的eBPF支援。截至2022年底，已經有功能性的示範展示了Cilium第4層負載平衡和根據eBPF的連線跟蹤在Windows上執行。

乍一看，eBPF程式設計是核心程式設計，一個為Linux核心編寫並能存取Linux核心資料結構的程式似乎不太可能在完全不同的作業系統中運作。但實際上，特別是在網路方面，所有作業系統都有很多共同點。無論是在Windows還是Linux機器上建立的網路封包，其結構都是相同的，網路堆積積疊的各層也必須以相同的方式處理。

eBPF程式由一組位元組碼指令組成，這些指令由核心內實作的虛擬機器(VM)處理。這個虛擬機器也可以在Windows中實作！

Windows上的eBPF架構

Windows上的eBPF架構重用了現有eBPF生態系統中的一些開放原始碼元件，如libbpf和Clang對生成eBPF位元組碼的支援。由於Linux核心採用GPL授權，而Windows是專有的，因此Windows專案不能重用Linux核心中驗證器的任何部分。相反，它使用PREVAIL驗證器和uBPF JIT編譯器（兩者都採用寬鬆授權，因此可以被更廣泛的專案和組織使用）。

一個有趣的區別是，eBPF程式碼在使用者空間的Windows安全環境中進行驗證和JIT編譯，而不是在核心內部（核心中顯示的uBPF直譯器僅用於除錯構建，而非生產環境）。

期望為Linux編寫的每個eBPF程式都能在Windows上工作是不現實的。但這與讓eBPF程式在不同Linux核心版本上執行的挑戰並沒有太大區別：即使有CO-RE支援，內部核心資料結構也可能在版本之間變更、新增或移除。eBPF程式設計師的工作就是優雅地處理這些可能性。

Linux eBPF的持續演進

自3.15版本以來，eBPF的功能幾乎隨著每一次核心發布而演進。BCC專案維護了一個有用的清單，可以查詢任何特定版本中可用的功能。在未來幾年中，玄貓預計會有更多的新增功能。

預測未來發展的最佳方式就是關注那些正在研究它的人。例如，在2022年Linux Plumbers會議上，eBPF維護者Alexei Starovoitov討論了他如何期望看到eBPF程式使用的C語言演進。隨著更多功能被增加到支援的C語言中，以及驗證器的支援，eBPF C語言可能會演進為允許開發核心模組的所有靈活性，但同時保持eBPF的安全性和動態載入特性。

eBPF未來發展趨勢

目前正在討論和開發的eBPF新功能和能力包括：

簽名eBPF程式

軟體供應鏈安全在過去幾年一直是熱門話題，其關鍵元素是能夠檢查你打算執行的程式是否來自預期的來源與未被篡改。實作這一點的一種方法是驗證隨程式一起提供的加密簽名。你可能認為核心可以為eBPF程式做這件事，也許作為驗證步驟的一部分，但不幸的是這並不簡單！使用者空間載入器會使用有關對映位置的資訊動態調整程式，從簽名角度看，這很難與惡意修改區分開來。eBPF社群正積極尋找解決方案。

長壽命核心指標

eBPF程式可以使用輔助函式或kfunc檢索指向核心物件的指標，但指標僅在該程式執行期間有效。指標不能儲存在對映中供之後檢索。型別化指標支援的想法將允許在這方面有更多的靈活性。

記憶體分配

eBPF程式不能安全地呼叫像kmalloc()這樣的記憶體分配函式，但有一個提案建議了一個eBPF專用的替代方案。

新功能採用的時間線

作為最終使用者，你能夠利用的功能取決於你在生產環境中執行的核心版本。正如第1章中討論的，核心發布可能需要數年才能進入Linux的穩定發行版。作為個人，你可能會選擇最新的核心，但絕大多數執行伺服器佈署的組織使用的是穩定、受支援的版本。

eBPF程式設計師必須考慮，如果他們編寫利用核心中新增最新功能的程式碼，這些功能在未來幾年內可能無法在大多數生產環境中使用。某些組織可能有足夠緊急的需求，值得更快地推出較新的核心版本，以便及早採用新的eBPF功能。

例如，在另一個關於構建明日網路的前瞻性演講中，Daniel Borkmann討論了一個名為Big TCP的功能。這項功能在5.19版本中被增加到Linux中，透過批次處理核心中的網路封包來實作100 Gbit/s（及更快）的網路速度。大多數Linux發行版在幾年內不會支援這麼新的核心，但對於處理大量網路流量的專業組織來說，提前升級可能是值得的。今天將Big TCP支援增加到eBPF和Cilium中意味著它可用於那些大規模使用者，即使大多陣列織尚未準備好使用。

eBPF跨平台標準化的意義

eBPF從Linux核心的一個功能發展成為一個獨立的技術平台，這一轉變具有深遠的意義。基金會的建立不僅促進了技術的發展，還為跨平台標準化鋪平了道路。

Windows上的eBPF支援展示了這項技術的靈活性和適應性。儘管兩個作業系統在內部實作上有顯著差異，但核心網路處理的基本原則是相似的。這種共通性使得eBPF能夠在不同平台上提供一致的程式設計模型。

對於開發者來說，這意味著他們可以開發一次，佈署在多個平台上。對於企業使用者來說，這提供了更一致的安全性和可觀測性工具，無論他們的基礎設施是根據Linux還是Windows。

隨著eBPF持續演進，我們可以期待看到更多創新使用案例的出現，以及更廣泛的行業採用。eBPF已經從一個簡單的封包過濾機制發展成為現代基礎設施可觀測性、安全性和網路的關鍵技術，其影響力將繼續擴大。

eBPF：從核心功能到應用平台的演進

eBPF (extended Berkeley Packet Filter) 作為一項革命性技術，已經從最初的網路封包過濾工具演變為一個強大的通用平台。由於eBPF允許動態調整核心程式碼，它能夠在實際執行環境中解決各種問題，從核心漏洞緩解到支援人機介面裝置，如滑鼠、鍵盤和遊戲控制器。這種靈活性使eBPF成為現代基礎設施工具的重要根本。

eBPF是平台而非單一功能

近十年前，容器技術是熱門的新技術，幾乎所有人都在討論它的特性和優勢。如今，eBPF也處於類別似階段，大量的會議演講和部落格文章都在讚揚eBPF的好處。容器現在已經成為許多開發者日常工作的一部分，無論是使用Docker在本地執行程式碼，還是將程式碼佈署到Kubernetes環境。那麼，eBPF是否也會成為每個人常規工具箱的一部分呢？

我認為答案是否定的——至少不是直接使用。大多數使用者不會直接編寫eBPF程式或使用bpftool等工具手動操作它們。但他們會經常與根據eBPF構建的工具互動，無論是用於效能測量、除錯、網路、安全、追蹤，還是其他許多使用eBPF實作的功能。使用者可能不知道他們正在使用eBPF，就像他們可能不知道當使用容器時，實際上是在使用名稱空間和控制群組等核心功能。

目前，瞭解eBPF的專案和供應商會強調他們使用eBPF，因為它非常強大並暗示著許多優勢。隨著根據eBPF的專案和產品獲得更多關注和市佔率，eBPF正在成為基礎設施工具的事實標準技術平台。

eBPF程式設計知識是並將繼續是一項搶手但相對罕見的技能，就像今天的核心開發比起開發商業應用程式或遊戲要少見得多。如果你喜歡深入研究系統底層並希望構建基本的基礎設施工具，eBPF技能將對你大有裨益。

eBPF技術資源與社群

eBPF社群提供了豐富的資源，幫助開發者深入學習和應用這項技術：

關鍵學習資源

eBPF生態系統中有許多寶貴的資源可供學習和參考：

  1. eBPF社群網站 (ebpf.io) - 提供最新的eBPF新聞、檔案和資源
  2. Cilium檔案中的BPF和XDP參考 - 詳細的技術檔案和使用
  3. Linux核心檔案 - 官方BPF相關檔案
  4. Brendan Gregg的網站 - 專注於使用eBPF進行效能分析和可觀測性
  5. Andrii Nakryiko的網站 - 提供關於CO-RE和libbpf的深入資訊
  6. Lwn.net - Linux核心更新的優秀資源，包括BPF子系統
  7. Elixir.bootlin.com - 可瀏覽Linux原始碼的網站
  8. eCHO - 每週直播，涵蓋eBPF和Cilium社群的各種主題

這些資源能幫助開發者從不同角度理解eBPF，從基礎概念到高階應用，為實際開發提供重要參考。

eBPF技術應用領域與實踐

eBPF的應用範圍非常廣泛，已經在多個技術領域展現出強大的能力：

網路監控與最佳化

在網路領域，eBPF提供了前所未有的可見性和控制能力：

SEC("xdp")
int network_monitor(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;
    struct ethhdr *eth = data;
    
    // 確保我們可以存取乙太網路標頭
    if (data + sizeof(*eth) > data_end)
        return XDP_PASS;
    
    // 分析封包並記錄統計資料
    bpf_map_update_elem(&packet_stats, &eth->h_proto, &increment, BPF_ANY);
    
    return XDP_PASS;
}

這段程式碼展示了一個基本的XDP程式，用於監控網路流量。它從傳入的封包中提取乙太網路標頭訊息，然後更新一個對映表來記錄不同協定型別的封包數量。XDP (eXpress Data Path) 是eBPF的一個特殊應用，它允許在網路封包到達作業系統網路堆積積疊之前處理這些封包，提供極高的效能。

安全監控與防護

eBPF已成為現代安全解決方案的核心元件，尤其是在雲原生環境中：

SEC("lsm/bprm_check_security")
int BPF_PROG(restrict_exec, struct linux_binprm *bprm) {
    char comm[16];
    bpf_get_current_comm(&comm, sizeof(comm));
    
    // 檢查程式名稱
    if (bpf_strncmp(comm, "suspicious_app", sizeof("suspicious_app")) == 0) {
        // 記錄嘗試並阻止執行
        struct event e = {0};
        e.pid = bpf_get_current_pid_tgid() >> 32;
        bpf_probe_read_str(&e.comm, sizeof(e.comm), comm);
        bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &e, sizeof(e));
        return -EPERM;
    }
    
    return 0;
}

這個範例展示瞭如何使用eBPF的LSM (Linux Security Module) 掛鉤來監控和限制程式執行。當系統嘗試執行一個程式時，這段程式碼會檢查程式名稱，如果比對到被標記為可疑的應用程式，它會記錄這次嘗試並阻止執行。這種即時防護機制可以有效防止未授權程式的執行，是零信任安全架構的重要組成部分。

效能分析與追蹤

eBPF提供了強大的工具來分析系統效能和追蹤程式行為：

SEC("tracepoint/syscalls/sys_enter_open")
int trace_open(struct trace_event_raw_sys_enter *ctx) {
    u64 id = bpf_get_current_pid_tgid();
    u32 pid = id >> 32;
    
    // 僅追蹤特定程式
    if (target_pid != 0 && target_pid != pid)
        return 0;
    
    // 取得檔案路徑
    char filename[MAX_FILENAME_LEN];
    bpf_probe_read_user_str(filename, sizeof(filename), (char *)ctx->args[0]);
    
    // 記錄開檔事件
    struct event e = {
        .pid = pid,
        .timestamp = bpf_ktime_get_ns(),
    };
    bpf_probe_read_kernel(&e.comm, sizeof(e.comm), current->comm);
    bpf_probe_read_user_str(e.filename, sizeof(e.filename), (char *)ctx->args[0]);
    
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &e, sizeof(e));
    return 0;
}

這段程式碼展示瞭如何使用eBPF追蹤系統呼叫，特別是open()呼叫。它會捕捉程式開啟檔案的操作，記錄程式ID、時間戳、程式名稱和被開啟的檔案路徑。這種追蹤能力對於理解應用程式行為、診斷效能問題和檢測異常活動非常有價值。透過eBPF，這種追蹤可以在生產環境中進行，幾乎不會影響系統效能。

eBPF與現代基礎設施的融合

eBPF已經深度融入現代雲原生基礎設施，尤其是在Kubernetes環境中：

在Kubernetes中的應用

Kubernetes環境中，eBPF可以替代傳統的iptables，提供更高效的網路策略實施：

SEC("cgroup/connect4")
int trace_connect_v4(struct bpf_sock_addr *ctx) {
    // 取得目標IP和連線埠
    struct sockaddr_in *addr = (struct sockaddr_in *)&ctx->user_ip4;
    __u32 ip = addr->sin_addr.s_addr;
    __u16 port = addr->sin_port;
    
    // 檢查是否允許連線
    struct policy_key key = {
        .ip = ip,
        .port = port
    };
    
    __u32 *action = bpf_map_lookup_elem(&policy_map, &key);
    if (action && *action == POLICY_DENY) {
        // 記錄並阻止連線
        return 1; // 阻止
    }
    
    return 0; // 允許
}

這個範例展示瞭如何使用eBPF實作網路策略。它掛鉤到控制群組(cgroup)的connect系統呼叫，檢查每個嘗試建立的TCP連線。透過查詢預先設定的策略對映表，程式可以決定是允許還是阻止連線。在Kubernetes中，這種方法可以替代傳統的iptables規則，提供更高效與更細粒度的網路策略控制。

可觀測性與監控

eBPF為系統和應用程式提供了深度的可觀測性：

SEC("tracepoint/sched/sched_process_exec")
int trace_exec(struct trace_event_raw_sched_process_exec *ctx) {
    struct event e = {0};
    e.pid = bpf_get_current_pid_tgid() >> 32;
    e.ppid = bpf_get_current_task()->real_parent->tgid;
    e.uid = bpf_get_current_uid_gid() & 0xFFFFFFFF;
    e.timestamp = bpf_ktime_get_ns();
    
    // 取得命令名稱和引數
    bpf_get_current_comm(&e.comm, sizeof(e.comm));
    
    const char *filename = BPF_CORE_READ(ctx, filename);
    bpf_probe_read_str(&e.filename, sizeof(e.filename), filename);
    
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &e, sizeof(e));
    return 0;
}

這段程式碼追蹤系統中所有程式執行事件，記錄程式ID、父程式ID、使用者ID、時間戳、命令名稱和執行的檔案路徑。這種全系統的可觀測性使維運人員和開發者可以深入瞭解系統行為，快速識別問題並進行故障排除。特別是在微服務架構中，這種能力尤為重要，因為它可以提供跨服務的追蹤和監控。

eBPF開發實踐與最佳做法

要有效地使用eBPF，開發者需要了解一些關鍵的實踐和模式：

CO-RE (Compile Once, Run Everywhere)

CO-RE是eBPF開發的重要進步，它解決了eBPF程式的可移植性問題：

/* 使用BTF型別訊息和CO-RE重定位 */
SEC("fentry/do_sys_open")
int BPF_PROG(trace_open, struct pt_regs *ctx, int dfd, const char *filename, int flags)
{
    struct task_struct *task = (struct task_struct *)bpf_get_current_task();
    pid_t pid = BPF_CORE_READ(task, pid);
    
    if (target_pid != 0 && target_pid != pid)
        return 0;
    
    char comm[TASK_COMM_LEN];
    bpf_get_current_comm(&comm, sizeof(comm));
    
    char fname[MAX_FILENAME_LEN];
    bpf_probe_read_user_str(fname, sizeof(fname), filename);
    
    struct event e = {
        .pid = pid,
        .timestamp = bpf_ktime_get_ns(),
    };
    
    __builtin_memcpy(e.comm, comm, sizeof(comm));
    __builtin_memcpy(e.filename, fname, sizeof(fname));
    
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &e, sizeof(e));
    return 0;
}

這個範例展示了CO-RE (Compile Once, Run Everywhere) 技術在eBPF中的應用。透過使用BPF_CORE_READ巨集和BTF (BPF Type Format) 型別訊息，程式可以在不同版本的Linux核心上執行，而不需要為每個核心版本重新編譯。這解決了eBPF程式的一個主要挑戰——核心結構體在不同版本間的變化。CO-RE使eBPF程式更容易分發和佈署，大提高了開發效率。

使用libbpf簡化開發

libbpf是一個強大的函式庫，它簡化了eBPF程式的開發和載入：

// 使用者空間程式碼使用libbpf載入eBPF程式
int main(int argc, char **argv) {
    struct ring_buffer *rb = NULL;
    struct open_tracer_bpf *skel;
    int err;
    
    // 設定libbpf日誌回呼
    libbpf_set_print(libbpf_print_fn);
    
    // 開啟BPF程式
    skel = open_tracer_bpf__open();
    if (!skel) {
        fprintf(stderr, "Failed to open BPF program\n");
        return 1;
    }
    
    // 設定程式引數
    skel->rodata->target_pid = target_pid;
    
    // 載入並驗證BPF程式
    err = open_tracer_bpf__load(skel);
    if (err) {
        fprintf(stderr, "Failed to load BPF program: %d\n", err);
        goto cleanup;
    }
    
    // 附加BPF程式
    err = open_tracer_bpf__attach(skel);
    if (err) {
        fprintf(stderr, "Failed to attach BPF program: %d\n", err);
        goto cleanup;
    }
    
    // 設定環形緩衝區用於事件處理
    rb = ring_buffer__new(bpf_map__fd(skel->maps.events), handle_event, NULL, NULL);
    if (!rb) {
        fprintf(stderr, "Failed to create ring buffer\n");
        goto cleanup;
    }
    
    printf("Successfully started! Tracing open syscalls...\n");
    
    // 主事件迴圈
    while (running) {
        ring_buffer__poll(rb, 100);
    }
    
cleanup:
    ring_buffer__free(rb);
    open_tracer_bpf__destroy(skel);
    return err ? 1 : 0;
}

這段使用者空間程式碼展示瞭如何使用libbpf函式庫載入和管理eBPF程式。libbpf提供了一套API，使開發者可以更輕鬆地處理eBPF程式的生命週期，包括開啟、載入、附加和銷毀。特別是，它支援BPF骨架(skeleton)，這是一種自動生成的程式碼，可以簡化eBPF程式和對映表的存取。骨架程式碼提供了型別安全的API，減少了錯誤並提高了程式碼可讀性。

eBPF的未來發展與趨勢

eBPF技術仍在快速發展，未來幾年可能會出現許多新的應用和改進：

跨平台支援

雖然eBPF最初是為Linux開發的，但它正在擴充套件到其他平台：

// 跨平台eBPF程式範例 (概念性程式碼)
SEC("xdp")
int cross_platform_monitor(struct xdp_md *ctx) {
    // 平台無關的程式碼
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    
    // 使用通用抽象層處理封包
    struct generic_eth_hdr *eth = data;
    if (data + sizeof(*eth) > data_end)
        return XDP_PASS;
    
    // 平台特定處理透過編譯時條件實作
#ifdef __linux__
    // Linux特定程式碼
#elif defined(_WIN32)
    // Windows特定程式碼
#else
    // 其他平台
#endif
    
    return XDP_PASS;
}

這個概念性例子展示了eBPF程式如何設計為跨平台執行。雖然目前eBPF主要用於Linux，但像「eBPF for Windows」這樣的專案正在將eBPF功能帶到Windows平台。未來，我們可能會看到更多的平台支援eBPF，這將使開發者能夠編寫一次程式碼，在多個作業系統上執行。這種跨平台能力對於構建一致的監控、網路和安全解決方案特別有價值。

擴充套件到新的應用領域

eBPF正在擴充套件到新的應用領域，包括邊緣計算和IoT裝置：

// 邊緣裝置上的eBPF應用範例
SEC("tc")
int edge_device_monitor(struct __sk_buff *skb) {
    // 低資源環境最佳化的程式碼
    __u32 cpu_usage = 0;
    __u32 memory_usage = 0;
    
    // 收集裝置資源使用情況
    bpf_probe_read(&cpu_usage, sizeof(cpu_usage), &global_cpu_usage);
    bpf_probe_read(&memory_usage, sizeof(memory_usage), &global_memory_usage);
    
    // 根據資源情況做出決策
    if (cpu_usage > CPU_THRESHOLD || memory_usage > MEMORY_THRESHOLD) {
        // 節流或拒絕處理
        return TC_ACT_SHOT;
    }
    
    // 正常處理
    return TC_ACT_OK;
}

這個範例展示了eBPF如何應用於資源受限的邊緣裝置。透過監控CPU和記憶體使用情況，程式可以做出人工智慧決策，例如在資源壓力大時減少網路流量處理。隨著IoT和邊緣計算的普及，eBPF的低開銷和高效能特性使其成為這些環境中理想的技術。未來，我們可能會看到專門為邊緣裝置最佳化的eBPF工具和框架。

結語

eBPF已經從一個專門的技術演變成為現代基礎設施工具的關鍵平台。雖然大多數使用者不會直接編寫eBPF程式，但他們將越來越多地使用建立在eBPF之上的工具和產品，無論是用於效能測量、除錯、網路、安全還是追蹤。

eBPF的強大之處在於它能夠安全地擴充套件核心功能，而無需修改核心程式碼或載入核心模組。這種能力使開發者能夠建立前所未有的工具，提供深度的系統可見性和控制能力。隨著容器和Kubernetes成為許多開發者日常工作的一部分，eBPF也在逐漸成為基礎設施工具的事實標準技術平台。

對於那些喜歡深入研究系統底層並希望構建基本基礎設施工具的開發者來說，掌握eBPF技能將是一項寶貴的投資。隨著技術的不斷發展和新應用領域的開拓，eBPF的重要性只會繼續增長，成為現代系統程式設計中不可或缺的一部分。

無論你是系統管理員、網路工程師、安全工作者還是應用開發者，瞭解eBPF及其能力都將幫助你更好地理解和利用現代Linux系統的強大功能。eBPF不僅是一項技術，它代表了一種新的系統程式設計正規化，正在改變我們構建和管理基礎設施的方式。 在現代網路與系統工程領域，eBPF技術已成為一項革命性的技術創新，它徹底改變了我們監控、除錯和最佳化Linux系統的方式。透過本文的探討，我們瞭解到eBPF如何在不修改核心程式碼的情況下，安全地執行自定義程式，實作前所未有的可觀測性與效能最佳化。

eBPF技術最令人印象深刻的是它的多功能性與高效能。從網路封包過濾到系統呼叫追蹤，從安全策略實施到效能分析，eBPF幾乎可以應用於任何需要深入系統核心的場景。現代雲原生應用與微服務架構的複雜性，使得eBPF成為解決當代系統工程挑戰的關鍵工具。

在實際應用中，eBPF已經被證明能夠顯著提升系統可觀測性、安全性與效能。無論是Cilium這樣的容器網路解決方案，還是Falco等安全監控工具，都充分展示了eBPF的強大潛力。隨著工具生態系統的不斷成熟，eBPF的應用門檻也在逐步降低，使更多開發者能夠利用這一技術解決實際問題。

eBPF技術仍在快速發展中。隨著更多高層抽象工具的出現，以及社群持續的創新，我們可以預見eBPF將在更廣泛的領域發揮作用。對於任何關注系統效能、安全性與可觀測性的技術專業人士來說，掌握eBPF已經成為一項不可或缺的技能。

技術的價值最終體現在解決實際問題的能力上。eBPF正是這樣一項技術，它賦予開發者前所未有的能力，讓我們能夠以更靈活、更高效的方式理解和最佳化複雜系統。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。