内核源码定制修改模块化技术总结

背景介绍

产品开发中，存在为了支持某些特定功能修改内核源码的过程，修改后的内核需要独立维护，常常会带来额外的工作量，同时每次内核版本变更时相关修改也需要同步到新的内核上，有一定的工作量。

基于上述情况，我们尝试使用现有的内核技术，在不修改内核源码的条件下，通过编写内核模块来实现这些修改。达成了这个目标，后期就只需要维护这些内核模块，不涉及对内核源码的修改，更新内核只需要适配这些模块重新编译，迁移的工作量会大幅降低。

通用问题与解决思路

内核源码修改将未导出的符号修改为导出

模块开发中需要调用未导出的符号，包含函数与变量，解决此问题可以使用如下方法：

1. 确定 /proc/kallsyms 中是否能够找到相应的符号
2. 封装 kallsyms_lookup_name 函数，用符号名称找到符号地址并转化为实际类型使用

模块中需要修改内核内部特定函数的执行逻辑

1. 确定此函数是否内联函数，内联函数不能修改
2. 使用 kprobe 在函数出入口添加探针来改变函数执行行为（并不能解决所有的问题）

需要修改某个模块中的代码

1. 优先确定能否通过其它技术手段支持
2. 模块编译为 m，单独维护一份模块代码修改编译

内核热补丁技术

内核热补丁可以算是一种通用的给内核打补丁的框架，是一种相对通用的解决方案，不过它也不能保证能够解决所有场景中的问题，需要具体问题具体分析。

内核源码修改能否模块化的判断依据

1. 功能是否独立，内核是否支持通过注册某个接口来定制修改设计的所有执行逻辑
2. 是否涉及对未导出符号、内联函数、数据结构的修改（是否支持调用接口定制）
3. 现有的探针、ebpf、lsm 等机制能否实现定制逻辑的修改，能则将这部分内容编写为内核模块加载
4. 依赖的 moprobe 这些命令是否能在修改的执行位置前正常使用？如 initrd 解密中，这些命令都不可用，无法模块化