eBPFのこれまでとこれから

eBPFはネットワークソフトウェア開発の何を変えたか Yutaro Hayakawa Isovalent at Cisco

eBPFはネットワークソフトウェア開発の何を変えたか eBPFのこれまでとこれから Yutaro Hayakawa Isovalent at Cisco

自己紹介 • 早川侑太朗 (@YutaroHayakawa) • 所属: Isovalent @ Cisco •
肩書: Software Engineering Technical Leader

今日のお話 • eBPFが生まれた歴史的背景 • eBPFとは何か？何が嬉しかったのか？ • eBPFの今後

私とeBPF • 7年ほど大小様々な規模で eBPFを活用したネットワークソフトウェアの開発に従事 • 2017 - 2018: generic-ebpf (eBPF
for FreeBSD, GSoC’18) • 2017 - 2021: Prism (学生の頃からやっていた研究プロジェクト , NSDI’21) • 2019 - 2021: LINEの内製クラウドのロードバランサ開発 • 2020 - 現在 : ipftrace2 (個人OSS, トレーシングツール ) • 2022 - 現在 : IsovalentにてCiliumの開発 (2023年からCommitter)

Isovalent • 主にKubernetes向けのネットワーク・セキュリティ・オブザーバビリティのソリューションを開発する会社 • eBPFを作った人々の一部が創業した会社 • 全てのプロダクトが eBPFを使って作られてい
る • 現在は買収によりCiscoの一部

eBPFが生まれた歴史的背景

2011年頃: ネットワーク仮想化の隆盛 • 「ネットワーク仮想化」という概念が産学ともに大きなブームを巻き起こした • サーバが仮想化によって数秒 - 数分のオーダで簡単に作って壊せるものになった • ネットワークも仮想化によって同じように簡単に作って壊せるようにしたい
• 現在のクラウドネットワーキングやコンテナネットワーキングの基礎になる考え方

Any IP Network Niciraのネットワーク仮想化アーキテクチャ • 仮想ネットワークの機能をハイパーバイザ上のソフトウェアスイッチに実装する • LB, FW, NATのようなネットワーク機器もソフトウェア化し
APIで集中制御 • プログラムで簡単に作成・削除・制御できるように HV HV HV VM VM VM VM VM VM Distributed Firewall LB vxlan vxlan

ネットワーク仮想化の実装 • だいたい L2 - L4くらいの話 • スイッチ , ルータ,
LB, FWなどをソフトウェアで実装する • LinuxではL2-L4はカーネルの領分 • ここで新しいことをするにはカーネルプログラミングが必要ソフトウェア (ユーザ空間 ) ソフトウェア (カーネル空間 ) 物理 https://www.cloudflare.com/it-it/learning/ddos/glossary/open-systems-interc onnection-model-osi/

CrowdStrike事件 • 今年の7月19日に世界中の約 850万台のWindowsマシンが一斉にブルースクリーンになった • 原因は設定ファイルのたった一行の変更で引き起こされたカーネル拡張のクラッシュ
https://en.wikipedia.org/wiki/2024_CrowdStrike_incident#/media/File:CrowdStrike_BSOD_at_ LGA.jpg

CrowdStrike事件から学ぶカーネルプログラミングの難しさ • カーネル拡張を作ることは大きなリスクを伴う ◦ カーネルクラッシュをするとマシンが使用不能になる ◦ カーネルがリークしたメモリは誰も回収できない ◦ 無限ループやデッドロックをしたらマシン全体が使用不能に ◦
さらにLinuxはカーネル拡張に対してインターフェースの後方互換性を担保しない • このようなリスクに対するセーフティネットがほぼ無いのが従来のカーネルプログラミング

カーネル開発の硬直化 • カーネル開発はリスクが高いがために保守的にならざるを得ず硬直化していた • ビジネスの都合としては新しいことを押し進めたいのにカーネル開発のスピードが追いつかない • この問題の解決をめぐるアプローチで業界は 2つの派閥に分かれた

