Kernel symbol table problem

Problem Description

There are two modules, mod1 and MOD2.

The Func () function is defined in MOD1 and is exported by Export_symbol ().

In Mod2, the extern func (), called Func ().

Compile module MOD2, success.

When loading mod2, output:

Insmod:error inserting ' Mod2.ko ':-1 Invalid parameters

DMESG View:

Mod2:no symbol version for Func

Mod2:unknown symbol func (err-22)

Kernel symbol Table

Kernel symbol table, kernel symbol tables.

The symbol table for the Linux kernel is in two parts:

Static symbol table, the symbol table for kernel image vmlinuz (system.map)

Dynamic symbol table, the symbol table for kernel modules (/proc/kallsyms)

Symbol sign

T External Text

T Local text

D External Initialized data

D Local initialized data

B External zeroed data

b Local zeroed data

A External Absolute

A Local absolute

U External undefined

G External Small initialized data

G Local small initialized data

I Init Section

S External Small Zeroed data

s Local small zeroed data

R External Read Only

R Local Read Only

C Common

E Small Common

As we can see, uppercase flags are global and externally referenced, while lowercase flags are local and cannot be externally referenced.

You can use the NM command to view the symbol table for the executable (nm-list symbols from object files).

Insmod uses a common kernel symbol table to parse symbols that are not defined in the module. The Common kernel symbol table contains all the global functions and global

The address of the variable. When the module is loaded into the kernel, any kernel symbols it exports become part of the kernel symbol table.

Export_symbol (name); All modules Visible

EXPORT_SYMBOL_GPL (NAE); Contains GPL license module visible

Problem Solving

After knowing what the kernel symbol table is, we go back to the previous question.

We look at/proc/kallsyms and find that the mod1 func function has a flag of T, and this flag indicates that the function is local.

This issue is a bug that follows the kernel 2.6.26 and will not be repaired.

There are several workarounds:

(1) Put mod1 module.symvers in mod2 so that the symbolic information will be automatically linked when compiling the MOD2.

(2) Adding symbolic information to the makefile of MOD2

Echo ' 0x01873e3f func mod1 export_symbol_gpl ' > Module.symvers

This way MOD2 knows the address of the Func symbol in MOD1 at compile time.

Q: What is the cause of this problem?

A: When generating mod2, do not know the mod1 in the Func checksum code, MOD2 load when checking the checksum error.

In the kernel mainline code tree A commit modifies the kernel Mount module when the function version check mechanism, so that in the Mount module when the compilation

When an individual function is not determined, the CRC checksum cannot be checked by the Check_version function.

This is the module mount of the kernel intended to prohibit the existence of individual versions of a function without version checksum information.

Reference

[1]. http://blog.chinaunix.net/uid-20543672-id-3023148.html