本刊物旨在為中文使用者提供及時、深入、有態度的 ebpf 資訊。
如果你吃了雞蛋覺得好吃，還想認識下蛋的母雞，歡迎關注：
筆者的 twitter：https://twitter.com/spacewand...
Merbridge 成為 CNCF sandbox 專案
Istio、Linkerd、Kuma 這三個專案除了都是 service mesh 之外，還有什麼共同點？
它們都可以透過 Merbridge 加速！
Merbridge 是一個旨在透過 ebpf 代替 iptables，給 service mesh 加速的專案。作為成立剛滿一週年的新專案，Merbridge 已經應用到 kuma 的官方版本當中。最近 Merbridge 又達到了另外一個里程碑 —— Merbridge 正式成為 CNCF sandbox 專案。
從 Merbridge 提交給 CNCF 的維護者列表來看，目前該專案背後是由 DaoCloud 推動的，半數維護者來自於該公司。不過由於 Merbridge 的位置偏向於底層元件，我們還是可以相信該專案的中立性。想必該專案的創立之初是為了加速 istio，後來也被 kuma 等非 istio 的 service mesh 所採納。
在使用 Merbridge 進行一鍵加速之前，一個典型的 service mesh 的網路通訊是這樣的：
Merbridge 使用了 ebpf 的 SOCKMAP 功能，在 socket 層面上完成包的轉發，繞過其他彎彎繞繞的路線。
在採用 Merbridge 之後，sidecar 和 app 之間的路徑能夠顯著縮短：
在 Readme 上，Merbridge 把這種變化比喻成穿過了愛因斯坦-羅森橋（蟲洞），倒是挺貼切。
SkyWalking Rover：使用 eBPF 提升 HTTP 可觀測性 - L7 指標和追蹤
https://skywalking.apache.org...
提供及時的抓包資訊一直是做接入層的程式設計師的剛需。在筆者的上上家公司，就有同事使用 pcap 實現了可以互動式抓包的後臺服務。Elastic 公司也有個開源專案 packetbeat 支援透過 pcap 或者 af_packet 來常態化抓包。
只支援純抓包的專案都有個限制，那就是無法跟使用者態的更多資訊有機結合起來。假設可以把使用者態的上下文容納入網路包的資訊中，前景將會大大拓寬。比如透過比較使用者態的讀寫方法和核心中實際的讀寫操作的時間差和資料量，使用者會對應用中的 buffering 情況有更深入的瞭解。抑或透過 hook 應用中的 TLS 操作，可以得到未加密的真實的請求內容。
ebpf 填充了純抓包和純使用者態的可觀測性之間的鴻溝。透過 ebpf，使用者能夠同時在 kprobe 和 uprobe 中記錄上下文，把兩者緊密結合在一起。
言歸正傳，SkyWalking Rover 的這篇文章，強調了它對 L7 協議的可觀測性。眾所周知，作為一個跑在核心態裡面、對執行方式有強約束的技術，想要在 ebpf 裡面實現完整的 L7 協議棧是一件很困難的事。那麼 SkyWalking Rover 是如何做到的？
SkyWalking Rover hook 了核心相關的函式，嗅探新連線的內容。它會讀取最開始的一段內容做分析，猜測其背後採用的協議。雖然有的協議需要更加複雜的處理方式，比如嗅探 websocket 需要剝開外面的 HTTP1 的殼。不過對於絕大多數協議，這樣就夠了。在完成基本的篩選後，它會把內容轉到使用者態，交給使用者態的解析程式來完成。使用者態的解析程式會完成完整的 L7 協議解析。
Caretta：輕量級的 k8s 服務呼叫網路視覺化工具
https://github.com/groundcove...
作為一個去年 11 月才開始開發的專案，Caretta 在最近一個月的 star 增長得飛快，不得不讓人佩服 groundcover 這家商業公司的宣發。
groundcover 是一家成立於 2021 年，基於 ebpf 做可觀測性的以色列 APM 廠商。Caretta 並非是他們產品的開源版，而是該公司開源出來的小工具。Caretta 是一個輕量級的 k8s 服務呼叫網路視覺化工具，能夠梳理叢集內不同應用之間的呼叫關係。這個工具透過 ebpf 獲取 Node 上各個連線的資訊，接著在使用者態藉助 k8s 的上下文把連線資訊翻譯成 k8s 的服務呼叫，然後透過 Prometheus 的標準介面把資訊暴露出來，最後提供了 Grafana 報表展示 Prometheus 採集到的服務呼叫資訊。畢竟是才開發了兩個月的專案，這個工具在 ebpf 方面的邏輯其實並不複雜，比較酷炫的展示，是透過 Grafana 來實現的。
如何應對 eBPF 帶來的新攻擊方式
https://redcanary.com/blog/eb...
ebpf 這麼強大，一定會有人把它應用到黑產上。本文提到了一些藉助 ebpf 進行不法行為的方式，並且給出若干加固的建議。
總結起來就兩條：
- defense in depth
- 如果不用，禁掉 ebpf 和/或 kprobe
對第一條展開說一下。由於 ebpf 能夠跑在核心態的，所以通常需要 root 許可權，或者 CAP_SYS_ADMIN / CAP_BPF（Linux 5.8 新加的）來跑。然而實際上非特權使用者也能跑 ebpf，只是有些功能會被限制。感興趣的讀者可以搜尋下“unprivileged ebpf”。但是，就像大家平時寫的程式碼，核心程式碼中也難免不會出現 bug，導致非特權使用者繞過限制的情況。
比如下面的部落格就分析了之前一個繞過 Linux ebpf verifier 的安全漏洞：https://stdnoerr.github.io/writeup/2022/08/21/eBPF-exploitation-(ft.-D-3CTF-d3bpf).html
所以考慮到非特權使用者執行 ebpf 是如此鮮見，我們大可透過設定 kernel.unprivileged_bpf_disabled 禁用該功能。我檢查了手上幾個 Linux 裝置，開發環境上 unprivileged ebpf 是啟用的，而兩臺 VPS 上 unprivileged ebpf 都是禁用的。較新的發行版預設就是禁用 unprivileged ebpf，見 https://www.kernel.org/doc/ht...。
即使設定了 root 才能跑 ebpf，也不代表高枕無憂。駭客們可以透過別的手段拿到 root 許可權，然後在 rootkit 裡面植入 ebpf 程式。還有一種思路是採用供應鏈攻擊，就像 log4j 一樣。不過考慮到目前好像沒有什麼應用能夠動態根據使用者輸入執行 ebpf 程式碼，而且 ebpf 也不能直接 import 別人的程式碼庫，在這一塊談供應鏈攻擊還尚早。
藉助 ebpf 的 rootkit 是跑在核心裡的，且許多 Linux 加固手段也是同樣應用在核心裡，看來彼此在核心中的鬥爭會是持久的攻防戰。