2024-05-23 15:02:15

by Jarkko Sakkinen

[permalink] [raw]
Subject: is_module()

Hi,

I just put this here while I still have it on my mind. Possibly I'm
ignoring something that already enables this but at least I learn
something by doing this then.

This came up in a recent discussion albeit for this crypto bug it
did not make waves because the bug fix did not require it:

https://lore.kernel.org/linux-integrity/[email protected]/

So the gist of is_module() would be that it would have different
semantics than IS_MODULE(): it could be used to e.g. check modules in a
loop.

Compilation would generate a new ELF section with following entries:

<ASCIIZ string><0 or 1>

The string would contain module name, and 1 could be marking for
being a module, and 0 for being builtin.

Also, it would enabled to add lsmod -b to enumerate built-in modules,
which would give nice way to carve up more information about a running
test kernel. This would obviously need perhaps a new file to procfs for
built-in modules (for regular there is /proc/modules).

Not fighting for having this, just makig it visible.

BR, Jarkko


2024-06-14 19:33:39

by Lucas De Marchi

[permalink] [raw]
Subject: Re: is_module()

On Thu, May 23, 2024 at 06:01:49PM GMT, Jarkko Sakkinen wrote:
>Hi,
>
>I just put this here while I still have it on my mind. Possibly I'm
>ignoring something that already enables this but at least I learn
>something by doing this then.
>
>This came up in a recent discussion albeit for this crypto bug it
>did not make waves because the bug fix did not require it:
>
>https://lore.kernel.org/linux-integrity/[email protected]/
>
>So the gist of is_module() would be that it would have different
>semantics than IS_MODULE(): it could be used to e.g. check modules in a
>loop.
>
>Compilation would generate a new ELF section with following entries:
>
><ASCIIZ string><0 or 1>
>
>The string would contain module name, and 1 could be marking for
>being a module, and 0 for being builtin.
>
>Also, it would enabled to add lsmod -b to enumerate built-in modules,
>which would give nice way to carve up more information about a running
>test kernel. This would obviously need perhaps a new file to procfs for
>built-in modules (for regular there is /proc/modules).


this information is already exported by kernel's build system:

$ head /usr/lib/modules/$(uname -r)/modules.builtin
kernel/arch/x86/kernel/msr.ko
kernel/arch/x86/kernel/cpuid.ko
kernel/arch/x86/platform/intel/iosf_mbi.ko
kernel/kernel/configs.ko
kernel/mm/zbud.ko
kernel/mm/zsmalloc.ko
kernel/mm/z3fold.ko
kernel/fs/binfmt_misc.ko
kernel/fs/binfmt_script.ko
kernel/fs/configfs/configfs.ko

But I'm not sure if you were intendending to use that inside the kernel
as per the other thread you mentioned.

libkmod uses the more verbose modules.builtin.modinfo
so e.g. `modinfo ext4` works even if ext4 is builtin.

We indeed miss a -b flag to lsmod, but that would be an welcome
addition. A decade or so ago I was thinking to actually use
/sys/module/ to get details about builtin modules. At the time
we didn't have modules.builtin. However not all builtin modules
create a dir in /sys, only the ones that have module parameters. I was
surprised it's still in kmod's TODO file:
https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/tree/TODO#n56


Lucas De Marchi

>
>Not fighting for having this, just makig it visible.
>
>BR, Jarkko