lkml.org 
[lkml]   [2005]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH] Prevent overriding of Symbols in the Kernel, avoiding Undefined behaviour
    From
    Date
    On Tue, 2005-12-13 at 17:49 +0100, Jesper Juhl wrote:
    > On 12/13/05, Ashutosh Naik <ashutosh.naik@gmail.com> wrote:
    > > On 12/13/05, Rusty Russell <rusty@rustcorp.com.au> wrote:
    > > >
    > > > How about something like:
    > > >
    > [snip imrovement suggestion]
    > >
    > > Have tried that in the attached patch. However, mod->syms[i].name
    > > would be valid only after a long relocation for loop has run through.
    > > While this adds a wee bit extra overhead, that overhead is only in the
    > > case where the module does actually export a Duplicate Symbol.
    > >
    > > This its a question, whether we do the search before relocation ( A
    > > little messier ) or after ( More straight forward)

    Hi Ashutosh, Jasper,

    Patch looks good! A few nits still:

    > > +static int verify_export_symbols(struct module *mod)
    > > +{
    > > + const char *name=0;
    >
    > CodingStyle issue :
    > const char *name = 0;

    More importantly:
    const char *name = NULL; /* GCC 4.0 warns */

    (I assume that's why you have the useless initialization).

    > > + spin_lock_irq(&modlist_lock);
    > > + for (i = 0; i < mod->num_syms; i++)
    > > + if (unlikely(__find_symbol(mod->syms[i].name, &owner, &crc,1))) {
    >
    > CodingStyle issue :
    > if (unlikely(__find_symbol(mod->syms[i].name, &owner, &crc, 1))) {

    I would discard the unlikely() here; it's a completely wasted
    micro-optimization in this context

    > > + if (ret)
    > > + printk("%s: exports duplicate symbol %s (owned by %s)\n",
    >
    > I still think this should be printk(KERN_ERROR ...) and not just a
    > warning, since the loading of the module will fail completely. Others
    > may disagree ofcourse, but that's my oppinion.

    I agree, KERN_ERR is appropriate here.

    > I still worry a bit about the spinlock hold time, especially since you
    > are doing two linear searches through what could potentially be a
    > *lot* of symbols.. It may not be a problem (do you have any time
    > measurements?), but it still seems to me that using a lock type that
    > allows you to sleep + a call to schedule() would be a good thing for
    > those loops.

    We already do this to resolve (more) symbols, so I don't see it as a
    problem. However, I believe that lock is redundant here: we need both
    locks to write the list, but either is sufficient for reading, and we
    already hold the sem.

    Cheers,
    Rusty.
    --
    ccontrol: http://ozlabs.org/~rusty/ccontrol

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

    \
     
     \ /
      Last update: 2005-12-14 03:06    [W:0.024 / U:88.896 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site