作用简述

将已编译的 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 - 原内核模块适配项目（已合并归档）