eBPF - Rethinking the Linux Kernel
まとめ
今後はeBPFによってLinuxはマイクロカーネルのような性質を手にすることになるだろう。 今まではカーネルモジュールやメインラインへのパッチによって機能拡張されていた。しかしeBPFによってより安全にかつ互換性を保った方法で拡張できるようになった。 eBPFによる道的なコード挿入によっていずれはゼロデイ脆弱性に即座に対応するためのホットパッチなども可能になるだろう。
Linuxカーネルがプログラマビリティを獲得したことによってこれらの見通しが現実的となった。 これはあたかもかつてWebがJavascriptによってプログラマビリティを獲得したことで大きく進化したことと似ている。 Javascriptは下記のような性質によってプログラマビリティをもたらした。
- 安全性: 不正なコードをブラウザ内で実行させないサンドボックス
- 継続的デリバリ: ユーザ側に操作を要求することなくロジックを更新できる
- パフォーマンス: 最小限のオーバヘッドでプログラムを実行できるようにするJITコンパイラ
eBPFもまたこれらの性質を満たしているといえる。
- 安全性: 不正なコードをブラウザ内で実行させないverifier
- 継続的デリバリ: eBPFプログラムは動的にアトミックに更新することができる
- パフォーマンス: eBPFプログラムのバイトコードをネイティブコードに変換するJITコンパイラ
以上のようにeBPFはLinuxカーネルに大きなプログラマビリティをもたらした。
感想
大きな意味で目新しい話はなかった。 ずっとモノリシックなスタイルを貫いてきたLinuxカーネルがBPFの拡張によって結果的に(たぶんたまたま？)マイクロカーネル的な機構を生み出してしまったのは結構皮肉な気はする。(Linuxは太りすぎた、とコメントしている人もいたので、このような拡張性を備えることに反感を持つ人はやはりいると思われる)
ここで比較として語られているブラウザとJavascriptの進化と同じ経路を辿るのか、と考えるとちょっと心配になるところもある。 Javascriptは最初に開発された当初のユースケースを大きく越えて、アプリケーションのコアを支える言語として重用されている。このためにJavascript単体では不十分な機能をツールや代替言語で補うようになった。本当に多くのツールが生まれて開発者も技術選定が悩ましいのは想像にかたくない。これと同じことがeBPFでも起きうるのだろうか？
と思ったけど、Linuxカーネル的にはバイトコードとヘルパー関数などをAPIとして提供しているだけで、ハイレベルな言語については何も規定していないのでいくらか収束しやすいかもしれない。またブラウザのように複数のバラバラな実装が開発されるのではなく、eBPFではあくまでもLinuxという一つのカーネルなので混乱の度合は小さくなりそうにも思う。
ネットワーク周辺の仕事をしていた自分の目線だと、カーネルモジュールを使ってパケット転送機能を拡張していたのがXDPでeBPF化できるなら、カーネルアップグレードごとにモジュールビルドするような辛さともおさらばできて運用が楽になる、という嬉しさはあるし面白そうだな、と思っている。
この講演のMapの説明のところで「Prefix Longest Match」というまさしくルーティングで使うために生まれてきたようなタイプのMapがあることを知った。ちょうどMapのタイプについて調査していたところだったので、なおさら調査するモチベーションが出てきた。