3

Note this post doesn't fully answer my question.

I inspected the memory dump of a Debian installation. In detail, I inspected the Kernel Memory Space and manually inspected present code fragments. After inspecting code fragments, I found a reasonable amount of fragments in memory, which actually belong to a module (i.e. sky2.ko), which was NOT listed by lsmod or other logging mechanisms.

I tried to understand the functionality of LKMs and the presence of modules built inside the kernel itself. However, after checking every resource, grepping all the logs and try to understand possible dependencies, I can't answer when and where the LKM gets actually loaded into RAM.

Is there load/unload step which I do not consider? E.g. udev loads the LKM and discards it after several steps?

Could I resolve all cross loadings (e.g. by LKM dependencies) with lsmod, which does not seem so?

Is there a comprehensive resource, which lists all breakpoints of possible LKM loading?

Expectation : To my current understanding the fragments occur because of the initial ramdisk (see this great answers). However, how could I confirm my assumption?

lkmssss
  • 31
  • 1
  • 3

1 Answers1

2

lsmod will show loadable modules only:

# lsmod
Module                  Size  Used by
nls_iso8859_1          16384  0
vfat                   20480  0
fat                    77824  1 vfat
isofs                  45056  0
(...)

The rest you can get with the kernel config:

# zless /proc/config.gz

or

# zgrep "=y" /proc/config.gz

That, however, also shows some config options other than compiled-in "modules" (as enabled options).

Ned64
  • 8,486
  • 9
  • 48
  • 86
  • `lsmod` will show the loadable kernel modules but not the compiled-in modules. – Ned64 Feb 10 '18 at 11:38
  • Reply to comment: is there a way to enumerate the compiled-in modules? Reply to answer: Nope. Recalling the question: "After inspecting code fragments, I found a reasonable amount of fragments in memory, which actually belong to a module (i.e. sky2.ko), which was NOT listed by lsmod or other logging mechanisms." – lkmssss Feb 10 '18 at 11:38
  • Sorry, but maybe my note above will point in the right direction? You can see the rest by looking at the kernel config! – Ned64 Feb 10 '18 at 11:40
  • Hmm.. I checked all the resources. Which config do you explicitly mean, could you give me a hint? I'm somehow overwhelmed by the possible locations, where LKMs could actually getting loaded into memory: udev / initramfs / initrd .... – lkmssss Feb 10 '18 at 11:43
  • When you compile a kernel, you configure both options/flags and modules like those for specific hardware or file systems. The latter can be compiled in ("=y") or enabled as modules ("=m") to be loaded on the fly. – Ned64 Feb 10 '18 at 11:45
  • Ok, one last (possibly stupid) question: Inspecting /boot/config* and grepping all parameters with a present Y flag -> How could I infer to the actual (Kernel) Modules (or the code base, i.e. ko-files). – lkmssss Feb 10 '18 at 12:07
  • I am not sure whether I understand you right. The `/proc/config*` (sometimes in `/boot` but this may or may not reflect your kernel, whereas in `/proc` it definitely is the running kernel) shows which parts of the vast kernel source code was compiled-in and which ones were prepared for loading as modules. The former code is in memory, the latter loaded as needed. – Ned64 Feb 10 '18 at 12:39