Messages in this thread | | | Subject | Re: [RFC][PATCH] Prevent overriding of Symbols in the Kernel, avoiding Undefined behaviour | From | Rusty Russell <> | Date | Wed, 14 Dec 2005 13:03:35 +1100 |
| |
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/
| |