Development and challenges of eeBPF technology

1、eBPF が Linux を変えた理由

前述の図は、従来のオペレーティングシステムモデルを示しています。このモデルは 50 年にわたって持続し、上から順にアプリケーション、システムコール、カーネル、ハードウェアの 4 層で構成されています。

eBPF の登場により、オペレーティングシステムモデルは前述の図のようなアーキテクチャへと進化しました。

従来のオペレーティングシステムの構成要素は引き続き存在しますが、上位 2 層が 2 つの部分に分割されました。右側はカーネルモードのアプリケーションであり、システムコールは eBPF のシステムコール群となりました。eBPF プログラムはユーザーモードとカーネルモードの間に橋渡しをします。ユーザーモードでプログラムを記述し、ベリファイアの検証を経てカーネルに注入できます。これらの処理の多くは BPF Helper Calls で実行され、Linux のカーネル関数にフォーカスするきっかけにもなっています。

従来のオペレーティングシステムでは、プロセスは待ち状態、スリープ状態、準備状態の 3 つの基本状態に分類されます。プロセスが準備状態のとき、スケジューラはそれを CPU に割り当てて実行できます。これを On-CPU と呼び、プロセスを CPU から外すことを Off-CPU と呼びます。

このように、従来のオペレーティングシステムのスケジューリングは状態に基づいており、準備状態のプロセスのみが CPU で実行できます。

eBPF により、状態モデルはイベント駆動へと変化しました。つまり、イベントが発生したときにのみ BPF プログラムが実行されます。イベントが発生しなければ、プロセスが実行可能であっても CPU は停止したままです。このモデルはモダン Linux とも呼ばれています。

モダン Linux はイベントベースのアプリケーションであり、スケジューラ、割り込み処理などのコア機能はカーネル内に残っています。ただし、アプリケーション向けのスケジューラの一部はカーネル外に移行される可能性があり、オペレーティングシステムの構造は実質的に変化しました。

eBPF はモダン Linux をマイクロカーネルアーキテクチャへと転換させ、Linux に大きな影響をもたらしました。Linux のカーネルは非常に小さくなり、ブートストラップ、ファイルシステム、スケジューラは eBPF の形態でカーネル外に存在するようになりました。これにより、想像の余地が大きく広がっています。

2、eBPF 関連プロジェクト

Netflix の bcc と bpftrace は eBPF の代表的なプロジェクトであり、eBPF のインフラストラクチャでもあります。そのインフラストラクチャの上に、Citrium のクラウドコンピューティングがあり、マイクロサービスをサポートし、マイクロサービスの OS となることを目指しています。その他の eBPF 関連プロジェクトとしては、Facebook の L4 負荷分散や、セキュリティ分野の DDoS オープンソースプロジェクトなどがあります。

まもなく第一回中国 eBPF カンファレンスが開催されます。トレーシング、メモリオーバーフロー、軽量開発フレームワーク、ネットワークなど、多岐にわたる約 20 のプロジェクトを収集しました。

前述の図は、Linux カーネルツアーのライブ配信関連コンテンツを示しています。これも eBPF を深く理解するための良い方法です。

eBPF 分野ではすでに多数のオープンソースプロジェクトが登場しています。ライブ配信のコンテンツやプロジェクトには、フレームワーク、可観測性、ネットワーク、クラウドコンピューティング、セキュリティなどが含まれています。

3、eBPF の機会と課題

現在、eBPF は多くの機会に直面しています。カーネルのプログラマビリティ、eBPF 可用性の継続的な向上、そしてさまざまな業界との連携などです。

eBPF を変更するには、ユーザーモードで eBPF プログラムを記述してスケジューリングアルゴリズムを実装でき、アプリケーション独自のスケジューリングアルゴリズムを記述できます。

従来のシナリオでは、ユーザーがプログラムをオペレーティングシステムに委ねると、制御権はオペレーティングシステムに完全に委ねられ、ユーザーには制御権がありません。ユーザーモードで eBPF プログラムを記述してスケジューリングアルゴリズムを実装できることは、将来のオペレーティングシステムの開発、カスタマイズ、パーソナライゼーションに対して非常に大きな想像の余地を提供します。

eBPF と WASM テクノロジーを組み合わせ、WebAssembly を利用することで、eBPF プログラムの記述、配布、ロード、実行がより簡便かつ軽量になります。

オペレーティングシステムはインフラストラクチャとしてプログラムを実行できますが、変更はできません。eBPF をリンカーとしてさまざまな業界分野と連携することで、クラウドコンピューティング、セキュリティ、IoT、ネットワークなど、多様な分野との接続が可能になります。アプリケーションがますます広範になるにつれて、さまざまな分野と連携する可能性が徐々に現れてくるでしょう。

一方で、eBPF はカーネルセキュリティ、eBPF プログラムの管理と統合などの課題にも直面しています。

たとえば、bpftrace の悪意のある使用は、セキュリティ攻撃、マルウェア、検出エンジニアリングなどの問題を引き起こす可能性があります。eBPF にはルート権限があるため、ベリファイアによる強力なセキュリティ検出があっても、脆弱性の存在を完全に回避することはできません。

Wal Mart は現在、eBPF のライフサイクル管理に関するプロジェクトを研究しています。その中核は「Kernel Functions as a Service」です。このプロジェクトを通じて、カーネルの最も価値ある機能を出力できることが期待されています。

BPF テクノロジー、カーネルテクノロジー、そしてさまざまな分野を真に連携させ、テクノロジーから恩恵を受け、プロジェクトから成果を得られることを期待しています。