I wrote/tweaked a custom kernel module and installed it.

It works as expected, but I've noticed that other kernel modules on my system are compressed with xz and have 0444 permissions, whereas I did not compress mine and I installed it with the executable bit set (0555 permissions).

$ stat --format=%A /path/to/my-module.ko

$ stat --format=%A /path/to/other-module.ko.xz

Does this have any implications -- performance, security, or otherwise? I plan on compressing mine and setting the permissions to match what other modules are using, but I don't know the underlying motivation for the compression and permissions they're using.


About permissions:

There is no need to set executable bit or write flag to module. Module file should be readable and that is it. insmod, modinfo, modprobe or something else are need to read the module file. Read permissions for group or others may be need possibly to debug module via objdump, nm, i.e.

There is no real reason of setting executable bit to module for anybody.

About compression:

Linux kernel has builtin XZ compression implementation. Linux kernel can successfully read (uncompress previously) initrd image, kernel modules and even itself (vmlinuz last z in kernel file name tells that kernel image is compressed).

I don't know what distro do you use. But if you have compressed kernel modules, then it's rules of your distro. Of course compressed modules have less size compared to that of uncompressed modules, but if the kernel module is compiled without debug symbols, then difference in size between compressed and uncompressed kernel modules will be small. On the other side, it's better to use compression and save space for something else instead of spending it only for storing huge count of modules considering that large count of it will not be necessary.

  • Thanks, that makes sense. Since the module I've added is quite small, I wonder if there's an unnecessary performance cost in keeping it compressed? – ivan May 24 '18 at 21:59
  • 1
    Of cause the uncompressing procedure takes a time. For main common modules this unnecessary performance cost is quite small. Sorry, but I can't find tests about this task. More info can be achieved from Linux kernel documents and Linux kernel sources. – Yurij Goncharuk May 24 '18 at 22:44
  • The modules will be in memory uncompressed anyway, so it's just a small load-time delay. Shouldn't matter unless you load and reload the module all the time. – ilkkachu May 25 '18 at 5:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.