I want to edit compiled kernel module file (module.ko) to insert something like "MODULE_INFO(vermagic, "3.10.9-blabla");" because this module file does not load with insmod and i get the error "failed (Exec format error)", the module was made for 2.6.35-smp version, I'm new to linux.
You cannot edit a compiled module directly.
Whatever change you need to do, you have to edit the source file and then compile it again.
From version 2.6.35 to 3.10 quite a lot of things changed; most likely the module is not compatible at all and it will not work. So, even if you can change the vermagic in the binary file it will not work because it's incompatible.
In your case, as Hector said, you have to recompile the module against a different Linux version. This process will also highlight all the incompatibilities that you should fix too.
If you do not have the sources because it is not an open source module: complain with the vendor :)
Although you will not be able to edit your compiled module now, build your kernel with CONFIG_MODVERSIONS is not set from next time, for driver development. It will enable you to make any number of incremental changes to your driver and load it against the newly built kernel with CONFIG_MODVERSIONS is not set.
CONFIG_MODVERSIONS is a notion thought up to make people's lives easier. If your kernel is compiled with CONFIG_MODVERSIONS=y, it enables you
to only be able to load modules that were compiled specifically for
that kernel version. Whereas, if your kernel is built with CONFIG_MODVERSIONS is not set, it will enable your driver to load on any kernel where CONFIG_MODVERSIONS is not set. You can modify this field in the .config file of your linux-kernel directory.
Related
CLNP ( Connection Less Network protocol ) was present as a loadable kernel module in 2.6.17.3 linux version.
At that time it was not linked with Datalink layer and Application layer and so the project was not considered as complete.
The project of implementing CLNP was continued by the CLNP subteam of BPPT-SGU 2008 and the remaining work was also completed.
Here is the source code for it.
https://github.com/crazoes/clnp
INSTALL file gives the description about how we can load this particular module in 2.6.17.3 kernel as it has slight different process than other modules. https://github.com/crazoes/clnp/blob/test/INSTALL
My Question
I want to load this module on the current kernel version. Is this possible?
My ultimate goal is to anyhow get this module working on latest kernel version. But this doesn't seem to be possible without changing the code. I am assuming that I'll have to rework on the whole driver.
Because many of the header files which CLNP was using during 2.6.17.3 kernel version (example:- socket.h) has changed in lot of terms.
But still, I would like to know if there is any way possible to have this work done.
I have ubuntu OS and i installed gcov in it.
I am able to use gcov for my c-program which is in user space and i am getting the desired results.
When i want to use gcov for my .ko files(kernel space) i am getting an error.
I googled and from the below mentioned link i found that i will have to recompile my whole kernel by enabling CONFIG_DEBUG_FS, CONFIG_GCOV_KERNEL, CONFIG_GCOV_FORMAT_AUTODETECT and CONFIG_GCOV_PROFILE_ALL.
http://techvolve.blogspot.in/2014/03/how-to-gcovlcov-for-linux-kernel-modules.html
Do i have any other way to integrate gcov for my kernel loadable modules without recompiling kernel?
If more information is required from my end please let me know. I will update it.
Thank You
Without support from the Linux kernel core you cannot collect coverage from a kernel module. So, if you current kernel has no such support, you have to recompile it.
CONFIG_GCOV_PROFILE_ALL isn't needed for coverage from the kernel module, however other configuration options are needed:
CONFIG_GCOV_KERNEL - enables coverage counters in the kernel space,
CONFIG_DEBUG_FS - enables debugfs filesystem, the only way for extract those counters into the user space,
CONFIG_GCOV_FORMAT_AUTODETECT - describes the format of the collected coverage (you may chose configuration option which selects specific format instead of autodetecting).
What's the difference between loadable modules and built-in (statically linked) modules?
I got this question while finding out an answer for difference between system calls subsys_initcall() and module_init()
Linux kernel supports inserting of modules (aka device drivers) in two ways:
Built-in kernel modules - When the kernel is booted up, the kernel automatically inserts this driver in to the kernel (it's more like it is already part of the kernel code).
Loadable kernel module (LKM) - A driver that is not automatically loaded by the kernel, the user can insert this module at run-time by insmod driver.ko or modprobe driver.ko
The advantage the loadable modules have over the built-in modules is that you can load unload them on run-time. This is good if you are working on a module and you need to test it. Every time you test it and you need to make changes to it, you can easily unload it (rmmod driver.ko or modprobe -r driver.ko) and then after making changes, you can insert it back. But for the built-in modules if you need to make any changes in the module then you need to compile the whole kernel and then reboot the system with the new image of the kernel.
Configuration:
You can configure a module to be either of the two by editing the .config file in the root folder of your kernel source:
DRIVER_1=y // y indicate a builtin module
DRIVER_1=m //m inicates a loadable module
Note: lsmod displays only the dynamically loaded modules not the built-in ones.
Read on: http://www.tldp.org/HOWTO/Module-HOWTO/x73.html
Thanks to every one,
This is the question asked in one of the interview i faced.
I have a Linux device driver which was compiled in Linux kernel version 2.6.I would like to port the same driver in a Linux PC which has kernel 3.X without compiling in new versions.
Is it possible ? If it is possible please let me know how. If it is not possible please let me know why not ?
Thanks & Regards
Siva
No you cannot port module which is compiled for one version to other version.
The reason is as follows
Modules are strongly tied to the data structures and function prototypes defined in a particular kernel version;
the interface seen by a module can change significantly from one kernel version to
the next. This is especially true of development kernels, of course
The kernel does not just assume that a given module has been built against the
proper kernel version. One of the steps in the build process is to link your module
against a file (called vermagic.o) from the current kernel tree; this object contains a
fair amount of information about the kernel the module was built for, including the
target kernel version, compiler version, and the settings of a number of important
configuration variables. When an attempt is made to load a module, this information
can be tested for compatibility with the running kernel. If things don’t match,
the module is not loaded; instead, you see something like:
# insmod hello.ko
Error inserting './hello.ko': -1 Invalid module format
A look in the system log file (/var/log/messages or whatever your system is configured
to use) will reveal the specific problem that caused the module to fail to load.
Kernel interfaces often change between releases. If you are writing a module that is
intended to work with multiple versions of the kernel (especially if it must work
across major releases), you likely have to make use of macros and #ifdef constructs
to make your code build properly.
now it's not possible:
usually, a "driver" is a binary kernel-module
porting will involve code-changes to the kernel module. if you change the code, you need to compile it, in order to get a binary.
since kernel modules run in kernel space, it is crucial that they are robust. since parts of the kernel-API change every now and then, trying to use a module compiled for kernel-X with another kernel-Y, might either not load because of missing symbols (if you are lucky) or lead to a kernel panic because semantics have changed.
btw, all this is not really related to 2.6.x vs 3.y, but holds true for any kernel version
but then: of course in theory it is possible to "write" a kernel-module as binary code in your favourite hex-editor, without resorting to compilers and such. this would allow you to "port" a driver from one kernel to another without recompilation. i guess this is not for humans though...
I am working on detecting kernel level rootkits and have chosen Adore-Ng as my first test rootkit. After having known how this rootkit hides itself and other processes in the Linux kernel (2.4, 2.6 versions), I now want to know how it gets loaded into the kernel.
Specifically, I want to know whether
1. It calls any already existing APIs in the Linux kernel OR
2. Does it have any hard-coded assembly instructions such that as soon as its compiled, it gets loaded into the kernel?
I went through the source code of Adore-Ng but couldn't find anything in this direction and could only see how it achieves its goal of hiding.
Can anyone tell/suggest how I can find its loading behaviour?
Thanks.
The core of the Adore rootkit is a malicious module, so for it to be loaded into the kernel you first need root access, then run insmod (or modinfo).
Another way to load Adore is to infect a trusted kernel module as described in Phrack volume 0x0b, issue 0x3d. It wouldn't be as stealthy as the former way because the cleaner module wouldn't be invoked. Since you went through the source code, I believe you have the aptitude to modify the source to invoke the cleaner module once the Adore module has infected a legit module. (make sure you also leave no trace of the module infection; the cleaner will not pick that up).
Any admin worth his salt would use signed modules, so don't expect these methods to work on production kernels after the 2.6 mainline.