プロンプトとコンテキスト
複数のLinuxディストリビューションおよびカーネルバージョンにわたってeBPF可観測性プログラムをどのようにデプロイしますか？ベリファイアが何を保護するのか、ロード失敗をどのようにデバッグするのか、テスト可能な互換性マトリクスをどのように構築するのかを説明してください。
これはプラットフォーム、Linux、SRE、セキュリティ、システム関連の面接に適しています。カーネル境界、静的検証、ユーザー空間ローダーのライフサイクル、リリースの規律をテストします。eBPFプログラムは、カーネルフックにアタッチされる前にベリファイアを通過します。検証に合格したとしても、ビジネスロジックの正しさや、あらゆるカーネル、権限セット、ヘルパー、マップ、BTF環境との互換性が証明されるわけではありません。
面接官が評価するポイント
- ベリファイアの安全性制約とビジネス成果の正しさを区別できているか。
- レジスタの型、ポインタの境界、初期化されたスタック、ループ、ヘルパーのチェックを理解しているか。
- libbpfのopen、load、attach、teardownのライフサイクルを説明できるか。
- BTF、CO-RE、機能検出、バージョン差異のためのカーネルマトリクスを活用できているか。
- ベリファイアログ、権限、マップリソース、アタッチ失敗に対するデバッグパスを提供できるか。
- eBPFがカーネルバグ、ヘルパーのセマンティクス、観測コストの影響を受けることを認識しているか。
30秒の回答例
「ベリファイアは実行前に静的チェックを行います。境界内のメモリアクセス、有効なレジスタおよびポインタの状態を証明し、ヘルパーを制限し、安全性を証明できないパスを拒否します。ただし、メトリクスが正しい意味を持っているかまでは証明できません。私なら、オブジェクトのopen、load、verify、attach、teardownを可観測にし、ベリファイアログを使用してデバッグします。BTF、CO-RE、機能検出、そしてカーネル、アーキテクチャ、権限、フックを網羅するCIマトリクスによって互換性を確立します。ターゲットでロードできない場合、サービスはチェックをバイパスするのではなく、ユーザー空間または既存のメトリクスのフォールバックを維持します。」
ステップバイステップの解決策
ステップ 1: eBPFの安全性境界を定義する
eBPFプログラムは、カーネルが制御する実行環境で実行されます。カーネルメモリを任意に読み取ったり、不正な関数を呼び出したりすることはできません。ベリファイアは、レジスタ、スタック、マップポインタ、パケットポインタを追跡しながら制御フローをたどり、安全性を証明できないパスを拒否します。これはセーフティゲートであり、完全な形式的証明ではなく、サンプリングの意味、プライバシー、リソースコストを精査するものではありません。
まずはプログラムタイプとフックから始めます。tracepoint、kprobe、cgroup、XDPなどはそれぞれ異なる入力、ヘルパー、リターン制約を持ちます。コンテキストと機能が変わるため、同じソースコードでも別のプログラムタイプに移行すると失敗することがあります。
ステップ 2: 一般的なベリファイアエラーを認識する
未初期化レジスタ、スタックのアウトオブバウンズアクセス、未チェックのNULL許容ポインタ、不十分なパケット境界チェック、証明不能なループ、無効なヘルパー引数、無効なポインタ演算はすべて拒否の原因となります。最後のメッセージだけを修正するのではなく、ログ内の最初の状態エラーを読み取ります。
/* Pseudocode: check bounds before reading packet fields */
if (cursor + sizeof(struct header) > data_end)
return DROP;
struct header *h = cursor;
return handle(h->kind);パスをシンプルに保ち、読み取りの直前に境界チェックを配置し、複雑なパース処理は検証可能な小さな関数に分割します。ループを明示的に制限し、マップ検索結果をチェックし、現在のコンテキストで許可されているポインタ変換を使用します。
ステップ 3: libbpfのライフサイクルを説明する
ユーザー空間ローダーはBPFオブジェクトを開き（open）、プログラム、マップ、グローバル変数を検出します。ロード（load）によってマップが作成され、再配置が解決され、カーネルベリファイアにプログラムのチェックとロードを要求します。アタッチ（attach）はプログラムをフックに接続し、ティアダウン（teardown）はデタッチしてリソースを解放します。各フェーズでオブジェクト名、プログラムタイプ、カーネルバージョン、エラーコード、ベリファイアログを記録します。
ロードの成功はアタッチの成功を意味しません。権限、ロックメモリ制限、BTFの欠落、存在しないフック、マップ制限、リングバッファリソースなどは、異なるフェーズで失敗する可能性があります。ランチャーは失敗したフェーズを公開し、一部のプログラムのみがロードされた場合にどの機能が残るかを示す必要があります。
ステップ 4: マップ、イベント、リソース制限を設計する
マップは、カーネルとユーザー空間の間で主要な共有状態を提供します。キー、値、更新の同時実行性、ライフサイクル、容量に基づいて、hash、array、per-CPU、またはring-bufferマップを選択します。高頻度イベントにはサンプリング、バッチ処理、パケット損失カウンタが必要です。観測によってカーネルリソースを枯渇させてはなりません。
カーネル内の機密フィールドを最小限に抑え、可能な限りハッシュ、カテゴリ、またはカウントを送信します。ユーザー空間コンシューマは、リングバッファのオーバーフロー、再起動、バージョンの変更を処理する必要があります。失われたイベントは明示的な不確実性であり、観測値がゼロであることを意味するわけではありません。
ステップ 5: BTF、CO-RE、互換性を処理する
BTFは型のメタデータを提供し、ローダーやツールがプログラム、マップ、カーネルシンボルを理解できるようにします。CO-REは型ごとに再配置を行い、カーネルごとの再コンパイルを削減しますが、すべての差異を解消するわけではありません。ヘルパー、kfuncs、プログラムタイプ、アーキテクチャ、コンパイラ、権限には依然として機能チェックが必要です。
互換性マトリクスには、ディストリビューション、カーネルバージョン、アーキテクチャ、BTFの有無、機能フラグ、コンテナの権限、ターゲットフックを含める必要があります。CIは、実カーネルまたは仮想カーネル上でコンパイル、ベリファイアロード、アタッチ、イベントリプレイ、ティアダウンを実行しなければなりません。コンパイルが通るだけでは互換性があるとは言えません。
ステップ 6: デバッグ、フォールバック、リリースを構築する
次の順序でデバッグします。カーネルと権限を確認する、プログラムタイプとフックを検査する、完全なベリファイアログをキャプチャする、BTFとヘルパーをチェックする、次にマップリソースとユーザー空間の消費をチェックする。修正が原因と一致するように、失敗をソースの安全性、欠落している機能、権限、ランタイムリソース、またはビジネスロジックとして分類します。
まずはシャドウノードまたは小規模なホストカナリアでリリースします。CPU、メモリ、失われたイベント、ベリファイア拒否、カーネルログ、ターゲットシグナルを監視します。ロードに失敗した場合、ユーザー空間サービスは既存のメトリクスまたはログを維持します。ロールバックが新しいプログラムに依存しないように、以前のオブジェクトとデタッチ操作を保持しておきます。
情報の獲得と境界
eBPFの主な利点は、検証可能で可観測なロードパスを通じた制約付きのカーネルプログラマビリティです。ベリファイアはプログラムの意図ではなく一連の安全特性を証明し、CO-REはポータビリティを向上させますがバージョンをまたいだ成功を保証するものではありません。優れた回答は、安全性、互換性、リソース、ビジネスの正確性を包括して扱います。
模範回答
「私はプログラムタイプとフックの確認から始めます。コンテキストによって入力、戻り値、ヘルパーの機能が定義されるためです。実行前に、ベリファイアはレジスタ、スタック、マップ、パケットポインタを追跡し、未初期化レジスタ、境界外アクセス、未チェックのNULL、無制限のループ、無効なヘルパー引数を拒否します。合格はそれらのパスが安全に実行できることを証明しますが、サンプリングやビジネスメトリクスが正しいことを証明するわけではありません。
ユーザー空間ローダーはlibbpfを使用して、open、load、attach、teardownを可観測にします。ロード失敗時には、完全なベリファイアログを保持し、ソースの安全性、ヘルパーの欠落、BTF、権限、リソースの違いを区別します。BTFとCO-REは再コンパイルを減らしますが、それでもコンパイル、ロード、アタッチ、リプレイ、ティアダウンにわたり、ディストリビューション、カーネル、アーキテクチャ、フック、権限、機能の実際のマトリクスをテストします。
マップ容量とイベントレートを制限し、損失を記録し、カーネル内の機密フィールドを最小限に抑えます。本番環境への導入はシャドウノードや小規模なカナリアから開始し、CPU、メモリ、失われたイベント、カーネルログを監視します。ロードに失敗した場合は既存のメトリクスまたはログパスを維持し、デタッチを伴って以前のオブジェクトにロールバックします。これにより、ベリファイアやCO-REを絶対的な安全性や互換性と混同することなくeBPFを活用できます。」
よくある間違い
- ベリファイアをビジネスロジックの証明として扱う → メトリクスの意味やプライバシーはチェックされません → リプレイ、サンプリング、データ監査を追加します。
- コンパイルのみをチェックする → ロード、アタッチ、権限、BTFで失敗する可能性があります → カーネルマトリクス上でライフサイクル全体をテストします。
- ログの最後の行だけを修正する → 根本原因は多くの場合、それ以前の状態障害にあります → 最初のレジスタまたは境界エラーから着手します。
- 無制限のマップやイベントを作成する → 観測によってカーネルリソースが枯渇する可能性があります → 容量を制限し、サンプリングを行い、損失をカウントします。
- CO-REがバージョンの差異をすべて解消すると想定する → ヘルパー、フック、権限、アーキテクチャは依然として異なります → 機能を検出し、適切に性能を縮退（デグレード）させます。
- ユーザー空間のフォールバックを用意しない → ロードの失敗がメインサービスに影響を与える可能性があります → メトリクス、ログ、デタッチパスを保持します。
フォローアップの質問
NULLの可能性があるポインタに関するベリファイアエラーはどのように修正しますか？
参照を解決（デリファレンス）する前に、すべての制御フローパスで明示的にチェックし、そのチェックを読み取り処理の近くに配置します。分岐が複雑な場合は、関数を分割し、危険なキャストで問題を隠すのではなく、ベリファイアの状態を再度確認します。
同じプログラムがあるカーネルではロードされ、別のカーネルでは失敗する場合はどうしますか？
バージョン番号だけを比較するのではなく、プログラムタイプ、ヘルパー、kfuncs、BTF、アーキテクチャ、設定、権限、ベリファイアログを比較します。代替手段を機能検出し、その結果を互換性マトリクスおよびリリースゲートに記録します。
失われたイベントが正常に見えてしまうのを防ぐにはどうすればよいですか？
カーネルとユーザー空間の両方で、損失、リングバッファのオーバーフロー、コンシューマの再起動をカウントします。サンプルレート、損失率、カバレッジを公開します。ダッシュボードでは、イベントが不完全な場合にゼロではなく不確実性を表示する必要があります。
ベリファイアの承認後もセキュリティレビューは必要ですか？
はい。プログラムの権限、データの最小化、ユーザー空間ローダー、アップグレードとロールバック、カーネルの露出、リソース制限をレビューします。ベリファイアは必須ですが、脅威モデリングやランタイム監視の代わりにはなりません。