内核模块详细加载/卸载过程

ko文件在数据组织形式上是ELF(Excutable And Linking Format)格式，是一种普通的可重定位目标文件。 这类文件包含了代码和数据，可以被用来链接成可执行文件或共享目标文件，静态链接库也可以归为这一类。

 

文件开始处是一个ELF头部(ELF Header)，用来描述整个文件的组织，这些信息独立于处理器， 也独立于文件中的其余内容

我们可以使用readelf工具查看elf文件的头部详细信息。

readelf -h ***.ko

程序头部表(Program Header Table)是个数组结构，它的每一个元素的数据结构如下每个数组元素表示:

• 一个”段”：包含一个或者多个”节区”，程序头部仅对于可执行文件和共享目标文件有意义

• 其他信息：系统准备程序执行所必需的其它信息”

节区头部表/段表(Section Heade Table) ELF文件中有很多各种各样的段，这个段表(Section Header Table)就是保存这些段的基本属性的结构， ELF文件的段结构就是由段表决定的，编译器、链接器、装载器都是依靠段表来定位和访问各个段的属性的 包含了描述文件节区的信息。

ELF头部中：

• e_shoff：给出从文件头到节区头部表格的偏移字节数，

• e_shnum：给出表格中条目数目，

• e_shentsize： 给出每个项目的字节数。

从这些信息中可以确切地定位节区的具体位置、长度和程序头部表一样， 每一项节区在节区头部表格中都存在着一项元素与它对应，因此可知，这个节区头部表格为一连续的空间， 每一项元素为一结构体(思考这节开头的那张节区和节区头部的示意图)。

读取节区头部表的详细信息。

readelf -S ***.ko

重定位表

重定位表(“.rel.text”)位于段表之后，它的类型为(sh_type)为”SHT_REL”，即重定位表(Relocation Table) 链接器在处理目标文件时，必须要对目标文件中某些部位进行重定位，即代码段和数据段中那些对绝对地址的引用的位置， 这些重定位信息都记录在ELF文件的重定位表里面，对于每个须要重定位的代码段或者数据段，都会有一个相应的重定位表 一个重定位表同时也是ELF的一个段，这个段的类型(sh_type)就是”SHT_REL”

读取重定位表。

readelf -r

 

字符串表

ELF文件中用到了很多字符串，比如段名、变量名等。因为字符串的长度往往是不定的， 所以用固定的结构来表示比较困难，一种常见的做法是把字符串集中起来存放到一个表，然后使用字符串在表中的偏移来引用字符串。 一般字符串表在ELF文件中也以段的形式保存，常见的段名为”.strtab”(String Table 字符串表)或者”.shstrtab”(Section Header String Table 段字符串表)

读取节区字符串表。

readelf -p

 

 

 

2.2.1.2. 内核模块加载过程

我们先了解整个加载过程，再带着这个框架去看代码。

首先insmod会通过文件系统将ko读到用户空间的一块内存中， 然后执行系统调用sys_init_module()解析模组,这时，内核在vmalloc区分配与ko文件大小相同的内存来暂存ko文件， 暂存好之后解析ko文件，将文件中的各个section分配到init 段和core 段，在modules区为init段和core段分配内存， 并把对应的section copy到modules区最终的运行地址，经过relocate函数地址等操作后，就可以执行ko的init操作了， 这样一个ko的加载流程就结束了。 同时，init段会被释放掉，仅留下core段来运行。

`SYSCALL_DEFINE3(init_module, void __user *, umod, unsigned long, len, const char __user *, uargs) { int err; struct load_info info = { }; err = may_init_module(); if (err) return err; pr_debug("init_module: umod=%p, len=%lu, uargs=%p\n", umod, len, uargs); err = copy_module_from_user(umod, len, &info); if (err) return err; return load_module(&info, uargs, 0); }`

第14行：通过vmalloc在vmalloc区分配内存空间，将内核模块copy到此空间，info->hdr 直接指向此空间首地址，也就是ko的elf header 。

第18行：然后通过load_module()进行模块加载的核心处理，在这里完成了模块的搬移，重定向等艰苦的过程。

 

 

 

2.2.2. 内核是如何导出符号的

符号是什么东西？我们为什么需要导出符号呢？内核模块如何导出符号呢？其他模块又是如何找到这些符号的呢？

这是这一小节讨论的知识，实际上，符号指的就是内核模块中使用EXPORT_SYMBOL 声明的函数和变量。 当模块被装入内核后，它所导出的符号都会记录在公共内核符号表中。 在使用命令insmod加载模块后，模块就被连接到了内核，因此可以访问内核的共用符号。

 

 

2.3.4.2. 系统自动加载模块

我们自己编写了一个模块，或者说怎样让它在板子开机自动加载呢？ 这里就需要用到上述的depmod和modprobe工具了。

首先需要将我们想要自动加载的模块统一放到”/lib/modules/内核版本”目录下，内核版本使用’uname -r’查询； 其次使用depmod建立模块之间的依赖关系，命令’ depmod -a’； 这个时候我们就可以在modules.dep中看到模块依赖关系，可以使用如下命令查看；

cat /lib/modules/内核版本/modules.dep | grep calculation

最后在/etc/modules加上我们自己的模块，注意在该配置文件中，模块不写成.ko形式代表该模块与内核紧耦合，有些是系统必须要跟内核紧耦合，比如mm子系统， 一般写成.ko形式比较好，如果出现错误不会导致内核出现panic错误，如果集成到内核，出错了就会出现panic。