Re: [PATCH] security_ops locking

Previous message: Emily Ratliff: "Re: Why hooks in sys_iopl and sys_ioperm?"
In reply to: James Morris: "[PATCH] security_ops locking"
Next in thread: David Wheeler: "Re: [PATCH] security_ops locking"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

chrisat_private

* James Morris (jmorrisat_private) wrote:
> 
> Typically this will not be encountered, as module load/unload occurs under 
> locks, but it is possible for these interfaces to be called from other 
> contexts.  I'm not sure if this is too paranoid, but it should at least be 
> safe and correct under all conditions.

Ugh!  I suppose these are open interfaces and are not required to be
called during module load/unload which is already serialized by BKL.  Of
course, only the first register_security() is successful...

> David raised an issue regarding atomic pointer assignments -- if this is 
> indeed a problem on any arch, the new spinlock will impose appropriate 
> memory ordering for security_ops pointer assignments.

Considering parisc appears to implement xchg() this way, it seems at
least correct.  This is the only part I'm really concerned with, and
the spin_lock should fix this.  It is heavier handed than xchg(), so the
question is do we want to be this paranoid?  In the vein of users will
abuse any interface, it's probably reasonable.

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