Attached are the lmbench results with stacker compiled as a module (which
required a slight stacker patch) but never loaded, and selinux+capabilities
compiled in. Results were quite comparable, so perhaps the hlist_heads
do not need to be compiled out? Perhaps a few points can be gained on
top of these results by still redefining security_{get,set,del}_value
to know not to "search" the (one-element) lists anymore.
thanks,
-serge
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 http://lsm.immunix.org http://lsm.bkbits.net
>
This archive was generated by hypermail 2.1.3 : Fri Nov 12 2004 - 11:29:15 PST