Re: [PATCH] lsm stacking through chaining

From: Serge E. Hallyn (serue@private)
Date: Fri Nov 12 2004 - 04:30:01 PST

Ok - I guess I should be able to just compile stacker as a module, and not
load it, to get the numbers you're interested in.  Let me see what that
gets me this morning.  It should be interesting to see how much more a
hlist_add/hlist_del takes vs simple void* assignment.


Quoting Chris Wright (chrisw@private):
> * Serge E. Hallyn (serue@private) wrote:
> > Attached is a new implementation of the lsm stacking through chaining.
> > This one is a little more intricate than the last, in that it is enabled
> > when the stacker module is compiled in, but can otherwise be compiled out.
> Hmm, I'm not convinced that's a great idea.
> > The attached lmbench numbers show that the fedora setup of selinux +
> > capabilities compiled in (and no stacker module) does not slow down at
> > least this benchmark.  Using the same modules but through stacker fares
> > a bit worse.
> I'd hope that w/out stacker (with this configurable setup) the config'd
> off it should completely go away.  I'll have to look closer, but I wonder
> what it would look like with it unconditionally enabled, yet not used (in
> the SELinux case)?
> > Attached are the following files:
> > lsm-chain.patch: implements the CONFIG-dependent use of hlist_heads for
> > 	kernel object security structs.
> This worries me.  Especially with security_t being conditionally defined
> to two different datatypes.  I think that would be rejected.
> thanks,
> -chris
> -- 
> Linux Security Modules

This archive was generated by hypermail 2.1.3 : Fri Nov 12 2004 - 04:30:26 PST