Kernel developers might find it useful for quickly getting out from some
rough debugging scenarios.
Signed-off-by: Dan Aloni <[email protected]>
diff --git a/init/Kconfig b/init/Kconfig
index 4e009fd..796715e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -682,6 +682,17 @@ config KMOD
runs modprobe with the appropriate arguments, thereby
loading the module if it is available. If unsure, say Y.
+config MODULE_EXCLUSION
+ bool "Refuse loading of modules with certain names"
+ depends on MODULES && DEBUG_KERNEL
+ help
+ During kernel module development and debugging you might come
+ into a situation where one of your kernel modules crashes the
+ kernel on boot. This option lets you specify in the kernel
+ command line (via exclude-modules=) a comma-separated list
+ of kernel modules that the kernel will refuse to load based
+ on their names.
+
config STOP_MACHINE
bool
default y
diff --git a/kernel/module.c b/kernel/module.c
index 9bd93de..14457dd 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1551,6 +1551,27 @@ static inline void add_kallsyms(struct module *mod,
}
#endif /* CONFIG_KALLSYMS */
+#ifdef CONFIG_MODULE_EXCLUSION
+
+static char exclusion_names[0x100];
+static int __init module_exclusion_setup(char *str)
+{
+ snprintf(exclusion_names, sizeof(exclusion_names), ",%s,", str);
+ return 1;
+}
+__setup("exclude-modules=", module_exclusion_setup);
+
+static int is_module_excluded(const char *name)
+{
+ char lookup_str[MODULE_NAME_LEN+3];
+ snprintf(lookup_str, sizeof(lookup_str), ",%s,", name);
+ return strstr(exclusion_names, lookup_str) != NULL;
+}
+
+#else
+static inline int is_module_excluded(const char *name) {return 0;}
+#endif
+
/* Allocate and load the module: note that size of section 0 is always
zero, and we rely on this for optional sections. */
static struct module *load_module(void __user *umod,
@@ -1714,6 +1735,11 @@ static struct module *load_module(void __user *umod,
goto free_hdr;
}
+ if (is_module_excluded(mod->name)) {
+ err = -EACCES;
+ goto free_mod;
+ }
+
if (find_module(mod->name)) {
err = -EEXIST;
goto free_mod;
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
On Sun, 13 May 2007 16:25:17 +0300
Dan Aloni <[email protected]> wrote:
> Kernel developers might find it useful for quickly getting out from some
> rough debugging scenarios.
>
> Signed-off-by: Dan Aloni <[email protected]>
>
There is already the modprobe blacklist ability in user space.
> On Sun, 13 May 2007 16:25:17 +0300
> Dan Aloni <[email protected]> wrote:
>
>> Kernel developers might find it useful for quickly getting out from some
>> rough debugging scenarios.
>>
>> Signed-off-by: Dan Aloni <[email protected]>
>>
>
> There is already the modprobe blacklist ability in user space.
I guess the patch being discussed could still save some time for people who
try or debug a new kernel and find that certain module crashes it. Yes it
is possible to boot to old kernel, then blacklist something, then
regenerate initramfs, etc etc, and then undo all that.
Compared to that, adding a boot arg to kernel being debugged is *much* more
convinient.
Just my 2c.
On Sun, May 13, 2007 at 09:23:52AM -0700, Stephen Hemminger wrote:
> On Sun, 13 May 2007 16:25:17 +0300
> Dan Aloni <[email protected]> wrote:
>
> > Kernel developers might find it useful for quickly getting out from some
> > rough debugging scenarios.
> >
> > Signed-off-by: Dan Aloni <[email protected]>
> >
>
> There is already the modprobe blacklist ability in user space.
Yes, however the point here is that you can easily (and temporarily)
blacklist a module *manually* from the boot loader without needing to
actually perform a complete and successful boot. Using modprobe's
blacklist requires editing /etc files, and it also doesn't apply
for initrd/initramfs or other system/distribution-specific scripts
that would do hardcoded sequential insmod invocations (for example
on embedded systems that require minimal userspace complexity).
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
Dan Aloni wrote:
> On Sun, May 13, 2007 at 09:23:52AM -0700, Stephen Hemminger wrote:
>> On Sun, 13 May 2007 16:25:17 +0300
>> Dan Aloni <[email protected]> wrote:
>>
>>> Kernel developers might find it useful for quickly getting out from some
>>> rough debugging scenarios.
>>>
>>> Signed-off-by: Dan Aloni <[email protected]>
>>>
>> There is already the modprobe blacklist ability in user space.
>
> Yes, however the point here is that you can easily (and temporarily)
> blacklist a module *manually* from the boot loader without needing to
> actually perform a complete and successful boot. Using modprobe's
> blacklist requires editing /etc files, and it also doesn't apply
> for initrd/initramfs or other system/distribution-specific scripts
> that would do hardcoded sequential insmod invocations (for example
> on embedded systems that require minimal userspace complexity).
There are two issues (IMHO anyway), both are userspace.
First is the ability blacklist the given module from bootloader.
My initramfs has it since the beginning - it allows a noload=xxx
paramerer (comma-separated list of module patterns, cumulative),
for exactly this purpose. I implemented modprobe in shell (not
using a binary from module-init-tools) for initramfs (it's some
20 lines of shell code). Because of exactly that reason - on
certain systems i had a problem with certain drivers, resulting
in boot failures. Later on, this set of modules gets transformed
into a modprobe blacklist list. It's trivial to do.
And second is what to do with direct insmod invocations in minimal
embedded system startup sequence. Well, minimal it or not, but
shell is present anyhow, so I don't see any problem with that,
either...
Just my $0.02...
/mjt
On Sun, May 13, 2007 at 09:23:52AM -0700, Stephen Hemminger wrote:
> On Sun, 13 May 2007 16:25:17 +0300
> Dan Aloni <[email protected]> wrote:
>
> > Kernel developers might find it useful for quickly getting out from some
> > rough debugging scenarios.
> >
> > Signed-off-by: Dan Aloni <[email protected]>
> >
>
> There is already the modprobe blacklist ability in user space.
doesn't really help if hotplug loads a broken module before you're getting
a login prompt. So while this is a bit of a hack I'm all in favour of this.
(Especially as I got hit by this issue again yesterday)
On Sun, May 13, 2007 at 10:04:20PM +0400, Michael Tokarev wrote:
> There are two issues (IMHO anyway), both are userspace.
>
> First is the ability blacklist the given module from bootloader.
> My initramfs has it since the beginning - it allows a noload=xxx
> paramerer (comma-separated list of module patterns, cumulative),
> for exactly this purpose. I implemented modprobe in shell (not
> using a binary from module-init-tools) for initramfs (it's some
> 20 lines of shell code). Because of exactly that reason - on
> certain systems i had a problem with certain drivers, resulting
> in boot failures. Later on, this set of modules gets transformed
> into a modprobe blacklist list. It's trivial to do.
>
> And second is what to do with direct insmod invocations in minimal
> embedded system startup sequence. Well, minimal it or not, but
> shell is present anyhow, so I don't see any problem with that,
> either...
Yes, I guess a shell script can always look at /proc/cmdline with
relatively minimal complexity.
Anyway, it all boils down to whether there's a developer demand
for a userspace-independent way of blacklisting modules. Let's see
if more people post their opinion so we can determine.
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
Dan Aloni wrote:
[]
> Yes, I guess a shell script can always look at /proc/cmdline with
> relatively minimal complexity.
>
> Anyway, it all boils down to whether there's a developer demand
> for a userspace-independent way of blacklisting modules. Let's see
> if more people post their opinion so we can determine.
The real problem here - again IMHO - is the complete lack of more-or-less
standard boot sequence. Every distro invents their own intramfs with
unique recognized command-line arguments.
And kinit/klibc doesn't really help here, because it's too low-level.
/mjt
P.S. I wonder why certain emails are duplicated on LKML. An example
is my previous email in this thread - I received two copies of it
from linux-kernel-owner@vger.
Christoph Hellwig wrote:
> On Sun, May 13, 2007 at 09:23:52AM -0700, Stephen Hemminger wrote:
[]
>> There is already the modprobe blacklist ability in user space.
>
> doesn't really help if hotplug loads a broken module before you're getting
> a login prompt.
modprobe blacklist is designed especially for this very case: to stop
hotplug loading broken modules. ;)
But yes, in order to use the blacklist, one have to fill in the list
itself, for which one has to log in...
/mjt
On Sun, 13 May 2007 16:25:17 +0300, Dan Aloni said:
> Kernel developers might find it useful for quickly getting out from some
> rough debugging scenarios.
>
> Signed-off-by: Dan Aloni <[email protected]>
I think I (and everybody else who tests kernels with 3rd-party binary or
out-of-tree modules) owe you a beer-equivalent. ;)
On Mon, May 14, 2007 at 04:23:21PM -0400, [email protected] wrote:
> On Sun, 13 May 2007 16:25:17 +0300, Dan Aloni said:
> > Kernel developers might find it useful for quickly getting out from some
> > rough debugging scenarios.
> >
> > Signed-off-by: Dan Aloni <[email protected]>
>
> I think I (and everybody else who tests kernels with 3rd-party binary or
> out-of-tree modules) owe you a beer-equivalent. ;)
>
Thanks, just hold that thought until OLS2007, where there's beer :)
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
Christoph Hellwig <[email protected]> writes:
>
> doesn't really help if hotplug loads a broken module before you're getting
> a login prompt. So while this is a bit of a hack I'm all in favour of this.
> (Especially as I got hit by this issue again yesterday)
At least on SUSE the hotplug code implements this all in user space
(by reading /proc/cmdline). No need to pollute the kernel with it.
Just fix your user space.
-Andi
On Sun 2007-05-13 19:20:35, Christoph Hellwig wrote:
> On Sun, May 13, 2007 at 09:23:52AM -0700, Stephen Hemminger wrote:
> > On Sun, 13 May 2007 16:25:17 +0300
> > Dan Aloni <[email protected]> wrote:
> >
> > > Kernel developers might find it useful for quickly getting out from some
> > > rough debugging scenarios.
> > >
> > > Signed-off-by: Dan Aloni <[email protected]>
> > >
> >
> > There is already the modprobe blacklist ability in user space.
>
> doesn't really help if hotplug loads a broken module before you're getting
> a login prompt. So while this is a bit of a hack I'm all in favour of this.
> (Especially as I got hit by this issue again yesterday)
It is quite a bick hack. Unknown kernel parameters are passed to init,
can we just make modprobe parse that?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, May 15, 2007 at 08:23:11AM +0000, Pavel Machek wrote:
> On Sun 2007-05-13 19:20:35, Christoph Hellwig wrote:
> > On Sun, May 13, 2007 at 09:23:52AM -0700, Stephen Hemminger wrote:
> > > On Sun, 13 May 2007 16:25:17 +0300
> > > Dan Aloni <[email protected]> wrote:
> > >
> > > > Kernel developers might find it useful for quickly getting out from some
> > > > rough debugging scenarios.
> > > >
> > > > Signed-off-by: Dan Aloni <[email protected]>
> > > >
> > >
> > > There is already the modprobe blacklist ability in user space.
> >
> > doesn't really help if hotplug loads a broken module before you're getting
> > a login prompt. So while this is a bit of a hack I'm all in favour of this.
> > (Especially as I got hit by this issue again yesterday)
>
> It is quite a bick hack. Unknown kernel parameters are passed to init,
> can we just make modprobe parse that?
We can, and then we also have to patch busybox's own fork of modprobe
and every other code out there that does the same thing (not so much,
but still).
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
On Wed 2007-05-16 19:51:07, Dan Aloni wrote:
> On Tue, May 15, 2007 at 08:23:11AM +0000, Pavel Machek wrote:
> > On Sun 2007-05-13 19:20:35, Christoph Hellwig wrote:
> > > On Sun, May 13, 2007 at 09:23:52AM -0700, Stephen Hemminger wrote:
> > > > On Sun, 13 May 2007 16:25:17 +0300
> > > > Dan Aloni <[email protected]> wrote:
> > > >
> > > > > Kernel developers might find it useful for quickly getting out from some
> > > > > rough debugging scenarios.
> > > > >
> > > > > Signed-off-by: Dan Aloni <[email protected]>
> > > > >
> > > >
> > > > There is already the modprobe blacklist ability in user space.
> > >
> > > doesn't really help if hotplug loads a broken module before you're getting
> > > a login prompt. So while this is a bit of a hack I'm all in favour of this.
> > > (Especially as I got hit by this issue again yesterday)
> >
> > It is quite a bick hack. Unknown kernel parameters are passed to init,
> > can we just make modprobe parse that?
>
> We can, and then we also have to patch busybox's own fork of modprobe
> and every other code out there that does the same thing (not so much,
> but still).
Too lazy to fix userspace so lets break kernel?
No, thanks.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, May 16, 2007 at 07:33:21PM +0000, Pavel Machek wrote:
> On Wed 2007-05-16 19:51:07, Dan Aloni wrote:
> > On Tue, May 15, 2007 at 08:23:11AM +0000, Pavel Machek wrote:
> > > On Sun 2007-05-13 19:20:35, Christoph Hellwig wrote:
> > > > On Sun, May 13, 2007 at 09:23:52AM -0700, Stephen Hemminger wrote:
> > > > > On Sun, 13 May 2007 16:25:17 +0300
> > > > > Dan Aloni <[email protected]> wrote:
> > > > >
> > > > > > Kernel developers might find it useful for quickly getting out from some
> > > > > > rough debugging scenarios.
> > > > > >
> > > > > > Signed-off-by: Dan Aloni <[email protected]>
> > > > > >
> > > > >
> > > > > There is already the modprobe blacklist ability in user space.
> > > >
> > > > doesn't really help if hotplug loads a broken module before you're getting
> > > > a login prompt. So while this is a bit of a hack I'm all in favour of this.
> > > > (Especially as I got hit by this issue again yesterday)
> > >
> > > It is quite a bick hack. Unknown kernel parameters are passed to init,
> > > can we just make modprobe parse that?
> >
> > We can, and then we also have to patch busybox's own fork of modprobe
> > and every other code out there that does the same thing (not so much,
> > but still).
>
> Too lazy to fix userspace so lets break kernel?
>
> No, thanks.
I wouldn't consider it breaking, more like extending. But regardless
of userspace, in the future we can also use this same interface in
order to disable _built-in_ kernel modules and functionlity (e.g.
'nousb' could turn into something more canonical). This can be useful
for people working in the embedded who compile module-less kernels (if
module-less kernels are considered bad practicle these days, I'd like
to know more).
Just a thought..
One can even come up with a kernel parameter that allows a developer
to skip a call to one or more of the initcall functions based on
its name only even with !CONFIG_KALLSYMS (looks like that except
for crypto/, almost all initcalls have unique names these days).
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
On Thu, 17 May 2007 00:09:22 +0300 Dan Aloni wrote:
> On Wed, May 16, 2007 at 07:33:21PM +0000, Pavel Machek wrote:
> > On Wed 2007-05-16 19:51:07, Dan Aloni wrote:
> > > On Tue, May 15, 2007 at 08:23:11AM +0000, Pavel Machek wrote:
> > > > On Sun 2007-05-13 19:20:35, Christoph Hellwig wrote:
> > > > > On Sun, May 13, 2007 at 09:23:52AM -0700, Stephen Hemminger wrote:
> > > > > > On Sun, 13 May 2007 16:25:17 +0300
> > > > > > Dan Aloni <[email protected]> wrote:
> > > > > >
> > > > > > > Kernel developers might find it useful for quickly getting out from some
> > > > > > > rough debugging scenarios.
> > > > > > >
> > > > > > > Signed-off-by: Dan Aloni <[email protected]>
> > > > > > >
> > > > > >
> > > > > > There is already the modprobe blacklist ability in user space.
> > > > >
> > > > > doesn't really help if hotplug loads a broken module before you're getting
> > > > > a login prompt. So while this is a bit of a hack I'm all in favour of this.
> > > > > (Especially as I got hit by this issue again yesterday)
> > > >
> > > > It is quite a bick hack. Unknown kernel parameters are passed to init,
> > > > can we just make modprobe parse that?
> > >
> > > We can, and then we also have to patch busybox's own fork of modprobe
> > > and every other code out there that does the same thing (not so much,
> > > but still).
> >
> > Too lazy to fix userspace so lets break kernel?
> >
> > No, thanks.
>
> I wouldn't consider it breaking, more like extending. But regardless
> of userspace, in the future we can also use this same interface in
> order to disable _built-in_ kernel modules and functionlity (e.g.
> 'nousb' could turn into something more canonical). This can be useful
> for people working in the embedded who compile module-less kernels (if
> module-less kernels are considered bad practicle these days, I'd like
> to know more).
>
> Just a thought..
>
> One can even come up with a kernel parameter that allows a developer
> to skip a call to one or more of the initcall functions based on
> its name only even with !CONFIG_KALLSYMS (looks like that except
> for crypto/, almost all initcalls have unique names these days).
sounds good to me.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***