when we cat 'proc/kallsyms' or 'system.map' we get symbols like this
....
c033718c T nf_hook_slow
c04ca284 r __ksymtab_nf_hook_slow
c04ca28c r __ksymtab_nf_hooks
c04d24a0 r __kcrctab_nf_hook_slow
c04d24a4 r __kcrctab_nf_hooks
c04e9122 r __kstrtab_nf_hook_slow
c04e9179 r __kstrtab_nf_hooks
c054d854 D nf_hooks
c0571ca0 d nf_hook_mutex
....
thank you in advance.
Insmod copies the module into the allocated space and relocates it so that it will run from the kernel address that it has been allocated. This must happen as the module cannot expect to be loaded at the same address twice let alone into the same address in two different Linux systems.
. ko is an ELF file, which stands for “Executable and Linking Format”, the standand execute file format in Linux.
The format is similar to that of the output of nm utility, see also this page.
To put it simple, 'T' usually denotes a global (non-static but not necessarily exported) function, 't' - a function local to the compilation unit (i.e. static), 'D' - global data, 'd' - data local to the compilation unit. 'R' and 'r' - same as 'D'/'d' but for read-only data.
These are the items from the special sections needed to export symbols so that the symbols could be used by kernel modules.
For each exported symbol, al least the following is defined by EXPORT_SYMBOL()
:
__kstrtab_<symbol_name>
- name of the symbol as a string__ksymtab_<symbol_name>
- a structure with the information about the symbol: its address, address of __kstrtab_<symbol_name>
, etc.__kcrctab_<symbol_name>
- address of the control sum (CRC) of the symbol - it is used, for example, to check if the kernel or a module provides an exactly the same symbol as needed by a given kernel module. If a module requires a symbol with a given name and CRC and the kernel provides a symbol with that name but a different CRC (e.g. if the module was compiled for a different kernel version), the module loader will refuse to load that kernel module (unless this check is disabled).Take a look at the implementation of EXPORT_SYMBOL()
macro in linux/export.h for details.
Not sure but I have not encountered a situation so far when a function ("text symbol") or a variable ("data symbol") was present in System.map but not shown in /proc/kallsyms if the kernel is compiled properly and with kallsyms fully enabled (CONFIG_KALLSYMS=y, CONFIG_KALLSYMS_ALL=y). If CONFIG_KALLSYMS_ALL=n, only the functions (to be exact, symbols from *.text sections) will be shown in /proc/kallsyms.
Depends on your kernel version. You can take a look at the definition of EXPORT_SYMBOL()
for your kernel and find which type __ksymtab_<symbol_name>
variables are. In the kernel 3.11, it is struct kernel_symbol
defined in linux/export.h. Having the definition of that struct and its address, I suppose, you can get the address of the symbol: struct kernel_symbol::value
. Haven't tried this myself though.
Note, however, that __ksymtab_nf_hook
is for nf_hook
but not for nf_hooks
. The name must match. nf_hooks
and nf_hook
are different entities.
Hard to tell without seeing the code and the relevant part of /proc/kallsyms. Maybe it is #ifdef'ed out and not compiled at all, may be there is something else.
Besides, nf_hooks
is a data item so it might not show up in /proc/kallsyms if CONFIG_KALLSYMS_ALL is 'n'.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With