Re: LSM stacker update

From: Serge Hallyn (serue@private)
Date: Thu Feb 03 2005 - 10:07:17 PST


On Thu, 2005-02-03 at 11:09 -0500, Stephen Smalley wrote:
> On Wed, 2005-02-02 at 11:00, Stephen Smalley wrote:
> > Adding a small allocation to the existing object allocation path
> > shouldn't be significant, vs. overhead on the security_get_value path
> > which happens on every object operation.  And the overhead on
> > security_get_value will be significant - not only is there locking
> > overhead, but you have to disable interrupts too.  And the scalability
> > impact will clearly be significant, at least on security_set_value.
> 
> Possible alternatives to going completely lockless for [gs]et_value and
> del_value (with the corresponding requirement that your set_value and
> del_value functions only be called from alloc_security and
> free_security) might be:
> 1) Reduce the read_lock_irqsave/unlock_irqrestore to just
> read_lock/unlock.  That is safe as long as modules never attempt a
> set_value or del_value from interrupt; as long as they only call
> get_value from interrupt, there is no need to use the irq-safe read lock
> variant.  That will at least reduce the cost on the read path, although
> there is still locking overhead there.
> 2) Rewrite to use RCU.  That makes get_value cheap, but still requires
> locking for set_value and del_value, and it would still be a global lock
> there.

The biggest reason I didn't want to use RCU is the required cooperation
from all modules.

For the moment I'm working on the completely lockless variant.
Unfortunately that means digsig has to be loaded very early, but other
LSMs don't seem to be a problem.

I did consider another variant:  Stick with the lockless variant.
Export a stacker_write_value_lock spinlock.  A module which must add a
symbol outside of the security_alloc_object hook has to grab that
spinlock, then do the assignment in a manner safe to readers, ie

	blob->next = next;
	inode->i_security.next = blob;

Readers are protected while walking the list.  Ordinary writers are
adding blobs only during security_alloc_object(), which is inherently
protected from these writers.  These writers are protected from each
other by the spinlock.

Does this seem like it might work?

thanks,
-serge
	
-- 
Serge Hallyn <serue@private>



This archive was generated by hypermail 2.1.3 : Thu Feb 03 2005 - 08:51:21 PST