Re: LSM Stacker

From: tvrtko.ursulin@private
Date: Fri Dec 24 2004 - 01:02:48 PST


On 23/12/2004 23:46:13 "Serge E. Hallyn" wrote:

>Quoting tvrtko.ursulin@private (tvrtko.ursulin@private):
>> If I didn't miss something, you are firing away a call_rcu which will 
free
>> stacker structures associated with the module. But what is preventing 
the
>> stacked module itself to unload after mod_unreg_security (from it's
>> perspective) returns? Couldn't it unload itself while something is 
still
>> executing it's security hooks?
>
>Nope.  It is removed from the list of modules; then we do call_rcu to 
call
>del_module.  This means del_module won't be called until the next grace
>period.  So if any process is using the module in a CALL_ALL (for 
instance),
>it will have incremented m->use before it rescheduled.  After the grace
>period no one can reach m from the list of modules.  So del_module will 
find
>(after the grace period) atomic_dec_and_test(m->use) to be non-zero if 
some
>module was using it.
>
>At first I was doing the atomic_dec_and_test in stacker_unregister before 
the
>call_rcu, but one of the RCU authors kindly pointed out that is in fact
>incorrect.

After you fire up the call_rcu, stacker_del_module will be called after 
the grace period. What if the use count will not be zero at that point 
(after the dec_and_test)? Then the stacker_del_module will do nothing. It 
can happen if the hooks which incremented the use count sleep, since grace 
period detection will not work correctly then. Yes, you are safe by the 
fact that you check for atomic_dec_and_test at the exit point of each hook 
and call stacker_free_module if so.

I don't like every hook being responsible for unload of the module. My 
approach isn't so much better, since hooks instead of free-ing do a 
wake_up on exit. But it feels a small bit more logical that way (and 
cleaner, again, not from the quantity of code perspective).

You don't have any comments on stacker behaviour with no stacked modules 
and security_fixup_ops implementation? Was I correct to implement it the 
way I described in the previous email?



This archive was generated by hypermail 2.1.3 : Fri Dec 24 2004 - 01:03:49 PST