Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Marking loadable kernel module as in-tree

This question is about linux kernel 4.10.

Loading an out-of-tree LKM causes kernel to print a warning:

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

This raises from this check in module.c: if (!get_modinfo(info, "intree")) {

Reading get_modinfo it seams that "intree" is just a a magic-string livnig inside the .ko file.

Running readelf on a random LKM I found in my system shows this:

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

While looking for intree in a simple, custom hello_world LKM returns no results.

Is this actually the case?

How are some modules marked as being in-tree? Is it done by adding a macro to the module (like MODULE_LICENCE), or by building the module in a specific way or something else?

like image 203
Mr M. Avatar asked Mar 22 '17 14:03

Mr M.


People also ask

How do I list all loadable kernel modules?

Under Linux use the file /proc/modules shows what kernel modules (drivers) are currently loaded into memory.

What are the disadvantages of using loadable kernel modules?

Disadvantage of Loadable Kernel Modules The fragmentation penalty is a major disadvantage of loadable modules in the kernel. This means that every time a new kernel module code is inserted, the kernel becomes fragmented. This leads to a performance penalty because of more TLB misses.

Which command is used to add a loadable kernel modules?

Loadable kernel modules in Linux are loaded (and unloaded) by the modprobe command. They are located in /lib/modules or /usr/lib/modules and have had the extension . ko ("kernel object") since version 2.6 (previous versions used the .o extension).


1 Answers

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.

like image 182
Ian Abbott Avatar answered Sep 29 '22 18:09

Ian Abbott