[Bugme-new] [Bug 8957] New: Exported functions and variables

[Bugme-new] [Bug 8957] New: Exported functions and variables

[Matti Linnanvuori]

I thought that the bug might happen when two kernel modules are being loaded. If module A is loaded and its code includes references to functions exported by module B, I thought module A could call those functions before the module_init function of module B has finished. I was not thinking about buggy calls to registering interface functions. I just thought that the kernel should not allow symbols exported by   EXPORT_SYMBOLto be visible to other modules before the module_init function is finished. One could code the exported functions so that they could be safely called by anyone while the module_init function is being called but that would be an unnecessary burden for coders. I think that a module should expose its functions and variables only by calling registering interface  functions before the module_init function is finished. So I think the design of the kernel modules is flawed if it allows anyone to call exported functions before the module_init
 function is finished.




      Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail

Re: [Bugme-new] [Bug 8957] New: Exported functions and variables

[Arjan van de Ven]

On Thu, 30 Aug 2007 09:41:41 -0700 (PDT)
Matti Linnanvuori <mattilinnanvuori@yahoo.com> wrote:

> I thought that the bug might happen when two kernel modules are being
> loaded. If module A is loaded and its code includes references to
> functions exported by module B, I thought module A could call those
> functions before the module_init function of module B has finished. I
> was not thinking about buggy calls to registering interface
> functions. I just thought that the kernel should not allow symbols
> exported by   EXPORT_SYMBOLto be visible to other modules before the
> module_init function is finished. One could code the exported
> functions so that they could be safely called by anyone while the
> module_init function is being called but that would be an unnecessary
> burden for coders. I think that a module should expose its functions
> and variables only by calling registering interface  functions before
> the module_init function is finished. So I think the design of the
> kernel modules is flawed if it allows anyone to call exported
> functions before the module_init function is finished.
> 

have you seen this?
module loading is pretty much serialized, so that no 2 modules are
being loaded in parallel...

[Bugme-new] [Bug 8957] New: Exported functions and variables

[Matti Linnanvuori]

I thought I had seen that bug. Module init function execution does not seem serialized enough, so the init function of one module seems to be able to be called in parallel with several other modules in turn being loaded, executing their init functions and even becoming live first class citizens.
Function sys_init_module in 
Linux 2.6.22.x and 2.6.23-rc4 kernel/module.c does not hold module_mutex when executing the init functions of the modules.




      __________________________________  
Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/clever

Re: [Bugme-new] [Bug 8957] New: Exported functions and variables

[Satyam Sharma]

Hi Matti,


On Thu, 30 Aug 2007, Matti Linnanvuori wrote:
> 
> I thought I had seen that bug. Module init function execution does not
> seem serialized enough, so the init function of one module seems to be
> able to be called in parallel with several other modules in turn being
> loaded, executing their init functions and even becoming live first
> class citizens.
> Function sys_init_module in
> Linux 2.6.22.x and 2.6.23-rc4 kernel/module.c does not hold module_mutex
> when executing the init functions of the modules.

Sure, there's nothing to prevent one module's module_init() from being
concurrently executed with the module_init() of another -- but that's OK.
Anyway, I tested this out with:

Module A
========

/***** mod_a.c *****/
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/delay.h>
#include <linux/module.h>
#include <linux/spinlock.h>

static spinlock_t mylock;

static void mod_a_func(void)
{
        spin_lock(&mylock);
        printk(KERN_INFO "inside mod_a_func\n");
        spin_unlock(&mylock);
}
EXPORT_SYMBOL(mod_a_func);

static int __init mod_a_init(void)
{
        printk(KERN_INFO "module_init begin ...");
        ssleep(10);
        spin_lock_init(&mylock);
        printk(KERN_INFO "... module_init done\n");
        return 0;
}

static void __exit mod_a_exit(void)
{
        printk(KERN_INFO "exiting\n");
}

module_init(mod_a_init);
module_exit(mod_a_exit);
MODULE_LICENSE("GPL");
/***** mod_a.c *****/

Module B
========

/***** mod_b.c *****/
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/module.h>

extern void mod_a_func(void);

