Linux Observability with BPF 1人輪読会(3)

「ありえなくて起こりえない」と思われていたことが急に生じた場合、「予測できない」、「非常に強い衝撃を与える」という理論

Steven McCanne と Van Jacobson によって"The BSD Packet Filter: A New Architecture for User-Level Packet Capture." という論文が書かれた。
- 論文はこちら。https://www.tcpdump.org/papers/bpf-usenix93.pdf
当時最新の技術に比べて20倍速いパケットフィルタリングの実装方法が説明されている。
BPF はパケットフィルタリングに2つの革新を導入した
- レジスタベースの CPU で効率的に動作する新しい仮想マシン
- アプリケーション毎のバッファーの使用方法
この実装は、Linux を含めた今日の Unix の派生形のカーネルに存在している

Alexei Starovoitov は extended BPF を導入した。
extended BPF の当初のゴールは、内部的な命令を最適化することだった。
extended BPF は BPF の 2 個の 32 ビットレジスタに対し、10 個の 64 ビットレジスタを持っている。
オリジナルの BPF に比べ、4 倍の性能アップにつながった。
extended BPF は、ユーザースペースからアクセスできるようになり、のちの BPF の大きな変化点になった。
この時のAlexeiのパッチ: [PATCH RFC net-next 00/14] BPF syscall, maps, verifier, samples [LWN.net]
eBPF によって、安全で安定で、カーネルモジュールのようにリコンパイルすることなくプログラムを書くことが出来るようになった。

BPF は、コードを分離された環境で実行できる、高度に拡張された VM である。
BPF が動作するまでの流れ
- コンパイル→ ベリファイアで安全であることを検証→カーネルに組み込み
ベリファイアはカーネルのクラッシュが起きないことを保証する。
カーネルは、JIT コンパイラを組み込んでおり、BPF のバイトコードを機械語に変換することで、実行時間のオーバーヘッドにならないようにしている。
カーネルに組み込まれた実行ポイントは、BPF program type によって定義されている。
このページの図が分かりやすい:
LinuxのBPFで何ができるのか？ BPFの「プログラムタイプ」とは (1/2)：Berkeley Packet Filter（BPF）入門（4） - ＠IT
最後のコンポーネントは、ユーザースペースとカーネルスペースのデータ共有を行うための、BPF map。
BPF map は、双方向のデータ構造となっており、ユーザースペース、カーネルスペースの双方向で読み書きを行うことが出来る。