eBPFのこれまでとこれから

by Yutaro Hayakawa

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

私と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)

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

eBPFが生まれた歴史的背景

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

カーネルネイティブ派 ● 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…)

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

eBPFとは？

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

eBPFの今後

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Q & A