[Paper] LLM驱动的内核演进：在 Linux 中自动化驱动更新

Source: arXiv - 2511.18924v1

概览

Linux 内核发展迅速，每一次改动都可能导致成千上万依赖它的设备驱动出现破坏。本文介绍了 DRIVEBENCH，一个真实内核‑驱动共演案例的精选语料库，以及 AUTODRIVER，一个利用大语言模型（LLM）自动生成并验证驱动补丁的闭环系统。通过提示工程、多代理协作、静态分析和运行时测试的结合，作者展示了一条实用路径，使驱动能够在无需人工重写的情况下与内核保持同步。

关键贡献

• DRIVEBENCH 语料库：从 612 个候选中提取并完整验证的 235 条内核‑驱动演进案例（覆盖 Linux 5.10–6.10），公开发布以支持可复现研究。
• AUTODRIVER 框架：一个端到端流水线，(1) 构造精确的 LLM 提示，(2) 协调多个 LLM 代理提出补丁，(3) 运行静态分析捕获 API/ABI 不匹配，(4) 通过编译和基于 QEMU 的启动测试迭代验证补丁。
• 实证评估：在 55 条未见过的演进案例上，AUTODRIVER 达到 56.4 % 的编译成功率，且大多数编译通过的补丁在虚拟化环境中能够保持驱动初始化。
• 开源工具：所有脚本、提示和评估框架均在宽松许可证下发布，社区可以将其扩展或集成到 CI 流水线中。

方法论

1. 案例收集：作者挖掘 Linux git 历史，寻找同时修改内核核心文件和驱动源码的提交。手动筛选去除噪声或不相关的改动，形成 DRIVEBENCH 数据集。
2. 提示工程：为每个案例构建结构化提示，包含 (a) 原始驱动代码，(b) 内核差分，和 (c) 对所需语义改动的简要描述（例如 “将 pci_register_driver 替换为 module_driver”）。
3. 多代理 LLM 工作流：
   • 生成代理 产生初始补丁。
   • 审查代理 使用静态分析工具（如 sparse、clang-tidy）对补丁进行检查，并反馈诊断信息。
   • 精炼代理 在静态检查通过之前迭代修改补丁。
4. 闭环验证：精炼后的补丁针对目标内核版本进行编译。编译成功后在 QEMU 中执行，以验证驱动能够加载、初始化且在早期启动阶段不崩溃。失败则触发再次精炼或记录供人工检查。

结果与发现

• 编译成功率：55 条测试案例中有 31 条在 LLM‑驱动的精炼循环后成功编译（56.4 %）。
• 运行时可靠性：在 QEMU 启动测试中，已编译的补丁中有 27 条保持了正确的驱动初始化（例如正确的 probe 回调、资源分配）。
• 错误模式：大多数失败源于细微的 ABI 变化（如结构体布局修改），这些变化未被静态分析捕获，凸显了更深层语义检查的必要性。
• 效率：单个 GPU 工作站上每个案例的平均端到端处理时间约为 12 分钟，表明该方案可在持续集成（CI）流水线中实现。

实际意义

• 自动化驱动维护：内核维护者和 OEM 可以将 AUTODRIVER 接入 CI，在每次新内核发布时自动生成补丁，显著降低驱动破坏的积压。
• 更快的安全更新：内核的安全加固补丁可以即时传播到驱动，无需等待手动移植，缩短硬件漏洞的暴露窗口。
• 供应商无关工具：系统基于原始源码差分和标准静态分析工具，可被任何提供 Linux 驱动的组织采用（嵌入式、汽车、IoT 等）。
• 研究平台：DRIVEBENCH 为后续 LLM 辅助代码转换工作提供基准，便于比较不同提示策略、模型规模或验证方法的效果。

局限性与未来工作

• 成功率有限：仅约一半的案例能够成功编译并运行；需要更复杂的语义分析（如类型状态建模）来捕获 ABI 细节。
• 模型依赖：结果与所使用的特定 LLM 与提示策略紧密相关；探索开源模型或在内核代码上进行微调可能提升鲁棒性。
• 对大型驱动的可扩展性：当前流水线适用于中小规模驱动；若要扩展到大型子系统（如网络栈），可能需要层次化提示或分块分析。
• 人机协同：作者设想一种半自动工作流，让开发者在合并前审查 LLM 生成的补丁，尤其是安全关键硬件。未来工作将研究人类介入的最佳时机以及相应的 UI 设计。

作者

• Arina Kharlamova
• Jiawen Liu
• Tianyi Zhang
• Xinrui Yang
• Humaid Alqasimi
• Youcheng Sun
• Chun Jason Xue

论文信息

• arXiv ID: 2511.18924v1
• 分类: cs.SE, cs.AI
• 发布日期: 2025 年 11 月 24 日
• PDF: Download PDF