将可加载内核模块标记为in-tree

时间:2017-03-22 14:07:19

标签: linux linux-kernel kernel kernel-module

这个问题是关于linux内核4.10。

加载树外LKM会导致内核打印警告:

module: loading out-of-tree module taints kernel.

这可以从module.c的这次检查中得出: if (!get_modinfo(info, "intree")) {

阅读get_modinfo它接缝" intree"只是.ko文件中的魔法字符串。

在我的系统中找到的随机LKM上运行readelf会显示:

readelf -a imon.ko | grep intree 161: 00000000000006c0 9 OBJECT LOCAL DEFAULT 13 __UNIQUE_ID_intree1

在一个简单的自定义hello_world中寻找intree时,LKM不会返回任何结果。

实际情况如此吗?

如何将某些模块标记为树内?是通过向模块添加宏(如MODULE_LICENCE),还是通过以特定方式或其他方式构建模块来完成的?

1 个答案:

答案 0 :(得分:6)

In short, the build system contrives to add the line MODULE_INFO(intree, "Y"); to the "modulename.mod.c" file if and only if the module is being built intree.

There is an obvious way to fool the system by adding that line to one of your module's regular ".c" files, but I'm not sure why you'd want to.

Longer version....

External modules are normally built with a command similar to this:

$ make M=`pwd` modules

or the old syntax:

$ make SUBDIRS=`pwd` modules

The presence of a non-empty M or SUBDIRS causes the kernel's top-level "Makefile" to set the KBUILD_EXTMOD variable. It won't be set for a normal kernel build.

For stage 2 of module building (when the message "Building modules, stage 2" is output), make runs the "scripts/Makefile.modpost" makefile. That runs scripts/mod/modpost with different options when KBUILD_EXTMOD is set. In particular, the -I option is used when KBUILD_EXTMOD is set.

Looking at the source for modpost in "scripts/mod/modpost.c", the external_module variable has an initial value of 0, but the -I option sets it to 1. The function add_intree_flag() is called with the second parameter is_intree set to !external_module. The add_intree_flag() function writes MODULE_INFO(intree, "Y"); to the "modulename.mod.c" file if and only if its is_intree parameter is true.

So the difference between intree modules and external modules is the presence of the MODULE_INFO(intree, "Y"); macro call in the "modulename.mod.c" file. This gets compiled to "modulename.mod.o" and linked with the module's other object files to form the "modulename.ko" file.