linux-kernel - Re: [RFC PATCH 2/3] Add generation of Module.ksymb file in streamline

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, 8 Aug 2016 23:54:03 +0200
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	Julia Lawall <julia.lawall@...6.fr>
Cc:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	Cristina Moraru <cristina.moraru09@...il.com>,
	Josh Triplett <josh@...htriplett.org>,
	"vegard.nossum@...il.com" <vegard.nossum@...il.com>,
	Valentin Rothberg <valentinrothberg@...il.com>,
	Paul Bolle <pebolle@...cali.nl>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Simon Horman <horms+renesas@...ge.net.au>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Stephen Boyd <sboyd@...eaurora.org>,
	linux-kernel@...r.kernel.org, teg@...m.no, kay@...y.org,
	rusty@...tcorp.com.au, akpm@...ux-foundation.org,
	backports@...r.kernel.org, gregkh@...uxfoundation.org,
	Michal Marek <mmarek@...e.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	"rafael.j.wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [RFC PATCH 2/3] Add generation of Module.ksymb file in
 streamline_config.pl

On Mon, Aug 08, 2016 at 10:32:46PM +0200, Julia Lawall wrote:
> 
> 
> On Mon, 8 Aug 2016, Luis R. Rodriguez wrote:
> 
> > On Sun, Jul 31, 2016 at 05:33:51PM +0200, Cristina Moraru wrote:
> > > Add generation of ./scripts/mod/Module.ksymb file containing
> > > associations of driver file names and corresponding CONFIG_*
> > > symbol.
> > >
> > > This file will be used by modpost to peg kconfig CONFIG_*
> > > symbol to its corresponding module. This information will
> > > be further exposed in userspace for extracting build options
> > > for the required modules.
> > >
> > > This approach faces the following limitations:
> > > * in some cases there are more than one CONFIG_* option
> > > for certain objects. This happens for the objects that are
> > > part of more CONFIGs. Thus, all configs are returned for
> > > this object names. For example, the mapping for clk_div6 is
> > > CONFIG_ARCH_R8A73A4, CONFIG_ARCH_R8A7793 and many others.
> >
> > Ah, indeed so for instance:
> >
> > drivers/clk/renesas/Makefile:
> > ...
> > obj-$(CONFIG_ARCH_R8A73A4)              += clk-r8a73a4.o clk-div6.o
> > obj-$(CONFIG_ARCH_R8A7740)              += clk-r8a7740.o clk-div6.o
> > ...
> >
> > So in this case there is no particular unique CONFIG_* symbols that
> > only associates itself to clk-div6.
> >
> > Given that the purpose here is to help compile a .config that is sufficient to
> > build a kernel with that module, I do believe using both config symbols would
> > be the appropriate solution in this case to ensure a build suffices based only
> > on this information.  This is only possible of course *iff* both symbols are
> > not mutually exclusive, so in this case an issue would be if for instance
> > CONFIG_ARCH_R8A73A4's kconfig entry negates CONFIG_ARCH_R8A7740. They do not
> > in this case so using both suffices. I can imagine doing this secondary logic
> > is cumbersome, so perhaps its best we avoid these sorts of situations as it
> > would imply doing more work going barkwards -- from modules loaded to modules
> > to symbols.
> >
> > I'd bet this would not be the only kconfig issue that could arise from this
> > loose practice in kconfig.
> >
> > Anyway, if we determine that both kconfig options should be enabled for a build
> > to select this driver -- that would increase the build size, perhaps with no
> > need for it. So this strategy of course would not yield optimal builds.
> 
> Do you care?  I guess no one would want clk-div6 for actual execution.  I
> haven't looked at the file, but from the make information, it looks like a
> library that is shared by two drivers and has no independent interest.  If
> the goal is just to be sure that the code is compiled, for sanity checking
> purposes, then wouldn't it be fine to either pick one option, or pick both
> (giving perhaps a little more confidence at a small cost).

Indeed but both kconfig options may be mutually exclusive, in such case a tool
trying to pick what should be enabled must do more work, maybe read some
Kconfig and then understand that language.

I'm a bit more inclined to close the gap and leave this ambiguity out of the
kconfig picture if possible so we have 1-1 mappings for modules at least, then
dependencies are explicit and tools doing backward mapping would not have to
learn kconfig.

  Luis