> [!abstract] 概要(arXiv abstract の日本語訳) > Linux カーネルは最も複雑なソフトウェアシステムの一つであり、自動化されたファジングが継続的に数千件のクラッシュを暴くが、根本原因診断は依然として手作業かつ時間のかかるボトルネックである。既存の LLM ベース根本原因分析(RCA)技術は分散システムには有効だが、疎な低レベルアーティファクト、異種の診断エビデンス(システムコール・ログ・クラッシュレポート等)、きめ細かいメソッドレベル推論を要求する複雑な非線形障害伝播といった理由により、カーネルデバッグへは容易には一般化しない。これらの課題に対処するため、我々は構造化された因果推論を通じたカーネル根本原因診断のためのエージェントベースフレームワーク KernelDiag を提案する。KernelDiag はまず log-to-code マッピングを通じて異種の診断アーティファクトを整列させ、次にアーティファクト特化型エージェントを用いてソースレベルのプログラム意味論とクラッシュ固有のカーネル設定を反復的に推論する。推論された因果依存関係は構造化された Evidence Graph に段階的に組織化され、正確な障害メソッド箇所特定と因果的説明を可能にする。我々は実世界の KGYM ベンチマーク上で KernelDiag を評価した。KernelDiag はファイルレベル・メソッドレベルの両方で最先端の箇所特定手法を一貫して上回り、Top@k 精度で顕著な改善を達成し、明示的なヒントのない挑戦的な設定では最大 4倍・2倍の向上を示した。さらに人手評価と LLM 支援評価の両方が、KernelDiag が正確で一貫性があり実行可能な診断説明を生成することを示した。全体として、この研究は低レベルの診断エビデンスとソースレベルの因果推論を橋渡しすることで、自動化されたカーネル根本原因診断の基盤を築く。 ## 論文情報 - タイトル: KernelDiag: Agent-Based Root Cause Diagnosis for Kernel Crashes - 著者・所属: Weijing Wang・Dong Wang・Haichi Wang・Junjie Chen(School of Computer Software, [[Tianjin University]])、Zan Wang([[Tianjin University]])。Corresponding authors: Zan Wang and Dong Wang。 - 媒体: arXiv プレプリント(未査読) - 発表年: 2026(arXiv 投稿日 2026-07-20) - arXiv ID: 2607.17722v1 [cs.SE] - コード: [KernelDiag-Artifact](https://github.com/VikingStudyHard/KernelDiag-Artifact)(replication package として公開) ## 概要 Linux カーネルは 4000 万行超のコードを持つ複雑なソフトウェアで、Syzkaller/Syzbot 等のファジングが年間数千件のクラッシュを検出するが、根本原因診断は依然として手作業に依存する。既存の分散システム向け LLM ベース RCA はカーネルには通用しない。KernelDiag は syscall・ログ・crash report という異種アーティファクトを役割特化型エージェントで解析し、Evidence Graph に統合して、ファイル/メソッドレベルの箇所特定と因果説明を end-to-end で行う。 ## 問題設定 - **入力**: 1件のカーネルクラッシュに対する診断アーティファクト一式 — トリガとなる syscall シーケンス、実行時ログ(dmesg 相当)、crash report(スタックトレース・BUG メッセージ等)、対象カーネルバージョンのソースコード、カーネル `.config`。 - **出力**: (1) 障害箇所(ファイル/メソッド)のランク付きリストとその根拠、(2) 障害の発生機序と crash site への伝播過程を説明するテキスト。 - **前提**: LinuxFL+ と同様、crash report・syscall・ログという複数アーティファクトが揃っている(KGYM が提供する形式)。ground-truth の障害位置がアーティファクトに明示されているケース(Hint)と、明示されていないケース(NoHint)を区別して評価する。 ## 提案手法 - **アーキテクチャ**: 3 フェーズで構成される(後掲「図表」節の Figure 2 参照)。 1. **Phase 1: Artifact Preprocessing** — Log-to-Code Mapping により、ログ行を発行元のソースコード位置へ静的解析で対応づける。 2. **Phase 2: Agent-Based Causal Reasoning** — Syscall Agent・Log Agent・Report Agent の 3 種のアーティファクト特化型エージェントが、それぞれの入力アーティファクトを起点に反復的にカーネルソースを探索し、各自の Evidence Graph(Syscall/Log/Report)を構築する。 3. **Phase 3: Root-Cause Diagnosis** — File-level Localization Agent → Method-level Localization Agent の2段階粗密箇所特定、続いて Explanation Agent が因果説明を生成する。 - **Log-to-Code Mapping(§III-A)**: カーネルのログ出力は `printk` を直接呼ばず、サブシステム固有のマクロ(例: `invalfc` → `errorfc` → `__plog` → `logfc` → `printk`)を多層に経由することが多く(論文 Figure 3、後述「補足」参照)、キーワードマッチや既定 API ルールに基づく既存手法では対応できない。KernelDiag は `printk` 等の atomic logging sink を起点に、関数呼び出しとマクロ展開の両方を追跡する logging dependency flow を静的解析で構築し、後方到達可能性(backward reachability)によって「sink に到達するあらゆる関数・マクロ」をログ関連とみなす。これにより表層的なログ識別子を持たない `invalfc` のようなラッパーも log 発行元として特定できる。 - **役割特化型エージェント設計(§III-B-I)**: 単一モデルに異種入力を混在させて処理させるのではなく、各アーティファクトに特化した推論方向性(causal anchor)を持つエージェントを用意する。 - **Syscall Agent**: ユーザ空間の呼び出しから開始し、syscall の意図・引数・呼び出し文脈を解析して被試験関数(Functions Under Test)と呼び出し経路を推論、粗粒度の実行スケルトンを構築して以降の探索空間を絞り込む。 - **Log Agent**: ソース位置つきのログを部分的な内部状態遷移として扱い、異常/エラー関連ログを検出したら呼び出し関係・データ依存・オブジェクト状態遷移を後方に辿って最も早い逸脱点を特定する。 - **Report Agent**: crash site(RIP・レジスタ状態・スタックトレース)から出発し、違反されたカーネル不変条件/API 契約(assertion・`BUG_ON` 等)を特定し、破損状態の起源を遡って crash site までの伝播を再構成する。 - **In-Depth Kernel Exploration Mechanisms(§III-B-II)**: 粗い AST サマリや呼び出しグラフだけでは分岐条件・状態検証・エラー処理・ポインタ更新・設定依存パスといった意味論が欠落するため、以下2つのツールを各エージェントに与える。 - **Semantic Function Introspection**: 事前にカーネルソース全体へ静的インデックスパスを行い、関数定義・マクロ定義・構造体宣言の位置とレンジを索引化。エージェントはオンデマンドで対象関数の完全な実装やマクロ定義、関連データ構造の宣言を取得できる。ポインタ経由アクセス(`x->y`)については構造体定義を辿って対応する state owner を特定する field resolution も行う。 - **Environment-Aware Semantic Pruning**: `#ifdef CONFIG_*`・`IS_ENABLED(CONFIG_*)`・アーキテクチャ固有分岐など設定依存コードに遭遇したとき、カーネル `.config` を参照して当該条件が対象環境で有効かどうかを検証し、実行不可能な分岐を除外する。間接ディスパッチ(コールバック・関数ポインタ・ops テーブル)についても活性ハンドラを優先する。 - **Evidence Graph 構築(§III-B-III)**: 各エージェントは自由形式のテキストではなく、事前定義されたコマンドラインツールを通じてスキーマ検証済みの Evidence Graph を段階的に構築する。ノードは Active Entities(operation・anomalous event)・Data Carriers(object・buffer)・Logical Constraints(invariant・lifecycle state)、エッジは Data/Control Flow・Lifecycle Transitions・Logical Provenance を表す。全ノードはファイルパス・関数名・行範囲というソースレベル位置属性を共有し、異種アーティファクト由来のグラフ間でのエンティティ整合(cross-artifact alignment)を可能にする(後掲「図表」節の Figure 4 参照)。 - **Root-Cause Localization(§III-C-I)**: 因果起源をクラッシュ地点への近さより優先する2段階プロセス。 1. **File-level Localization Agent**: Evidence Graph を後方推論し、不変条件違反・ライフサイクル対称性の破れ・不正状態の導入といった異常が最初に出現する箇所を特定して、Top-K 候補ファイルを Tier-1(障害起源の可能性が高い)/Tier-2(伝播・増幅・露呈に関与)に分類する。 2. **Method-level Localization Agent**: 優先ファイル内外を精査し、直接関与するメソッドだけでなく producer・mutator・consumer・guard・error handler といった意味的関連ルーチンも含めた Top-K 候補メソッドを検討。Evidence Graph 上で「そのロジックがどのように不正状態を生み観測された症状に至るか」を根拠づけられた場合のみ root cause と判定する。 - **Root-Cause Explanation Generation(§III-C-II)**: Explanation Agent が Evidence Graph・先行の箇所特定結果とその根拠を入力として、対象メソッドを中心とする説明を合成する。説明は (1) 対象メソッド内の具体的な障害ロジック機構、(2) 対象メソッドから観測されたクラッシュへの伝播過程、の両方をカバーすることを要求される。 ## 新規性 - **カーネル特化の初の agent-based 根本原因診断フレームワーク**: 著者らの整理によれば、既存 LLM ベース RCA は AIOps(クラウドサービス・分散システム)向けに設計されており、rich な運用コンテキスト(エンドツーエンドトレース・構造化ログ)を前提とする。カーネルにはこれが欠け、既存手法はそのままでは通用しない。カーネル特化の唯一の先行研究 LinuxFL+ は crash report のみを主信号とし、障害箇所は特定できても「どう伝播したか」を説明しない。KernelDiag は syscall・ログ・crash report を統合し、箇所特定と因果説明を同一パイプラインで扱う。 - **表層識別子に依存しない Log-to-Code Mapping**: 既存アプローチ(keyword matching や固定 API ルール)は「ロギング関数は限定的・安定・明示的に識別可能」という前提を置くが、カーネルのロギングは分散的かつマクロで多層に隠蔽されており、この前提が崩れる。KernelDiag は backward reachability に基づく形式化でこれを解決する。 - **一般目的コードローカライゼーション手法の転用限界を明示**: LocAgent のような graph-guided LLM エージェントは Python リポジトリ向けにグラフ構築・索引が調整されており、C 言語のマクロ・条件コンパイル・関数ポインタ・サブシステム固有ディスパッチを扱うカーネルへの適用には大幅な再エンジニアリングが必要であると論じ、比較対象から意図的に除外している。 ## 実験設定 - **環境**: 64 CPU コア・504GB メモリを備えたサーバ上の同一仮想環境。バックボーン LLM は DeepSeek-V3(温度 0、公平性と再現性のため)。候補数 K=10(開発者が許容する最大作業量に合わせる)。 - **データセット**: KGYM ベンチマーク。バージョン 4.x〜6.x にまたがる 279 件の実世界カーネルクラッシュ、72 の異なるサブシステムを含む。crash report・再現スクリプト・実行トレース・正解パッチのフルセットを提供。ファイルレベル 279 件・メソッドレベル 279 件を Hint/NoHint に分割(Table I: File-level Hint 244/NoHint 35、Method-level Hint 164/NoHint 115)。追加で 2025-03 以降に修正された 50 件のポストリリースクラッシュでデータリーク耐性を検証。 - **比較対象**: - **LinuxFL+**: 唯一のカーネル特化フレームワーク。SWE-agent をカーネル対応ヒューリスティック(directory-aware exploration・candidate expansion)で拡張。 - **Agentless**: 汎用ソフトウェア向け SOTA LLM ベース箇所特定手法(プロジェクトレベル要約→フィルタリング→自己一貫性スコアリングの3段階パイプライン)。SWE-bench で高性能。 - 説明品質評価用に LinuxFL+-Diag・Agentless-Diag(各手法の Top-1 箇所特定結果と根拠を crash report とともに同一バックボーン LLM・プロンプト・評価基準で説明生成させた diagnosis-oriented variant)を構築。 - **評価指標**: Top@k(k∈{1,3,5,10})、Mean Reciprocal Rank(MRR)、Mean First Rank(MFR、Top-10 圏外は 11 とする)。説明品質は Consistency(パッチとの整合)・Usefulness(修正への実用性)・Clarification(伝播の明確さ)の3軸 5 段階 Likert(LLM-as-a-Judge = GPT-5.2、および 3 名の非著者評価者による人手評価、Krippendorff's Alpha 0.75〜0.84)。 ## 実験結果 **ファイルレベル箇所特定(Table II)**: KernelDiag は F-All で Top@1 65.95%(LinuxFL+ 51.61%・Agentless 50.18%比 +27.78%/+31.43%)、MRR 0.78・MFR 1.93(開発者が平均 2 ファイル未満の確認で済む水準)。F-NoHint では LinuxFL+/Agentless が Top@1 で共に 0.00% に対し KernelDiag は 31.43%、Top@3〜10 で 314.29%〜1,150.00% の相対改善。F-Hint では Top@1 70.90%・Top@10 99.18%(ほぼ飽和)。Friedman χ²=82.819(p<0.001)、post-hoc Wilcoxon で両ベースラインに対し有意(p<0.001)。 **メソッドレベル箇所特定(Table III)**: M-All で Top@1 33.33%(LinuxFL+ 26.52%・Agentless 27.96%比 +24.09%〜+34.21%)、MRR 0.45・MFR 5.08。M-NoHint では両ベースラインが Top@1 0.00% なのに対し KernelDiag は 5.22%、Top@10 は 34.78%(LinuxFL+ 比 +185.71%、Agentless 比 +127.27%)。M-Hint では Top@1 53.05%・Top@10 95.12%。Friedman χ²=39.795(p<0.001)。 **説明品質(Table IV・V)**: GPT-5.2 評価で KernelDiag の Consistency 2.9713・Usefulness 2.9355・Clarification 4.2151。LinuxFL+-Diag 比 +11.57%/+27.97%/+5.76%、Agentless-Diag 比 +22.81%/+20.90%/+14.40%。人手評価は Hit@1 で Consistency 4.8065・Usefulness 4.9677 と非常に高く、Hit@k の増加とともにスコアが低下する傾向は人手・LLM 両評価で一致。 **局所化と説明の関係(Table VI)**: 正しい Top-1 局所化と誤った局所化の間で、Consistency は +1.1613 点(KernelDiag、Mann-Whitney U=12,735.0, δ=0.4724, p<0.001 after Holm correction)、Usefulness は +1.1935 点(δ=0.5227、大きな効果量)差がある一方、Clarification には有意差なし(δ=0.0845、無視できる効果)。LLM は誤った局所化でも一貫した説明を構成しうるため、Clarification 単独では根拠の正しさを示さない。 **アブレーション(Table VII・VIII)**: crash report(w/o Report)除去が最大の性能低下 — ファイル Top@1 -63.04%・メソッド Top@1 -78.49%・Consistency -61.76%。次いで NoHint 設定でログの寄与が大きい(M-NoHint Top@1 -50.00%)。推論フレームワークでは単一パス直接問い合わせ(w/ DirectQuery)が最大の劣化(Top@1 -28.26%/-29.03%、Usefulness -26.86%)、単一エージェント統合(w/ SingleAgent)も役割分化の欠如による性能低下を示す。アーキテクチャ要素では w/o Log-to-CodeMapping がメソッド Top@1 最大 -12.90%、続いて w/o EnvironmentPruning -11.83%、w/o EvidenceGraph -10.75%、w/o FunctionIntrospection -8.60%。 **ポストリリースデータセット(Table IX・X)**: 2025-03 以降修正の 50 件でも KernelDiag はファイル Top@1 70.00%(LinuxFL+ 比 +20.69%、Agentless 比 +12.90%)、メソッド Top@1 48.00%(+60.00%/+26.32%)、Top@10 でファイル 100.00% を達成。説明品質でも Consistency/Usefulness/Clarification を LinuxFL+ 比 +13.53%/+23.08%/+11.48%、Agentless 比 +7.86%/+16.79%/+9.68% 改善し、記憶(memorization)のみでは説明できない性能とする。 **LLM バックエンド汎化(Table XI・XII)**: Qwen3-Max でも KernelDiag は両ベースラインを上回る(ファイル Top@1 63.44%、メソッド Top@1 36.56%)。DeepSeek-V3 と Qwen3-Max はファイルレベルで 146 件共通で正解し、それぞれ 38 件・31 件を独自に正解しており、複数バックエンドの組み合わせがロバスト性を向上させる可能性を示唆する。 **失敗分析(§VI-IV, Figure 6)**: フレームバッファのジオメトリ更新に伴う整数アンダーフローが別サブシステムでの out-of-bounds メモリアクセスを引き起こすケースでは、KernelDiag はフレームバッファ状態更新まで疑いを絞り込めたが、設定更新から後段のサイズ計算までの中間ステップを Evidence 内で再構成できず根本原因の特定に失敗した。既存の診断アーティファクトのみへの依存の限界を示す例であり、著者らは軽量な動的解析(ブレークポイントや対象関数へのロギング挿入)との組み合わせを将来課題として挙げている。 ## 考察 - **crash report が主要な因果アンカーである一方、単独では不十分**: アブレーションで crash report 除去が最大の性能低下を示す一方、Figure 1 の EXT4 の例では crash report だけでは `__ext4_fill_super` という真の障害メソッドに到達できず、ログの checksum failure を手掛かりに mount 時のメタデータ検証ロジックへ絞り込む必要があった。3 種のアーティファクトは補完的であり、単一モダリティでは不完全または誤解を招く推論に陥りやすい。 - **NoHint 設定でこそ手法の真価が表れる**: Hint 設定では file-level Top@10 がほぼ飽和(99.18%)し、ベースラインとの差が縮まる。差が最も大きく開くのは、明示的な障害位置手がかりが与えられない NoHint 設定であり、これは KernelDiag が表層的な検索ではなく因果推論そのものによって障害を発見していることを示唆する。 - **精度と説明品質の相関は一様ではない**: 正しい局所化は Consistency・Usefulness と強く相関するが、Clarification(説明の分かりやすさ)とはほぼ無相関である。これは「説明が分かりやすいこと」と「説明が正しいこと」が独立した性質であり、LLM ベース診断システムの評価では両方を別々に測定する必要があることを示す。 - **計算コストは意図的なトレードオフ**: KernelDiag は役割特化エージェントとオンデマンドのきめ細かいリポジトリコンテキスト取得のため、時間・トークンコストが高い。著者らは、これを人間エンジニアが手動でクラッシュを再現・調査するコストと比較すれば正当化されるトレードオフだと位置づける。アーティファクト特化解析は並列実行可能であるためレイテンシは緩和できるとも述べる。 ## 強み / 弱点・課題 - **強み** - 3種の異種アーティファクトを役割特化エージェントで分業させ、単一エージェントに混在入力を処理させる設計(w/ SingleAgent)より高い性能を実証。 - Log-to-Code Mapping により、キーワードマッチでは捉えられないマクロ多層ラッピングされたログ発行元を静的解析ベースで解決。 - ファイル/メソッドレベル両方、Hint/NoHint 両条件、追加のポストリリースデータセット、異なる LLM バックエンド(DeepSeek-V3・Qwen3-Max)という複数軸で頑健性を検証。 - LLM-as-a-Judge と人手評価(Krippendorff's Alpha 0.75〜0.84)を併用し、評価の信頼性を相互検証。 - **弱点・課題**(著者による Threats to Validity・失敗分析より) - **データリークの懸念**: KGYM のバグは DeepSeek-V3 の学習コーパス公開前に修正されているため、記憶由来の性能である可能性を完全には排除できない。著者はポストリリースデータセットとアブレーション(DirectQuery/SingleAgent が劣ることを示す)で緩和を試みているが、closed-source LLM の正確な学習コーパスは不明なため threat として残る。 - **外的妥当性はカーネルドメインに限定**: KGYM が全てのカーネルバージョン・ハードウェアアーキテクチャ・サブシステム挙動の多様性を捉えているとは限らず、他の低レベルシステムへの一般化も未検証。 - **既存アーティファクトのみへの依存の限界**: Figure 6 の失敗例が示すように、設定更新から後段の不正計算までの中間状態がどのアーティファクトにも明示的に現れないケースでは診断に失敗する。著者は軽量動的解析の併用を今後の課題としている。 - **評価の主観性**: 説明品質は人手 Likert 評価に依存しており、3 名の評価者による事前ブリーフィングと Krippendorff's Alpha で信頼性を確保しているが、根本的な主観性は残る。 ## 図表 **Figure 2: Overview of KernelDiag** ![[_attachments/arxiv-2607.17722/fig02-architecture-overview.png]] (Figure 2. 3フェーズ構成の全体アーキテクチャ。Phase 1 で syscall・ログ・report を前処理(ログは Log-to-Code Mapping で発行元へ整列)、Phase 2 で Syscall/Log/Report の3エージェントがそれぞれ Iterative Causal Reasoning Process(In-Depth Kernel Exploration → Artifact Analysis and Reasoning → Evidence Graph Construction/Update の循環)を通じて Evidence Graph を構築、Phase 3 で File-level → Method-level の2段階 Localization Agent と Explanation Agent が Faulty Location + Explanation を出力する。Source: Adapted from Fig. 2.) **Figure 4: 因果トポロジー構造の例(Evidence Graph)** ![[_attachments/arxiv-2607.17722/fig04-evidence-graph-topology.png]] (Figure 4. EXT4 クラッシュ例(Figure 1)に対応する Syscall/Log/Report の3つの Evidence Graph を Entrance → Runtime → Crash Site の時系列に沿って重ね合わせた図。`syz_mount_image$ext4` からの mount 系統(青)と `openat` からの lookup 系統(青)が `__ext4_fill_super`・`path_openat` の "Same Loc" ノードで syscall グラフとログ/report グラフを接続し、最終的に `ext4_es_cache_extent_BUG` の Crash ノードへ至る。エッジラベル(Calls/Verifies/Violates/Produces/DispatchesTo)が Evidence Graph のエッジ種別(Data/Control Flow・Logical Provenance 等)の具体例を示す。Source: Adapted from Fig. 4.) 補足: 論文はこの他に Figure 1(EXT4 クラッシュの crash report/syscall/ログの生テキスト例)、Figure 3(`invalfc` のマクロ展開連鎖を示すコード断片)、Figure 5(生成された根本原因説明のテキスト例)、Figure 6(失敗診断のテキスト例)を含むが、いずれもテキスト/コードスクリーンショットであり、本文中の該当引用箇所(「問題設定」「提案手法」「実験結果」各節)にその内容を文章として転記済みのため画像化は省略した。