First, the concept...
A "kernel module" is a
loadable part of the Linux kernel. You can ask for the module to be loaded, and it incorporates itself into the kernel. Later, the module can also be
un-loaded. Very handy.
Now, the question... what, do you think, would be involved in actually
doing something like this? Well, let's see...
- Kernel-space memory has to be carved-out to hold the module. (No sweat...)
- The kernel-module image has to be moved into that space, and relocated to run at the chosen address. (Okay, that's easy enough...)
- When this kernel module needs to call a routine located elsewhere in the kernel, it has to be able to find it... to plug in the correct address. (Hmmm....)
To accomplish this third step:
- The kernel-module must provide a list of the routines that it needs to call, and the locations within itself where those calls occur. Easy enough, since all compilers and linkers support this idea.
- The kernel-module loader must have access to a list of all of the "public symbols" now in the kernel: the name of each routine and the corresponding address. That's in /proc/ksyms.
- The kernel-module loader must match-up the two lists, so that it can insert the proper address into the binary code it's about to load. (This is called resolving the symbols.)
- Once the module is successfully loaded, or unloaded, the 'ksyms' list must also be updated accordingly.
There are, therefore, two caveats:
- If any symbol needed by the kernel module cannot be found in 'ksyms,' then name-resolution is impossible. The symbols are unresolved, and that means that the kernel-loader can't build a usable module, so the module cannot be loaded at all.
- The only symbols that a kernel-module can have access to are those which are listed in 'ksyms.' The kernel-module loader doesn't know how to find any ones that aren't listed there.
Okay so far? Good.
Now, what's the
other way that we can get a module of code to be "part of the kernel?" Yes, exactly. We could have compiled it directly into the kernel-image, and then installed that image and rebooted the system. The linker, which builds the image file, does have access to a much larger list of symbols... not just the ones that will be listed in "ksyms."
On the other hand, the addresses that
are listed in "ksyms" are ones which the designers of the software
anticipated would be called by kernel-modules, or that would be of interest to debuggers. Those symbols are unlikely to change from one release of the software to the next.
