Re: Another version of stacker.c (URL attached) - Locking.

From: Chris Wright (chrisat_private)
Date: Mon Jul 22 2002 - 21:04:30 PDT

  • Next message: Seth Arnold: "Re: Another version of stacker.c (URL attached) - Locking."

    * Lachlan McIlroy (lachlanat_private) wrote:
    > I was referring to the case where a process calls a hook
    > before the module is unloaded and doesn't return until
    > after the module has finished unloading.  The process's
    > stack will have a reference to a function that no longer
    > exists in memory.
    
    This same issue exists with non-stacked modules.
    
    > As an alternative to using locks will this work?
    > 
    > in each hook:
    > 
    > if (module_p->active) {
    > 	atomic_inc (&module_p->counter);
    > 	res = module_p->security_ops->CALL;
    > 	atomic_dec (&module_p->counter);
    > }
    
    This is really __MOD_INC_USE_COUNT/__MOD_DEC_USE_COUNT.  The only
    thing we don't have is the struct module (I think an early version
    of mod_reg acutally passed struct module *).  This could be remedied,
    but is it worth the locking cost as it isn't free?  It all comes back
    to the problem that module unloading can be race prone in general,
    and LSM magnifies this issue.
    
    thanks,
    -chris
    -- 
    Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Mon Jul 22 2002 - 21:09:53 PDT