カーネルバイパス派 • Intel DPDKに代表されるカーネルをバイパスしてユーザスペースに全てのネットワーク機能を実装する派閥 • Pros: カーネル空間の開発と比較して安全なユーザ空間の開発は早い
• Cons: Linuxカーネルの枯れたスタックやアプリケーションなどのエコシステムに乗れない Kernel Driver Network Stack (LB, FW, NAT…) Applications (Routing Protocols) Kernel Driver Network Stack Applications Physical Kernel User NIC

カーネルネイティブ派 • Linuxカーネルの中に新たなプログラマビリティを持ち込む派閥 . Open vSwitchなどの開発を通じてプログラマブルなネットワークスタックを目指した .
• Pros: 既存のネットワークスタックやアプリケーションなど , カーネルの資産を生かすことができる • Cons: 硬直化の影響は依然としてある . 開発スピードは遅い . “Classic” Network Stack (iptables, ipvs …) Applications (Routing Protocols) Physical Kernel User NIC In-kernel Programmable Data Path (OVS, etc…) New CPlane Applications (OpenFlow, etc…)

カーネルネイティブ派 vs カーネルバイパス派 • 体感的には 2016年くらいまではカーネルバイパス派の優位が続いた ◦ 開発スピードの速さ ◦ コントリビューションのハードルの低さ
◦ etc… • Open vSwitchなどは盛り上がったが , 硬直化を打破するほどのプログラマビリティは得られず • その中でカーネル派の中から eBPFが登場 ◦ 「安全なカーネルプログラミング」でカーネル開発の硬直化を打破しようとする技術

eBPFとは？

eBPFとは？ Linuxカーネル拡張を書くためのプログラミングフレームワーク https://ebpf.io/what-is-ebpf

eBPFとは？ https://ebpf.io/what-is-ebpf

eBPFプログラミング C言語で書く (mainとかはない見慣れない C), ClangにeBPFバイトコードを吐くモードがある

eBPFプログラミング NICに入ってきたパケットの数を送信元 IPごとに数えるプログラム NIC Linux Network Stack NIC Device Driver
パケットの流れ

Load コンパイラから吐かれた「 ELFファイル」を bpfシステムコールに渡せる形にする工程詳しく知りたい方は => きっと明日から役立つ eBPFのしくみ

VerifierとJIT Compiler bpfシステムコールでロードされたプログラムは Verifierによって「検証」される =>「安全」でなければ実行できない検証が通ったらほとんどの場合 JITコンパイルされる => 実行前に全部ネイティブマシン命令に変換検証が共通化できるのが
eBPFバイトコードがアーキテクチャ非依存な理由

Hook カーネルの中で eBPFをアタッチして実行できる場所何かしらのイベントを契機に eBPFが実行される代表的なフック - Socket => socketに対するデータの入出力をフィルタする
- Syscall => システムコールの呼び出しをトレース・フィルタ - kprobe / ftrace => カーネルの関数呼び出しなどをトレース - TC / XDP => NIC入ったパケットを書き換え・ドロップ - TCPの輻輳制御 , スケジューラ , etc

eBPF Map eBPFプログラムとユーザ空間から読み書きできるデータ構造 => Hash, Array, Trie, Per-CPU Array, etc…
ユーザ空間と eBPFの情報のやりとりに使える

Helper Functions eBPFプログラムから外のカーネルの関数を呼び出す仕組みシステムコールのようなもの (ただし, コンテキストスイッチを伴わないただの関数呼び出し ) あらかじめ決められた関数しか呼べない Mapを読み書きする ,
タイムスタンプを取る , パケットをリダイレクトする , ルーティングテーブルを検索する , etc…

eBPF Core Conceptまとめ • ユーザは任意の eBPFプログラムを書いてカーネルにロードできる • カーネルはプログラムが安全かどうかを実行前にチェックする • eBPFプログラムは最終的にはネイティブコードに
JITされて実行される • Mapを使ってユーザスペースと eBPFでデータのやりとりができる • Helper Functionを使って外のカーネルの関数を呼べる

