eBPFとXDPによるパケット処理

カーネルを改造せずに拡張する発想

カーネルのパケット処理を変えたい場合、従来は専用のカーネルモジュールを書くか、カーネル本体にパッチを送るしかありませんでした。モジュールはクラッシュすればカーネルごと落ち、任意のコードを特権モードで実行できてしまう危険もあります。eBPF（extended Berkeley Packet Filter） はこの問題を、「カーネル内に小さな仮想マシンを用意し、検証済みのプログラムだけを安全に実行させる」方式で解決します。ユーザーが書いたプログラムはバイトコードへコンパイルされ、カーネルにロードされる際に**検証器（verifier）**の静的解析を通過して初めて実行が許可されます。

検証器：安全性を静的解析で保証する

検証器はロード時にプログラムのCFG（制御フローグラフ）を辿り、次のような性質を機械的に確認します。ループの禁止（有界ループを除き無限ループになり得る構造を拒否し、カーネルをハングさせない）、メモリアクセスの境界チェック（パケットバッファやスタックへのアクセスがすべて範囲内に収まると証明できない場合は拒否）、未初期化メモリの読み出し禁止、スタックサイズの上限、到達可能な全パスでの終了保証です。これらすべてを満たして初めて、プログラムはJIT（Just-In-Time）コンパイラによりCPUネイティブの機械語へ変換され、通常のカーネルコードと同等の速度で実行されます。

ユーザー: eBPFプログラム（Cのサブセットで記述）
   ↓ clang/LLVM でコンパイル
バイトコード（eBPF命令列）
   ↓ bpf() システムコールでロード要求
検証器: CFG解析・境界チェック・ループ検出・終了保証
   ↓ 合格のみ通過
JIT: ネイティブ機械語へ変換
   ↓
カーネル内で実行（フックに接続）

プログラムはカーネル内の任意のメモリへ自由にアクセスできるわけではなく、ヘルパー関数（bpf_map_lookup_elem()など、カーネルが提供する限定APIの集合）を通してのみカーネルの状態とやり取りします。ユーザー空間とのデータ共有にはeBPFマップ（ハッシュテーブルや配列としてカーネル・ユーザー双方から読み書きできる領域）を使い、統計情報やロードバランサの転送テーブルなどはここに置かれます。

XDP：NIC直後の最速フック

**XDP（eXpress Data Path）**は、NICドライバがパケットを受け取った直後、Linuxの標準的なパケット表現であるsk_buff（ソケットバッファ構造体）を生成するより前の段階でeBPFプログラムを実行するフックです。sk_buffの確保はフィールドが多く重い処理で、カーネルのパケット受信経路：NAPI と割り込み緩和 で説明される受信パイプラインの入口でもコストがかかります。XDPはこの手前で動くため、後続のスタック処理を丸ごと省略できるパケットに対しては極めて低いオーバーヘッドで判定を下せます。

XDPプログラムは処理の結果として次のいずれかの**戻り値（アクション）**を返し、カーネルはそれに従います。

XDP_DROPが特に強力なのは、破棄判定にかかるコストが「NICのリングからパケットを見て条件を評価する」だけで済み、sk_buff確保・スタック通過・ソケットへのコピーといった通常経路のコストが一切発生しない点です。これにより1コアで数千万pps級のドロップ性能が実現し、大量の攻撃パケットを浴びせるDDoS攻撃に対して、正規トラフィックへの影響を最小化しながら攻撃パケットだけを最上流で捨てられます。関連する増幅型の攻撃像は DNS/NTPリフレクション増幅DDoS攻撃の原理 で扱っています。

フック位置と性能特性のトレードオフ

eBPFはXDP以外にも複数の位置にフックできます。フックが**パケット経路の上流（NICに近い側）**にあるほど、扱える情報は少ない代わりに処理コストが小さく、下流に行くほど情報は豊富になる代わりにコストが増えます。

NIC受信
  → XDP（sk_buff生成前。最速、L2/L3ヘッダとペイロード先頭のみ参照可能）
  → TC ingress（sk_buff生成後。qdiscと連携、フロー情報や既存のTCインフラと統合しやすい）
  → ソケット層（cgroup/ソケットフィルタ。プロセス・ソケット単位のポリシーに向く）
  → アプリケーション

たとえばロードバランサの実装では、単純な宛先IP・ポートに基づく転送判定はXDPで最上流に置き、コネクションの状態管理や複雑なポリシー適用が必要な部分はTCフックやソケット層のeBPFに委ねる、という階層設計が定石です。これは状態を持つファイアウォールの判定を専用の追跡テーブルに任せる conntrackとステートフルファイアウォールの原理 の考え方とも通じます。フローをコアやバックエンドへ振り分ける計算そのものは、コンシステントハッシュ法によるロードバランシング や ECMPのフローハッシュと5-タプルの原理 で説明されるハッシュ設計と組み合わせて使われることが多く、XDPはその判定結果を「どのバックエンドへXDP_REDIRECTするか」という形で高速に実行する層にあたります。

実務での使われ方

DDoS対策では、攻撃シグネチャ（特定パターンのUDPパケットの急増など）をeBPFマップで検出し、送信元IPやパターンに一致するパケットをXDP_DROPで最上流で捨てる構成が典型です。ロードバランサでは、外部から来たパケットの宛先を書き換えてXDP_TXやXDP_REDIRECTでバックエンドへ転送し、カーネルのルーティングテーブルやNATを経由しない分だけ遅延と消費CPUを削減します。KubernetesのCNI（Cilium等）でもeBPFとXDPが多用され、Pod間・ノード間の転送ポリシーをiptablesのルールチェーン走査に代えてeBPFマップのO(1)ルックアップで解決することで、ルール数増加時の劣化を防ぎます。

まとめ

eBPFは、カーネル内に安全な実行環境を作ることで「カーネルを改造せず拡張する」という課題を解決します。検証器がループ・メモリ境界・終了性を静的に証明し、合格したプログラムだけがJITでネイティブ速度で走る——この安全性と速度の両立が核心です。XDPはそのeBPFをsk_buff生成前という最上流のフックに配置し、DROP/PASS/TX/REDIRECTの即時判定によって数千万pps級の処理を可能にします。フックが上流にあるほど速いが扱える情報は少ないというトレードオフを理解し、単純な判定はXDPで、複雑な状態管理はTCやソケット層のeBPFに委ねる階層設計が、DDoS対策やロードバランサを実務で構築する際の定石です。