linux-kernel - Re: diet-kconfig: a script to trim unneeded kconfigs

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: <s5hr67bumiq.wl%tiwai@suse.de>
Date:	Tue, 23 Sep 2008 13:31:09 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	"Chris Li" <lkml@...isli.org>
Cc:	"Giacomo A. Catenazzi" <cate@...eee.net>,
	"Mauro Carvalho Chehab" <mchehab@...radead.org>,
	"Steven Rostedt" <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org
Subject: Re: diet-kconfig: a script to trim unneeded kconfigs

At Mon, 22 Sep 2008 12:25:21 -0700,
Chris Li wrote:
> 
> On Mon, Sep 22, 2008 at 3:01 AM, Takashi Iwai <tiwai@...e.de> wrote:
> 
> > I think a whitelist would be useful, too, e.g. for hotplug devices
> > like usb.
> 
> The white list is marginally useful. But it is very complicate to do.
> In order to preform white list. You have to know the dependency
> of the module. e.g. You need to know exactly which options to
> turn on so the modules will show up. The current dependency
> analyze is the other way around. It knows which device should
> show up when some config option is enabled. Answering the
> question of which option should enable in order that device
> show up is a much harder problem.

That is true.  Enabling arbitrary kernel config item is hard to
achieve right now.  I think this feature should be implemented in
kbuild parser itself.  The current reverse-select is way limited and
known to be problematic in many kernel configs.

Anyway, I think the white list isn't that hard for certain use-cases.
My assumption is that users base on the distro kernel that have
already all modules.  Then, for likely scenarios such as USB-storage
hotplug, we can simply provide possible modules such as usb-storage
and nls_* as the additional modules.  The script would just need to
add them to the existing module list.  If necessary, the module
dependency can be solved easily from modules.dep, too.

> Also, as long as the user can get a boot able kernel out of
> the minimal config. It is easy enough to recompile the kernel
> with white list modules and install them as needed.

I don't think choosing necessary kernel config is "easy enough".  If
it were easy enough, we don't need such scripts at all.  The problem
is that you must know exactly which config should be used for what
purpose.  This is often a high hurdle.

> The white list should be a secondary step to do because
> its complexity. The first priority is to have some thing simple
> and provide a good minimal kernel module option. Then we
> can go from there, how to add extra white list from it. The white
> list is a very different game any way. I found the minimal config
> option is a sweet spot to have in terms of feature and simplicity.

I feel you goal is much farther than mine :)
The white list can be just a list of modules.  If it doesn't work,
that's fine -- at least, we get the exactly same system like currently
running.

> > This should be fixed in Makefile.
> > Care to submit a patch?
> 
> Some module does not want to be compile as build-in.

But not about this case.  It wants to be compiled-in, too.

thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/