eBPFがあるカーネルプログラミング (1/2) • Verifierによるセーフティネット ◦ 危険な可能性のあるメモリアクセスはできない ◦ 取ったロックは全部のコードパスで解放されることが保証されなければならない ◦ ループは実行前に最大ループ数がわかっているケースでしかできない
◦ etc, etc, etc… • (例外はあるが ) 基本的に eBPFプログラムの後方互換性は担保されている

eBPFがあるカーネルプログラミング (2/2) • 開発者目線 ◦ 開発のフィードバックサイクルが早い ◦ コードの安全性は自動で検証されるので , よりプロダクトの本質的なところに集中できる
◦ 後方互換性があるのでメンテナンスしやすい • ユーザ目線 ◦ 開発が早い => 欲しいものが早く手に入りやすい ◦ カーネルモジュールで書かれた製品より低リスク

カーネルネイティブ派 vs カーネルバイパス派の決着はついた？ • カーネルバイパスの代表格である DPDKはISPやテルコなどの現場では健在 ◦ パフォーマンスが特に大事なワークロードではアドバンテージがある ◦ Cisco
VPPなどネットワークベンダの仮想ルータの実装にも使われている ◦ 比較的ニッチな分野で根強く支持されているという印象 • eBPFを含むカーネルネイティブな技術の方が現在は広く使われている ◦ 特にコンテナネットワーキングの分野では圧倒的に優勢 ◦ カーネルに元々組み込まれている => デフォルトの選択肢ということか？

eBPFの今後

CrowdStrike事件はeBPFがあれば防げた ? • CrowdStrikeもLinuxではeBPFを採用している • WindowsにeBPFがあれば今回のようなインシデントは防げたかもしれない https://en.wikipedia.org/wiki/2024_CrowdStrike_incident#/media/File:CrowdStrik e_BSOD_at_LGA.jpg

eBPF for Windows • eBPFをWindowsに移植するプロジェクト ◦ Byte CodeはLinuxコンパチ (コンパイラが流用可能 )
◦ プログラムの直接的な互換性はない ▪ Windows固有のフックやカーネルのデータ構造 • Microsoft主導でプロダクションで使えるレベルのものを本気で目指している • OSの垣根を超えて移植がされるというのは技術として有用性が認められた証左

IETFでの標準化 • eBPF for Windowsのメンバが中心となって eBPF ISAなどを標準化 • 違う実装同士の互換性を目指すというよりは ,
ある程度のコードの共通化が可能になるくらい • 現状実装に関心を示しているのは MSと一部のストレージ系のベンダ

eBPFの未解決問題 - eBPF Verifierのバグ - • 実はCrowdStrikeはLinuxでもeBPFがあるのにもかかわらずカーネルクラッシュのインシデントを起こしている. 原因はeBPF Verifierのバグ.
• eBPFのプログラムの安全性は Verifierによって検証されるが eBPFそのものの安全性は担保されない

eBPFの未解決問題 - Verifierのスケーラビリティ - • eBPF Verifierの検証には制限がかけられている • 検証に際限なく時間やメモリが使われるのを防ぐため •
Instruction Limit ◦ プログラム自体の最大インストラクション数 ◦ eBPFができた当初から変わらず 4096 • Complexity Limit ◦ 分岐やループも含めた検証のステップ数 ◦ eBPFができた当初は 4096, カーネル 5.4から1M (100万) • Ciliumのような巨大 eBPFプログラムではたまに上限に引っかかったりする

eBPF FoundationとResearch Fund • eBPF Foundation ◦ eBPFの普及・発展のための基金の運営やイベント・調査などを行う Linux Foundation傘下の組織
• 今年から Research Fundも開始 ◦ eBPF Verifierのスケーラビリティ改善や新たな応用のアイデアなど ◦ 25k - 50k$くらい (350万円 - 700万円) くらい ◦ 今年は終わったが来年もおそらくやる

eBPFのこれまでとこれから

eBPFのこれまでとこれから

More Decks by Yutaro Hayakawa

Other Decks in Technology

Featured

Transcript