[eBPF Japan Meetup#8] eBPF Updates

eBPF Updatesという最近のeBPFの与太話をする回です。
今回はプラハで行われた、eBPF'26のWorkshopの話と、SOSP、LPCに参加してきた話とRecapをします。

Transcript

1. Cloud Native Community Japan - eBPF Japan Meetup #8 eBPF Updates Takeru Hayasaka ( @takemioIO ) eBPF Japan Meetup Co-Org & SAKURA Internet Inc. <ta-hayasaka@sakura.ad.jp> Nov 06, 2026
2. Whoami • 早坂 彪流 (Hayasaka Takeru|@takemioIO) • Senior Software Engineer at SAKURA internet Inc. ◦ さくらインターネット研究所に所属 ◦ NWとSystemSoftware領域の研究などをしている • My favorite eBPF Helper Func is bpf_fib_lookup • Co-Organizer of the eBPF Japan Meetup 2
3. eBPF Updatesとは? • 目的: 比較的最近のeBPF関連のトピック共有をする場 ◦ a.k.a. アレンジ担当者が独断と偏見で良かった物や気になった物を話すコーナー • 狙い ◦ eBPF 関連の色々なトピックを話の種に休憩時間や懇親会などでネタにしてもらう • 今回は SOSP 2026 & eBPF’26 + LPCに参加したので、そっち方面のeBPFに関 する話を中心にゆるーくご紹介 3
4. (初心者向けスライド )そもそも eBPFってなんだっけ？ 手前味噌ですが、こちらのリンクの前半がなんとなくわかった気になれます https://speakerdeck.com/takehaya/ebpf-deep-dive-architecture-and-safety-mechanisms 4
5. SOSP 2026 & eBPF’26 in Prague • SOSP 2026(The Symposium on Operating Systems Principles) というOS系トップカンファレンス ◦ 今年で36回目の歴史ある由緒正しいカンファレンス ◦ 1000本近く応募が来て、ダブルブラインドプロセスに加えて、最後に面談が発生する(!?)とい う難関カンファレンス • eBPF’26 (4th Workshop on eBPF and Kernel Extensions) というeBPF に関するトピックのワークショップ, co-located SOSPだった ◦ 今までSIGCOMMがスポンサーだったのが、今年からSIGOpsに変更された ▪ ついでに論文フォーマットも変わって土壇場で大変焦るハメになった ◦ 今年初めて日本人がTPCでの参加や採択論文に ▪ Yutaro Hayakawa(Isovalent at Cisco), Michio Honda(University of Edinburgh) ▪ Kunai: Toward a Verifier-Safe Layered DSL for Nested Encapsulation Packet Filtering on eBPF <= この論文を書いて採択されたので参加してきました 5
6. SOSP 2026 のスケジュール • 4日間行われ、1日目がWorkshop、2-4日目がSOSP本会議 • Workshopは複数行われて、HotStorageやPLOSなどが同時に開催された eBPF’26はその中の一つで開催された https://sigops.org/s/conferences/sosp/2026/workshops.html 6
7. eBPF’26 のスケジュール Verification, NW+GPU Comm BPF Perf, CPU Sched の4テーマでの 発表が1日かけて行われた 7
8. SOSP2026の様子 今年のベストペーパーの発表の様子とスメタナホールでの晩餐会の様子 本会議はシングルトラックなのでかなり大盛況だった 8
9. eBPF’26の様子 割とこじんまりした会議室での実施 まさかのマイク無しのスタイルでの発表😇 Peer-Review Process的には全投稿の平均の総合評価点 は2.65。点数の範囲（1〜5）で4割ぐらいの採択率 9
10. SOSP It’s the Kernel’s Fault!Custom Page Fault Handling With bpf_fault • linuxのuser defineのpage faultをする 仕組み(uffd)が遅いのでstruct ops を使ってebpf でカーネル内部で解決しようぜ！ page faultするアプリのワークロードごとに プログラマビリティがあるといいことがある！という 主張の論文 • 例えばVMLiveSnapshot (write-protect fault) ではページをeBPF Ringbufにコピーしておいて、 別プロセスで任せる。 従来は毎回uffdを呼んで待つ作業が出てたがそ れが回避できるようになり6-7倍改善 https://dl.acm.org/doi/10.1145/3830418.3843896 10
11. SOSP Scheduling Linux Threads under I/O Chiplet Wall Using cSwitch - 全てのコアがメモリやデバイスにアクセスしても 必ずI/Ochipletを経由するのでそこがボトルネッ クになる=>ボトルネックの結果コアあたりの実効 帯域を下げてしまう - EEVDFはCPU時間の公平性だけしかみてない =>CPUスケジュールはフロースケジュールとして 問題として解釈し直せるのでは？ - cFlow: 通信特性の注釈がついたデータフローと して計算した結果をsched_ext経由で実現する ことで解決→Max 2.7倍高速化された - CPU schedをNetworkの技術で解決してるの が面白い https://dl.acm.org/doi/10.1145/3830418.3843889 11
12. eBPF’26 XDP_CLONE: Efficient In-Driver Packet Duplication for eBPF-Accelerated Systems - 従来XDPのレイヤーで素直にパケットクローンをすると全部同一のコピーになってしまう問題 がある。（BPF_F_BROADCAST）そのためTCまでパケットを飛ばしてbpf_clone_redirectで実 現するワークアラウンドが知られていた。 - XDPでも柔軟なクローンを作れる機能を追加した - XDP_CLONE_PASS(n): 元のパケットはスタックへ渡し、n個の複製を作る。 - XDP_CLONE_TX(n): 元のパケットを同じNICから再送し、n個の複製を作る。 - 便利な実装をだと思うが、個人的にはBPF_F_BROADCAST+Devmapを組み合わせたらほぼ 同じことができるので、便利なエンジニアリングなのではないかという気持ちもある。 - その話で最近ブログ書いてみた https://takeio.hatenablog.com/entry/2026/10/26/220402 cf. https://github.com/Warcophyr/XDP_CLONE https://dl.acm.org/doi/pdf/10.1145/3837779.3838159 12
13. eBPF’26 NCCLbpf: Verified, Composable Policy Execution for GPU Collective Communication - NCCLというGPUの集団通信用ライブラリがあり（大規模な機械学習に使われる）、これらは様々なプ ラグインでアルゴリズムやプロトコルなどの挙動をカスタマイズができ、それらはNCCLのアドレス空間 でネイティブコードとしてロードされる(dlopenでso lib)=>が、サンドボックス検証などもないのでnull参 照一発あると学習ジョブ全体がクラッシュしてしまう - 修正のためにはポリシーやプラグインをFixして全てにばら撒く必要がありコストが高い - そこでeBPFをuserlandで動かすbpftimeをリンクさせて、bpftime越しにeBPFとしてpluginを実現さ せることで安全にVerifierを通じて利用できるようにした https://dl.acm.org/doi/10.1145/3837779.3838156 13
14. 4th Workshop on eBPF and Kernel Extensions (eBPF) Kunai: Toward a Verifier-Safe Layered DSL for Nested Encapsulation Packet Filtering on eBPF 1, 2 1 3 Takeru Hayasaka, Satoshi Uda, Ayako Hayasaka, Daisuke Kotani 1 3 4 2 japan Advanced Institute of Science and Technology, SAKURA Internet Inc, 4 Independent Researcher, Kyoto University 自分の研究もちょっと紹介...😄 https://github.com/takehaya/bpf-ninja ぜひリポジトリに⭐お願いします Sep 29, 2026
15. Example: Read the destination IP of UE traffic Investigate one SIMʼs session, Known UE (User Equipment) IPv4: 10.0.0.1 Capture downlink TCP traffic to this UE inside GTP-U. 4G/LTE: Basic GTP-U (no optional fields) A outer IPv4 UDP GTP-U base 8B Inner IPv4 dst = 10.0.0.1 TCP 5G: GTP-U with extension hdr (PSC: PDU Session Container, DL case) B outer IPv4 UDP GTP-U base 8B Opt 4B PSC 4B QFI Inner IPv4 dst = 10.0.0.1 TCP Inner IPv4 starts 8 B late Monitoring LTE/5G roaming interfaces also requires handling packets with extensions* => Optional fields and extensions shift the inner IP header even when the destination stays the same! *3GPP TS 23.501, TS29.281 15
16. Problem: Nested headers make fixed offsets hard to maintain pcap-filter is the de facto capture-filter language used by tcpdump/libpcap.* It has no named GTP-U inner fields, so these examples use hand-written offsets A: Basic GTP-U B: 5G with PSC udp dst port 2152 and udp dst port 2152 and udp[25] = 6 and udp[33] = 6 and udp[32:4] = 0x0a000001 udp[40:4] = 0x0a000001 Offsets from UDP start, 6 == TCP , 0x0a000001==10.0.0.1 For these two layouts, A and B can be combined with “or” . But changes to GTP-U extensions or other encapsulation headers can move the target fields => Update the offset expressions whenever the target fields move… *pcap-filter(7)man:https://raw.githubusercontent.com/the-tcpdump-group/libpcap/libpcap-1.10.5/pcap-filter.manmisc.in 16
17. Proposal: Kunai, a DSL that computes field positions GTP-U: Filter downlink TCP traffic to a specific UE at 10.0.0.1 eth/ipv4@outer/udp/gtp/ipv4@inner/tcp where inner.dst == 10.0.0.1 Same condition across the supported GTP-U layouts🙆 SRv6: Filter packets whose segment list contains Router R's SID, fc00::1 eth/ipv6/srv6 where any(srv6.segments.addr == fc00::1) Match R's SID anywhere in the segment list that filtering 🙆 List A: [fc00::a, fc00::1] List B: [fc00::a, fc00::b, fc00::1] R SID is 2nd in A and 3rd in B. The same filter matches both packets! 17
18. Kunai DSL: High-Level Architecture Filter Expression layer chain + field predicate Kunai Compiler parser resolve Generated Bytecode match / reject embed P4 protocol definitions header layout + parser rules codegen from definitions recorded bases bounded walks Host BPF Program XDP / TC / Tracing capture, drop, pass Kunai compiles a filter expression and P4 protocol definitions into eBPF bytecode that returns match or reject. Embed the generated filter in XDP, tc, or tracing programs. The host provides packet access and handles the match result. 18
19. Linux Plumbers Conference(LPC) in Prague • Linux Plumbers Conference (LPC)というLinuxの開発者会議 • 毎回チケットが爆速で売り切れることで知られてる • 今年はOSS EUなどのイベントと同じ会場で共催だった （まぁ同じLFですからね） • 今年は日本人が（おそらく）2人ほど発表(Networking Track等) • eBPF Trackというのが2日に渡って実施されていたのでそこからピックアップ 19
20. LPCの様子 マイクのところまで歩くのではなく、サイコ ロ型のマイクを欲しい人が取り合ってディ スカッションをする方式 20
21. LPCの様子: eBPF Track 今年のeBPF Trackはなんとなく （主観）大きく二つの話が多かった 1. Rust for BPFの話 2. BPFを利用したセキュリティっぽい話 21
22. Rust-BPF updates - Rustcが使えるものはVerifierも問題なく通せるようにする というためのいろいろな膨大な作業の話 - 改造していない rustc とpureなcore / alloc(BTreeMap, dyn Trait, Drop, panic)を BPF で動かすことが 目標。→型のミスマッチ、panicのケア、1Mを超えてしまう等の課題が... - 目的: プログラマのミスを見つけるのは rustc の仕事にしたい - verifier は出来るだけセキュリティ境界としての検査(ロック、参照、RCU、kfunc の型)に専念させたいみ たいな気持ちがあるらしい - 質疑で出てきた元来の目的 - 元々はAI AgentがまともなCをかけないのでRustのようなより抽象化の効いたモダンな言語でやれるよう にしたいという話があったが、最近は賢くなったのでCが書けるようになった。が、普通にやり始めたら Rustめっちゃ便利なのでそれに投資したくなった！ということらしい... - verifierの仕組みを抽象解釈的な方法に寄せることで、1Mを超える制限に取り組もうとしてる！ - つまり全部のパスを辿らなくてもいいような手法が検討されている https://lpc.events/event/20/contributions/2439/ 22
23. shirudo: BPF live-patching infra for the agentic era - 問題: CVE 修正は1日約33件。再起動を伴う配備は遅く、BPF LSM で緩和した CopyFail ですら全 台展開に26〜30時間かかった。LLM を使う攻撃者には遅すぎる - 提案: 常駐エージェントなしの BPF セキュリティ基盤。 LLM が CVE ごとに BPF プログラムを生成・署名して配布する仕組み - 仕組み - 対策は署名付き BPF の束（upatch）で、LSM フックや kprobe にアタッチして攻撃を検知、また は入口でブロックする（コードは書き換えない） - 起動時に BPF LSM で bpf(2) を検査し、自身の資産は security.bpf.shirudo xattr で封印して root からも守る - 予備実験: LLM に489件の CVE の検知器を生成させた - 317件がロードされ、再現テストで検知できた - 失敗: モジュールなし89件、verifier 拒否34件、インライン化22件など,緩和まで検証できたのは 30件のみ。手前で広くブロックするため副作用が大きく（例: CopyFail はソケット作成ごと止める） https://lpc.events/event/20/contributions/2437/ 23
24. Application-Layer Parsing in eBPF - 問題: Cilium や Hubble などは L7 の処理を eBPF でやるのは複雑である - HTTP/1.1:データの位置を探すのに状態が要る(大 or 小文字を区別しない、空白文字など) - HTTP/2:HPACK の可変長の型と長さを解読する必要がある - 提案: DFAをユーザー空間で作ってカーネルではそれを辿る仕組みを作る - つまるところ、複雑な正規表現みたいなのを作っておくイメージ - 大文字小文字や空白の揺れは、DFA の遷移を増やすだけで吸収できる - e.g. content-length と content-type なら、共通の content- の部分は同じ状態を共有 して、そこから枝分かれするイメージ - HTTP/2 はデコードせずに、エンコードされたまま照合する - 仕組み: ユーザーランドで欲しいパースの構成を作ったらBPFに変換して、freplace経由で ねじ込むことで実現 - だいぶフツーに使うにはしんどい実装ではある...😇 jsonとかは無理そう。パスベースな ルーティングとかに採用とか...？(サービスメッシュの L7 ポリシーで元論文は使ってる https://lpc.events/event/20/contributions/2428/ 24
25. eBPF Research: What's Going On In Academia? - CSRankings に載っているトップ会議の BPF 論文だけを集めて、 BPF がアカデミアでどう使われてるのかを調べた話 - BPF を「使う」研究 - 拡張: ページフォルト、ロック、DBMS、QUIC、BGP など - オフロード: Memcached、Paxos、L7 LB、NIC への移植 - 実装: OVS、サービスメッシュ、トレーシングや計測系、IDPS - BPF を「改善する」研究 - 検証:PCC、PREVAIL、Rust - バグ探し:fuzzing、形式検証(Agni など) - 性能:コンパイラ、合成 - upstreamには研究成果の一部がverifierとかJIT関連として割と入ってる https://lpc.events/event/20/contributions/2427/ 25
26. まとめ - SOSP 2026( focus ebpf ) & eBPF’26 + LPCのrecapをしました - eBPF のイマドキトレンドを少しでもお届けできたら幸いです :-) 26