linux-kernel - Re: is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <yzxjbx7c3hzodikhaeuv6k4ypxz22kxldfiwsl6gshderomw5e@j2jgdqb6jlf5>
Date: Fri, 14 Jun 2024 14:33:20 -0500
From: Lucas De Marchi <lucas.demarchi@...el.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
CC: <linux-modules@...r.kernel.org>, Luis Chamberlain <mcgrof@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>, Herbert Xu <herbert@...dor.apana.org.au>,
	<linux-crypto@...r.kernel.org>
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/D1GXKODMD4S8.1J12D4GOEQWPL@kernel.org/
>
>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