Chris Wright wrote: > * 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. I know, but we can at least try to accommodate a remedy for the problem using a multiplexor module and maybe later integrate the solution into the LSM framework. > > >>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. We cannot use MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT in this scenario because we need to deactivate the module_p->active flag (done in the multiplexor mod_unreg routine) and we may not be able to get there because sys_delete_module() checks MOD_IN_USE() before calling the child module cleanup routine. We can't even use MOD_DELETED instead of module_p->active because that isn't set until after sys_delete_module() checks MOD_IN_USE(). There is a security hook in sys_delete_module() just after it checks MOD_IN_USE() which is a contradiction if we are to use MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT. What is the cost of using atomic counters? It's only a few instructions, right?. It must be less overhead than using spinlocks. I know that module unloading can be race prone but that's no excuse not to try to fix the problem. Lachlan > > thanks, > -chris _______________________________________________ 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 - 22:08:12 PDT