I am in a situation where it would be very convenient to find the version of a loaded kernel module by querying the loaded module or .ko file.
Is there a standard way to do this without digging into the source code?
$ apropos modinfo
modinfo (8) - display information about a kernel module
$ modinfo cpuid.ko
filename: cpuid.ko
author: H. Peter Anvin <hpa#zytor.com>
description: x86 generic CPUID driver
license: GPL
vermagic: 2.6.37 SMP preempt mod_unload PENTIUM4 gcc-4.4.5
depends:
Runtime method
insmod /module_version.ko
cat /sys/modules/module_version/version
# => 1.0
cat /sys/module/module_version/srcversion
# => AB0F06618BC3A36B687CDC5
modinfo /module_version.ko | grep -E '^(src|)version'
# => version: 1.0
# => srcversion: AB0F06618BC3A36B687CDC5
Tested with this setup on kernel 4.9.6.
/sys/modules/module_version/version
version is set by the MODULE_VERSION macro.
The file does not exist if the MODULE_VERSION macro is not used in the module.
/sys/module/module_version/srcversion
srcversion is an MD4 hash of the source code used to compile the kernel module. It is calculated automatically at build time from https://github.com/torvalds/linux/blob/v4.9/scripts/mod/modpost.c#L1978 using https://github.com/torvalds/linux/blob/v4.9/scripts/mod/sumversion.c#L400
To enable it, either:
set MODULE_VERSION for the module
compile with CONFIG_MODULE_SRCVERSION_ALL. srcversion then gets generated for all modules, including those without MODULE_VERSION set: modinfo srcversion: How do I generate this from my source?
The srcversion file is only present when if one of the above holds.
You can then check that the built .ko matches the insmodded one with:
modinfo mymod.ko
This is a very useful sanity check when you are developing your own kernel modules and copying modules between machines.
From inside module code itself with THIS_MODULE
You can use THIS_MODULE->version, here is an example: What is the significance of THIS_MODULE in Linux kernel module drivers?
Related
I am sort of new to kernel programming, but i have been struggling a ton with this issue for days now. I have a machine with linux kernel '5.10.0-kali7-amd64' and im using it for development of a linux kernel module for Ubutnu 16.04.4 '4.4.0-119-generic', but i can't figure out any way that i can compile it on my machine for that version and for it to actually work on the 4.4.0 kernel machine.
The closest i've got is this:
I downloaded source from https://launchpad.net/ubuntu/xenial/+package/linux-headers-4.4.0-119
and installed with dpkg
I then downloaded and installed the 4.4.0-119-generic from https://www.ubuntuupdates.org/package/core/xenial/main/updates/linux-image-4.4.0-119-generic
Both of them installed with no issue.
I compiled my module by using in my Makefile make -C /lib/modules/4.4.0-119-generic/build M=$(PWD) modules which also worked and compiled my hello world module.
However when uploaded to the 4.4.0 machine the insmod errored saying insmod: ERROR: could not insert module rootkitMy.ko: Invalid module format. The dmesg says: module: rootkit: Unknown rela relocation: 4 I then compiled my source code on the 4.4.0 machine and created a module with literally the exact same modinfo, but that one did work.
here are the modinfos for both:
filename: /rootkit.ko
version: 0.01
description: Rootkit hook
author: Bl4ckC4t
license: GPL
srcversion: 46604268C8D1B7FA5115CB4
depends:
vermagic: 4.4.0-119-generic SMP mod_unload modversions retpoline
filename: /rootkitMy.ko
version: 0.01
description: Rootkit hook
author: Bl4ckC4t
license: GPL
srcversion: 46604268C8D1B7FA5115CB4
depends:
vermagic: 4.4.0-119-generic SMP mod_unload modversions retpoline
rootkitMy.ko was compiled on the 5.10 machine and didn't work while the rootkit.ko was compiled on the 4.4.0 machine and did work properly when injected with insmod What can I do to compile a working module from my 5.10 machine?
I managed to resolve the issue. Unknown rela relocation: 4
is an insmod error you get due to a change in the way the kernel handles PLT, more specifically the R_X86_64_PC32 and R_X86_64_PLT32. With binutils >= 2.31, the linker has decided to use R_X86_64_PLT32 relocations, which aren't supported in the older kernel.
To fix this:
I downloaded an older version of binutils (2.26.1) from https://ftp.gnu.org/gnu/binutils/
extracted the folder from the archive
compiled the binutils to /usr/local/binutils-2.6 by running
./configure --prefix=/usr/local/binutils-2.6
make
sudo make install
exported the new binutils to my path and recompiled my module export PATH=/usr/local/binutils-2.6/bin:$PATH
And now it works!
I am working on linux kernel development, and was trying to make my own modules for testing purposes. However, for the latest kernel source codes, the linux-headers don't exist. It only exists for 4.9.0-7 .
I googled and found 1 method where we make the module against the kernel source tree that we want (eg. 4.18)
make -C /home/prasad/linux-4.18/ M=$(PWD)
which does generate the .ko for my module. However, when I load up my kernel and insmod it , it says
insmod: ERROR: could not insert module test.ko: Unknown symbol in module
So how exactly do I generate a .ko file from my host machine that can be inserted for the 4.18 kernel ?
PS: My doubt is not a duplicate as I cannot "install" the 4.18 kernel in my vm, Im trying to avoid doing that. My question is more specific to generating an insertable .ko module, and not finding any other way to insert it in 4.18.
You cant use a module built for 4.18 in a 4.9 kernel.
If the headers for the kernel version you are building for are not available via apt/yum/etc, you will need to download the source manually from: https://www.kernel.org/
In the makefile for your module, you will specify the path to the kernel source code that you have downloaded and extracted.
That should allow you to build the module for the desired kernel version.
I have a problem with one of my kernel modules for Linux 4 tegra on the Jetson tk1. I'm trying to integrate a Camera driver into the kernel
I'm trying to insert a module into the kernel and I've compiled everything on the target machine. Here's the modinfo of the kernel module.
filename: /home/ubuntu/mymodule.ko
license: GPL v2
author: John Doe
description: SoC Camera driver
alias: of:N*T*Cnvidia,mymodule*
alias: i2c:mymodule
depends:
vermagic: 3.10.40-svn469 SMP preempt mod_unload ARMv7 p2v8
parm: test_pattern:int
The uname -r command outputs this :
3.10.40-svn469
I still get this output when I am running sudo insmod mymodule.ko
insmod: ERROR: could not insert module mymodule.ko: Invalid module format
I've tried looking into the dmesg/syslog/kern log files but there's no information about why my module insertion is failing. I also looked around on other threads and it usually says to verify that the module was compiled using the correct headers. From my understanding, is the "vermagic" and the "uname -r" are similar I'm assuming that the versions are correct (I might be very wrong about that).
I'm running out of ideas and I'd like to know if I missed something.
Cheers.
I am running an ARMv7 Chromebook with crouton. I would like to get CIFS shares mounted, but it appears that CIFS is not in the kernel. So I downloaded the same kernel version source as I am on, compiled the cifs.ko module, and attempted to load it. But I received this error:
# insmod cifs.ko
insmod: ERROR: could not insert module cifs.ko: Operation not permitted
The module is compiled as an ARM module, I checked with file:
# file cifs.kocifs.ko: ELF 32-bit LSB relocatable, ARM, version 1, BuildID[sha1]=e14d1772583fae478e2b113b57ce81c214e511af, not stripped
What gives?
Chromium OS does not allow adding kernel modules by default. Use this script to disable module locking. https://github.com/divx118/crouton-packages/blob/master/README.md
More information on modifying the Chromium OS kernel can be found here:
https://github.com/dnschneid/crouton/wiki/Build-kernel-headers-and-install-Virtualbox-(x86) Generally the entire crouton repository / wiki is a lot of help.
I am a beginner learning linux kernel module development. I am following a tutorial that says to recompile my kernel so as to enable various debugging features like forced module unloading e.t.c. Is is okay if I do that? Does it effects my pre-built kernel. In what cases that I am forced to insert a module into a running kernel and the kernel won't allow me to do so?
It is perfectly okay to compile and install a kernel to do kernel module development. If you are in ubuntu, you can follow the following steps to make sure that you are using the same kernel sources as your booted machine.
Step 1. Find out the linux being used in your booting from /boot/grub/grub.cfg file. Look for the entry agains 'linux ' in the boot option entries that you select while booting up.
Example excerpt : linux /boot/vmlinuz-3.13.0-24-generic root=UUID=e377a464-92db-4c07-86a9-b151800630c0 ro quiet splash $vt_handoff
Step 2. Look for the name of the package with the same version using the following command.
dpkg -l | grep linux | grep 3.13.0-24-generic
Example output:
$ dpkg -l | grep linux | grep 3.13.0-24-generic
ii linux-headers-3.13.0-24-generic 3.13.0-24.46 amd64 Linux kernel headers for version 3.13.0 on 64 bit x86 SMP
ii linux-image-3.13.0-24-generic 3.13.0-24.46 amd64 Linux kernel image for version 3.13.0 on 64 bit x86 SMP
ii linux-image-extra-3.13.0-24-generic 3.13.0-24.46 amd64 Linux kernel extra modules for version 3.13.0 on 64 bit x86 SMP
Step 3. Download sources of the package "linux-headers-3.13.0-24-generic" to get the same kernel that was used in your PC.
$ apt-get source linux-headers-3.13.0-24-generic
Step 4. Use the config file that is available at /boot/ folder as the config file to compile this kernel source
Example :
$ ls /boot/config-3.13.0-24-generic (Notice the same version used in this file)
Step 5. Turn on your debugging symbols on this config to do your testing.
Recompiling kernel help us to learn how kernel work.
latest kernel patches can be applied through kernel compile and install.
We can enable debug flag through compilation.
We can remove the not needed code.
Helps to add your own kernel code and test your code.
It is easy to recompile and install the linux kernel but it takes more time if we compile using low speed computer or VM.