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 for Android: free password hash cracker in your pocket

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

Message-ID: <70318cbf0809231115r506db98etd87b67a590ba6eae@mail.gmail.com>
Date:	Tue, 23 Sep 2008 11:15:19 -0700
From:	"Chris Li" <lkml@...isli.org>
To:	"Takashi Iwai" <tiwai@...e.de>
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

On Tue, Sep 23, 2008 at 4:31 AM, Takashi Iwai <tiwai@...e.de> wrote:
> 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.

I was looking at the kbuild system. BTW, I really like the Makefile
in kbuild.  For the reverse select, here is what I have in mind.

The reverse select needs to maintain the define-user chain for
each kernel option. And each kernel option has a list of the kernel
option and value pare to enable an option. Once we produce such
an list for "all config". We can know exactly what kernel option
needs to set in order to get to so module. It is kind of doing
the data flow analyze on the config options.

It is not trivial, but it shouldn't be too hard either.

> 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.

If you just want a white list without resolving the dependency, that
should be very easy to do in my current minmod.py.

In terms of implement in C. The currently kconf symbol has most
of the bits ready already. We can add a symbol type "module".
It points to a list of config symbols. That should be good enough.
Then we can use 1 bit of flag in config symbol to mark it is blacklisted
or not.

We can use some thing like minmod.py to provide a prototype
for some kernel user to try it out. If it covers most of the feature
the we want. We can go ahead to the C version.

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

I think my script can catch those already. Maybe I will beat it
up to generate a list of similar configs using "obj-m" directly.
We can example them one by one.

Chris
--
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/