Load kernel module-unknown symbol error analysis

In the debugging process, found a problem, compiled to generate a KO file, insmod load after the error:

Unknown symbol Var_set_integer (err 0)

Unknown symbol Parse_arg_eq (err 0)

Problem Analysis Ideas:

First, use the command to see if the kernel has this kernel symbol ,

For example, to see if there is a kernel symbol for Var_set_integer, enter the command:

#cat/proc/kallsyms | grep "Var_set_integer"

There is no related print, and the other function names are typed with information.

If the kernel already contains this symbol, then there will be the relevant printing information, otherwise do not print.

Note:

/PROC/KALLSYMS displays all the symbols in the kernel, but not all of them can be referenced by other modules (most of them cannot), and those that can be exported are those with uppercase characters (such as T,u).

second, use Modinfo to view kernel-related information, determine module dependencies, and further confirm the symbolic call .

For example:

[Root@localhost Sw_64-3_8] # modinfo Linux-bcm-core.ko
Filename:linux-bcm-core.ko
LICENSE:GPL//Permissions
DESCRIPTION:BCM Core Device Driver
Depends:linux-kernel-bde///This shows that Linux-bcm-core.ko relies on Linux-kernel-bde.ko
vermagic:3.8.0-sw2f SMP mod_unload modversions//kernel version

third, in the source code to search for these functions to define the place, to see if there is a use of export_symbol, whether there is an extern declaration;

and see if you want to make a GPL statement: Modify to Module_license ("GPL");

(1) If your module requires output symbols to be used by other modules, you should use the following macro definition:
Export_symbol (name);
EXPORT_SYMBOL_GPL (name);//Only for modules that contain the GPL license.

The symbol must be exported in the global portion of the module file, outside of any function, because the macro definition extends to a special-purpose declaration of variables that are expected to be globally accessible. This variable is stored in a special executable section of the module (an "ELF segment"), which is used by the kernel to locate variables that are output from the module at load time.

(2) Export_symbol use method:
1 Use Export_symbol (function name) after the definition of module functions;
2 use extern pair declaration in the module that calls the function;
3 first load the module that defines the function, and then load the module that calls the function. "The module loading sequence is required before and after, and is generally dependent on symbolic invocation"

After compiling the KO module, load the module into the kernel with the Insmod command. This program loads the module's code snippets and data segments into the kernel.

Next, connect any unresolved symbols in the module to the symbol table on the kernel.

Other words:

"Insmod uses a common kernel symbol table to resolve undefined symbols in a module," The Public kernel symbol table contains the addresses of all global kernel items (that is, functions and variables), which is required to implement a modular driver.

You can also " export any kernel symbols from your own modules to a common kernel symbol table ," as shown in the figure:

In general, a module only needs to implement its own functionality without exporting any symbols. However, if other modules need to derive benefits from a module, we can also export symbols.

Check the module.symvers in the module directory to see if there are any symbols to look for.

Module.symvers contains a list of all exported symbols from a kernel build.

Module.symvers contains all the list symbols to export.

Syntax format for module.symvers file:
<CRC> <Symbol> <module>
0x2d036834 Scsi_remove_host Drivers/scsi/scsi_mod

When the kernel compilation option config_modversions is closed, all CRC values are 0x00000000.

Add :

1,

"There are so many ways to communicate between Linux modules, and the easiest way to do this is to export the function symbol and call it directly ." 】

2,

Drive is also in the kernel space, and each of its functions has a corresponding symbol for each variable, which can also be called a kernel symbol,
They do not export (Export_symbol) can only be used for their own, after export can become public , for the export of that part of the kernel symbol is what we often say the kernel symbol table .

Insmod not all functions get the kernel symbol table to find the corresponding symbol,
Each driver will also have a symbol table in its own allocated space, there are some symbols about the variables and functions used in this drive, first the driver will look in here, if found can not find it will go to the Public kernel symbol table search, search is the module loaded successfully, the module failed to load.

2.6 The kernel by default, non-static global variables and non-static functions in the module are not automatically exported to the kernel symbol table after the module is loaded, and you need to explicitly invoke the macro export_symbol to export.
For a module, if you can implement your own functions on your own, you do not need to export any symbols, only other modules need to use the function provided by the module, you must export operations.
This is inspired by the fact that every symbol accessed in lkm (like a function name) is also listed in the kernel symbol table, and sometimes we can see the functions called by the lkm, and if the lkm is illegal, then we can kill the lkm.

Noun Explanation: "LKM: Loadable Module (Loadable Kernel module)"

Reference:

Http://lxr.free-electrons.com/source/Documentation/kbuild/modules.txt

http://blog.csdn.net/macrossdzh/article/details/4601648

http://secisland.blog.51cto.com/787880/319760