eBPFセキュリティエージェントのメモ化でカーネルCPUコストを約90%削減

何が報告されたのか

eBPFを使ったセキュリティエージェントを開発する著者が、プロファイリングの結果をもとに性能改善の事例をブログで報告しました。コードはすでにGitHubでオープンソース化されており、記事の内容はそのリポジトリに対応しています。

このエージェントのポリシーはパスベースで、eBPFのLSMフック(カーネルのセキュリティ判定に処理を差し込む仕組み)を使ってファイルオープン時に発火します。処理の流れは、パスを再構築し、親ディレクトリのdentries(ディレクトリエントリのカーネル内部表現)をたどりながら、対象ファイルや祖先ディレクトリに一致するポリシーがあるかを確認するというものです。

プロファイリングで分かったのは、コストの大半は許可・拒否の適用そのものではなく、どのポリシーが該当するかの特定にあるということでした。同じファイルや同じサブツリーを繰り返し開く場合、この判定を毎回やり直すことになり、たとえばPostgresが/var/lib/postgres配下のファイルを繰り返し読むようなケースでは無駄が大きくなります。記事ではこの非効率な経路を「スローパス」と呼んでいます。

キャッシュの設計

対策はメモ化、つまり判定結果をキャッシュして再利用するというものです。ただしeBPFのマップに格納できる形にする必要があり、dentriesはポインタであるためそのままではマップに入りません。ポインタの内容を構造体に詰める案も検討されましたが、キーとしては重すぎると判断されています。

そこで採用されたのがinodeベースのキャッシュです。キーはマウント名前空間ID、マウントID、inode番号の3つのフィールドで構成されます。inode番号は特定のマウントツリー内でのみ一意であり、複数のマウントツリーを対象にするポリシーでは番号が重複し得るため、マウントIDとマウント名前空間IDを組み合わせて別のマウントや名前空間のキャッシュを誤って使わないようにしています。

キャッシュの値はaccess_indexとキャッシュ状態の2つです。ポリシーは空間効率のためにビットマスクとして保持されており、access_indexは該当するパスポリシーのビット位置を指します。マップの種類はLRUハッシュで、最大エントリ数は10000とされています。キャッシュにヒットすればその結果でファイルオープンを判定し、ミスした場合のみスローパスを実行して結果を格納する流れです。

性能への影響

ベンチマークでは、同じファイルを200,000回オープンして性能を計測したと報告されています。キャッシュなしでは28 billion(280億)だったカーネルサイクル数が、キャッシュありでは3.03 billion(30.3億)になりました。記事ではこれを約90%の削減と表現しています。

キャッシュがない場合、tail_call_security_checkがスタックに89.2%、is_restricted_filepathが81.9%、path_check_callbackが63.7%の割合で出現していました。キャッシュを入れると、is_restricted_filepathとpath_check_callbackはそれぞれ約0.02%まで縮小し、グラフ上では事実上見えなくなると説明されています。

計測にはperfのcycles:kイベントが使われており、これはファイルオープン時のカーネル側CPUコストを測るものです。初回のルックアップ以降はパス走査のコストがほぼ消える、というのが著者の説明です。

エッジケースと注意点

考慮すべき例外として、複数のパスが1つのinodeを共有するケースがあります。最も分かりやすい例はハードリンクで、2つの異なるパスが同じinodeを指すことになります。パスベースのポリシーでは結果が変わってしまうため、キャッシュ性能よりも正確な結果が重要だと著者は述べています。

対処は完全な解決というより回避策です。inodeはリンク数(i_nlink)を保持しており、これを読み取って1より大きい場合はそのキャッシュエントリを使わずスローパスに戻す実装になっています。キャッシュのカバレッジはその分失われますが、正確なキャッシュの方が重要だというトレードオフとして説明されています。

もう1つの特徴は、キャッシュがエージェント内部で完結している点です。ユーザーが定義するポリシーを変更しなくても高速化の恩恵が受けられると著者は述べています。