【ITニュース解説】eBPF verifier limits are a design constraint: what CO-RE field offsets and bounded loops taught me

ITシステムを動かす心臓部である「カーネル」の中で、プログラムを安全かつ効率的に実行するための特別な技術として「eBPF」がある。このeBPFプログラムは、システムの動きを監視したり、ネットワーク通信を制御したりと、様々な重要な役割を果たす。しかし、カーネルという非常にデリケートな場所で動くため、その安全性は厳しくチェックされる。この記事では、eBPFプログラムを開発する際に直面する「設計上の制約」と、それらを乗り越えるための考え方について解説する。

まず一つ目の制約は、「CO-RE（Compile Once - Run Everywhere）」と呼ばれる、一度コンパイルしたeBPFプログラムを様々なカーネルバージョンで動かすための仕組みに関わるものだ。本来、CO-REはプログラムのポータビリティ（持ち運びやすさ）を高めることを目的としている。しかし実際には、問題が発生することがよくある。

具体的には、カーネルのバージョンが変わると、内部のデータ構造の「レイアウト」が変わってしまうことがある。例えば、struct fileというファイルに関する情報を持つ構造体があったとする。この構造体の中にある特定の情報（例えばファイルのサイズ）にアクセスするための位置（これを「オフセット」と呼ぶ）が、あるカーネルバージョンでは正しいが、別のバージョンではずれてしまう、という問題が起こる。eBPFはカーネルの持つ「BTF（BPF Type Format）」というメタデータを使って、このオフセットのずれを自動的に調整しようとする。しかし、開発者が「このフィールドは常にこういう意味だ」と前提してしまっていると、BTFによる調整は正しく行われても、開発者の意図と異なるデータにアクセスしてしまうというバグに繋がることがある。

さらに深刻なのは、対象のカーネルがBTF情報を提供していない場合だ。この場合、eBPFプログラムをカーネルにロードしようとした時点で「BTF情報が見つからない」というエラーが発生し、プログラムを動かすことすらできない。これはコードのバグというよりは、プログラムをデプロイする環境側の問題と捉えるべきだ。

これらのCO-REに関する問題を解決するために、開発者が学ぶべきは、「ポータブル」という言葉が単なる希望ではなく、実際にテストによって証明されるべき「主張」であるということだ。具体的には、「継続的インテグレーション（CI）」という開発プロセスに「検証マトリックス」を導入することが非常に有効だ。これは、同じeBPFプログラムのソースコードを、複数の異なるカーネルバージョンに対してコンパイルし、実際にロードしてみて、期待通りに動作するかどうかを自動的にテストする仕組みだ。もしフィールドのオフセットがずれてプログラムが失敗するようなことがあれば、CIパイプラインがすぐに赤信号を出し、本番環境で問題が起こる前に検知できる。これにより、「このカーネルでは動くはず」という漠然とした期待が、機械的に確認された確実な情報へと変わる。

二つ目の制約は、eBPFプログラムの「ベリファイア」による厳格なチェックだ。ベリファイアは、eBPFプログラムがカーネル内で無限ループに陥ったり、システムをクラッシュさせたりしないように、実行前にその安全性を徹底的に検査する。特に、ベリファイアは「無制限ループ」を禁止し、最大反復回数が事前にわかる「限定ループ」しか許可しない。これは、もしeBPFプログラムがカーネル内で無限ループに陥ったら、システム全体が停止してしまう危険性があるためだ。

この制約に対して「最後まで繰り返し処理する」という考え方を捨て、より生産的なアプローチを取る必要がある。具体的には、以下の三つの方法が挙げられる。

一つ目は、「マップをリースする」という考え方だ。例えば、ハッシュマップのすべてのエントリをスキャンしたい場合、eBPFプログラムは一度に全体をスキャンすることはできない。そこで、固定サイズの「スライディングウィンドウ」のような状態管理を行い、イベントが発生するたびに少量のデータを処理し、もしウィンドウがいっぱいになったら、最も古いバッチを処理するという方法をとる。これにより、個々の処理ステップは常に限定的で、ベリファイアに優しいループとして認識される。

二つ目は、「状態をマップエントリに折りたたむ」ことだ。何かを決定するために、マップ内の他の無関係なエントリを繰り返し参照する必要がある場合、ベリファイアはこれを拒否する可能性がある。代わりに、更新されるエントリ自体に、その決定に必要な「実行中のスコア」や「状態情報」を保存してしまう。これにより、複雑な反復処理を行うことなく、直接エントリの情報だけで判断が可能になる。

三つ目は、「無制限な部分はユーザー空間に押し出す」という戦略だ。カーネル内で複雑なロジックや、データ量が多い場合の集計・分析を行うのではなく、eBPFプログラムは最小限の処理で要約情報だけを抽出し、それを「ユーザー空間」、つまりカーネルの外で動作する通常のアプリケーションプログラムに渡す。そして、そのユーザー空間のプログラムが、任意の複雑なループや、大量のデータを扱う分析を実行する。これは、実際のシステムエージェントが動作するのと似ている。カーネル側の反応は迅速かつ限定的で、危険性や柔軟性の高い分析は、システムのホットパス（頻繁に実行される経路）の外で行われる。

三つ目の制約は、「マップアクセスパターン」に関するものだ。eBPFプログラムがカーネル内のマップにアクセスする際、特定のパターンでポインタを扱うと、ベリファイアによってロード時に拒否されることがある。特に問題となるのは、マップのエントリを指すポインタを長時間保持したまま、別の重要な処理（例えば、perf_event_outputのようなシステムイベントの出力）を呼び出したり、またはあるマップをルックアップしている最中に、そのルックアップキーがまだ確保されている状態でさらにネストされたマップのルックアップを行ったりするケースだ。ベリファイアは、ポインタが有効な間、そのポインタを使って何ができて何ができないかを厳密に追跡している。

この問題を回避するためには、プログラムの構造を工夫する必要がある。具体的には、マップから取得した必要なフィールドの値を、一度「スタックローカルな変数」、つまりeBPFプログラム自身の安全なメモリ領域にコピーしてから、その値を使ってイベントを出力したり、他の処理を行ったりする。こうすることで、マップのエントリポインタを不必要に長く保持することを避け、ベリファイアのチェックを通過しやすくなる。これは、「どこでもロードできる」プログラムと、「正しい形に構造化されたコードでのみロードできる」プログラムの違いとして理解できる。

これらの経験を通じて得られる最も重要な教訓は、eBPFプログラムの「検証」は、開発者の頭の中にある漠然とした「これで大丈夫だろう」という希望に頼るのではなく、「CI（継続的インテグレーション）」という自動化されたプロセスの中で、機械によって確実に行われるべきだということだ。この記事で触れられたプロジェクトでは、フィールドオフセットのマトリックスや、各カーネルバージョンでのロードの期待値などを含む検証ドキュメントを作成し、それをCIジョブで自動的にコンパイル、ロード、そして結果を検証するようにしている。このプロジェクトにおいて、最も価値の高いコミット（変更）は、新しい機能を追加したものではなく、「このカーネルで動作するはず」という開発者の思い込みを、機械がチェックする明確なステートメントへと変えたCIジョブの実装だったという。これは、eBPF開発における信頼性とポータビリティを確立するための、非常に重要なアプローチを示している。