linux-kernel - Re: [PATCH 09/27] irqchip: remove MODULE

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87v8jni6ls.fsf@esperi.org.uk>
Date:   Mon, 27 Feb 2023 13:24:31 +0000
From:   Nick Alcock <nick.alcock@...cle.com>
To:     Luis Chamberlain <mcgrof@...nel.org>
Cc:     linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/27] irqchip: remove MODULE_LICENSE in non-modules

On 24 Feb 2023, Luis Chamberlain spake thusly:
> Modules that are compiled in should succeed with a modprobe call as its
> already loaded. The construct we're looking for is a way to detect
> things which are built-in but *could* be modules. The annotation today
> is done at build time for something built-in using a file path using
> modinfo.
>
> All of the module macros which peg .modinfo section information for
> built-in code can be extracted from vmlinux using objcopy -j .modinfo, and
> that's exactly how modules.builtin.modinfo is built:
>
> objcopy -j .modinfo -O binary vmlinux.o modules.builtin.modinfo
>
> From this we grep out the "file:" and sed it with a ^kernel prefix.
> You can look at the commit 8b41fc4454e ("kbuild: create modules.builtin
> without Makefile.modbuiltin or tristate.conf") which did that.
>
> If a module is built-in then MODULE_FILE() is used we and we add a
> MODULE_INFO(file, KBUILD_MODFILE), and so the modinfo exists for the
> "file:" tag for it. At build time we sed for all those with a kernel prefix
> to build the modules.builtin file. That file is used by modprobe to tell
> us "yes your module is loaded as its built-in".
>
> So the thing we wish to not have present is when built-in code is being
> compiled but *cannot possibly* be module, and we have no way to verify that.
>
> So one way to go about this is to simply *not* use the MODULE_LICENSE()
> which cannot possibly be modules so to simplfy the build process.

I do wonder if I should drop this excellent description (up to the place
where you start musing on alternatives) into the cover letters for the
remaining two tranches in this series, to forestall further confusion.
Any objection? (I doubt it, but it seems right to ask.)