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]

Date:   Mon, 27 Feb 2023 11:35:17 -0800
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Nick Alcock <nick.alcock@...cle.com>
Cc:     linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/27] irqchip: remove MODULE_LICENSE in non-modules

On Mon, Feb 27, 2023 at 01:24:31PM +0000, Nick Alcock wrote:
> 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.)

Cover letters die, commit logs don't. So use it either as part of the
commit log or refer to this thread on the commit log. You can also try
to condense / paraphrase my description somehow too.

  Luis