On Wed, 2005-02-02 at 12:17, Serge Hallyn wrote:
> But just to be clear, you're talking about something a module like
> bsdjail and seclvl would need to do, right? This doesn't go into the
> stacking infrastructure?
Yes, this is the responsibility of the individual module, and already
has to be addressed today anytime you do object security setup from a
hook that is called after the object is accessible to other threads
(i.e. after alloc_security). That's why SELinux has to synchronize in
inode_doinit.
> In the case of seclvl, digsig, and bsdjail, I wonder whether having to
> do these blanket allocations will cause a greater performance impact
> than the rwlock in security_{set,get,del}_value. Maybe a performance
> comparison of just selinux+capabilities with and without the rwlock will
> be a good data point here.
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.
--
Stephen Smalley <sds@private>
National Security Agency
This archive was generated by hypermail 2.1.3 : Wed Feb 02 2005 - 08:07:56 PST