作用简述 将已编译的 Linux 可执行程序与某个 GLIBC 版本进行兼容 将已编译的 Linux 驱动程序强行适配某个内核版本 关于使用局限性及仓库地址见文章末尾 背景 早期在向低版本 glibc 环境部署工具链时，总是会遇到找不到高版本 glibc 符号的问题 于是就只能在低版本环境从源码构建出高版本 glibc ， 然后用 LD_LIBRARY_PATH 、 LD_PRELOAD 指向它或者用 patchelf 工具批量修改二进制文件的 rpath 和新的动态链接器路径 但这个方法太麻烦了，让我不由得产生一个疑问，既然报错的符号名称一致，为什么动态链接器非要匹配指定版本的符号？ 既然它能知道 elf 文件所需的版本，那么这个版本肯定被记录在 elf 文件中了，那么能不能像修改文本文件一样，把版本调低呢？ CAdapt [ 2022 ] 于是就从网上找 elf 文件格式资料、相关源码 果珍，让我找到了一个很久以前别人用 c 实现的代码 然后就是编译验证，成功后就是古法分析、注解，然后改造了 由此，我的第一版 CAdapt 就诞生了 当然在后面使用过程中也暴露出一些问题，后续又进行了一些修复 UpModule （ 2025 ） UpModule 的起因也很简单 就是因为后面做驱动开发时遇到了类似的问题 有时内核只是更新了一个小版本，原本正常的驱动就装载不上了 随后举一反三，既然以前做 CAdapt 可以直接修改已编译好的 elf 文件达到兼容的目的 那么同样修改已经编译好的驱动文件，是否也能达到此类目的呢 于是便尝试让 Ai 仿照着 CAdapt 的做法，输出一套用于内核模块硬兼容的代码 但不知道是 Ai 出于对于我这种行为的排斥，还是对内核代码并不了解，一直劝退我，导致最终未果 后面依旧是扒内核源码，分析内核模块装载时的校验逻辑，然后在代码中反向操作得以实现 Merge （ 26.10.02 ） 国庆节闲来无事，突然想到既然两者都属于同一类型的小工具，为何不合并成一个 后面再有类似需求再逐渐追加功能，慢慢发展成类似 patchelf 那种的实用工具呢 虽说现在 Ai 工具盛行导致工具廉价，但总能节省点 token 吧 于是使用 gemini 对两者进行了合并 Fix （ 26.10.12 ） 开始使用 codex ，刚好用这种小项目练习一下 于是便让他检查代码质量、以及有没有 bug 结果这世界上又多了个 回车战士 …… 注意事项 说了这么多，讲讲局限性吧 对于 glibc 的适配： 要保证没有用到高版本 glibc 中特有的符号 例如有些时间相关的…… 要确定被修改的这个符号使用的一些数据结构没有发生改变，否则即使提示修改成功，实际运行也会崩溃 比如某个结构体在低版本 glibc 中时 32 字节，高版本中变成了 64 字节，即便符号版本被降级成功，依旧 ABI 版本不兼容 以上两种情况对 kmod 也适用，同时对于启用了 CONFIG_MODVERSIONS 的内核模块，还需要获取目标内核导出符号对应的 CRC 信息 如果找不到对应的信息，就需要从系统中已安装的驱动中提取，如果提取到的符号覆盖了你驱动中使用的符号，那么就可以成功，反之失败 所以在编写驱动之初，就应该限制使用的函数数量以及更多的使用常用内核函数，这样的话再配合当前的工具就能在一定程度上提高驱动的兼容性 还有一点虽然不常见但也要注意，对于启用了强制模块签名校验的系统，修改后的模块还需要满足相应的签名要求。 仓库地址 CAdapt - GLIBC & KMOD 符号版本适配工具 UpModule - 原内核模块适配项目（已合并归档）

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/10/12 17:57:42