static int __init mod_b_init(void)
{
        mod_a_func();
        return 0;
}

static void __exit mod_b_exit(void)
{
}

module_init(mod_b_init);
module_exit(mod_b_exit);
MODULE_LICENSE("GPL");
/***** mod_b.c *****/

Test result:
============

Module B refuses to load (could not resolve the symbol mod_a_func) unless
the module_init() of Module A has finished completely. The following log
was obtained by running "insmod ./mod_b.ko" repeatedly on one xterm, while
another xterm was then used to do "insmod ./mod_a.ko":

mod_b: Unknown symbol mod_a_func
mod_b: Unknown symbol mod_a_func
module_init begin ...<4>mod_b: Unknown symbol mod_a_func
mod_b: Unknown symbol mod_a_func
last message repeated 4 times
... module_init done
inside mod_a_func


So the title of your bug report "Exported functions and variables should
not be reachable by the outside of the module until module_init finishes"
sounds to be already true to me, so let us know if bugzilla #8957 can be
closed or not ;-)


Thanks,

Satyam

[Bugme-new] [Bug 8957] New: Exported functions and variables

[Matti Linnanvuori]

It seems to me that kernel/module.c allows the whole kernel to use exported symbols during the execution of the init function if they are weak:
                        /* Ok if weak.  */
                          if (ELF_ST_BIND(sym[i].st_info) == STB_WEAK)
                                  break;
That seems a possible way to produce the scenario of this so-called bug.



      ________ 
Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever

Re: [Bugme-new] [Bug 8957] New: Exported functions and variables

[Arjan van de Ven]

On Fri, 31 Aug 2007 10:14:27 -0700 (PDT)
Matti Linnanvuori <mattilinnanvuori@yahoo.com> wrote:

> It seems to me that kernel/module.c allows the whole kernel to use
> exported symbols during the execution of the init function if they
> are weak: /* Ok if weak.  */ if (ELF_ST_BIND(sym[i].st_info) ==
> STB_WEAK) break;
> That seems a possible way to produce the scenario of this so-called
> bug.

if you export weak symbols in your own module AND you have some
piece of kernel that will start using the symbol (which means the
kernel already needs to know about it) AND you don't know what you're
doing you get shot in the foot... BFD

maybe if you have such a case you should publish the source code of
that case so that we can suggest alternative approaches of what you're
trying to do..

Re: [Bugme-new] [Bug 8957] New: Exported functions and variables

[Satyam Sharma]

On Fri, 31 Aug 2007, Matti Linnanvuori wrote:
> 
> It seems to me that kernel/module.c allows the whole kernel to use
> exported symbols during the execution of the init function if they are
> weak:
>                         /* Ok if weak.  */
>                           if (ELF_ST_BIND(sym[i].st_info) == STB_WEAK)
>                                   break;
> That seems a possible way to produce the scenario of this so-called bug.

No, even that won't reproduce the bug you're talking about, and you
clearly don't know how weak symbols are supposed to work / be used :-)
simplify_symbols() -> resolve_symbol() is called to resolve /external/
symbols that the module-being-loaded references, and error out in case
no such (global, exported) symbol was currently found.

So the "sym[i]" there refers to the (as yet unresolved) symbol referenced
in the _dependent module B_, that it sees exported as a weak symbol
(probably because marked as such in some header prototype). That check is
to support usage where we still allow B to load without A being loaded,
because it's somehow ensured that B will never call that function at
runtime unless it is available ... something like:

extern void mod_a_func(void) __attribute__((weak));
static int __init mod_b_init(void)
{
        if (mod_a_func)
                mod_a_func();
        else {
                /* some remedial action */
                printk(KERN_INFO "own little mod_a_func fallback\n");
        }
        return 0;
}

Try running the same test I described in previous post with this change.

Moreover, failure to check (mod_a_func) will cause an _oops_, and *not*
the "module A's exported function being called even when module_init()
has not finished" issue that you've complained about. So things look
alright to me on this front, the bug has been rightly rejected as invalid.
And as Arjan pointed out, if you really saw such an issue, please post
some code instead, so that we can have a look.

Thanks,

Satyam