Re: New stacker performance results

From: serue@private
Date: Mon May 23 2005 - 13:34:09 PDT


Quoting Stephen Smalley (sds@private):

Most of your comments are addressed in the new tarball on
www.sf.net/lsm-stacker.

> Minor issue:   It would be nice if we could ensure that capabilities and
> cap_stack are not simultaneously enabled; after applying the patches and
> performing a basic make menuconfig (which automatically selected stacker

The attached patch (stacker-only-one-cap.patch) prevents capability.ko
from being selected when selinux and/or cap_stack are selected.

Part of me still prefers to implement 'unselect'.  But I suspect that
it is preferred I make do with what is available.

> Stacker lacks a settime hook, possibly others but I didn't see any other
> gaps.  More generally, this adds another step in adding a new hook to

Thanks - I sure hope I had it at one point, and wonder where it went...
At any rate there is now a settime hook.

> LSM that everyone needs to be aware of; possibly should be noted in
> security.h.  Would be useful to have a script for checking stacker hooks
> against security.h or dummy module.

Both are now in the sf.net patches, and in the attached
stack-dummy-verify.patch.

> The stacker warnings about preventing unloading are amusing but have to
> go, of course.  Stacker should likely be displaying something upon
> successful registration to indicate that it is the primary LSM.

Done.

> I'd expect an objection ultimately to the limitation of getprocattr and
> setprocattr to SELinux and the SELinux-specific handling in stacker,
> although I'm certainly not excited about having to update userspace to
> deal with multiple attributes via that interface.
> 
...
> One of my performance-related concerns is whether there is any impact on
> scalability to large numbers of processors, as in KaiGai's earlier
> testing for the AVC RCU work.  I'd tend to not expect a significant
> impact given the relatively lockless approach, but one never knows until
> you see the data.  Are you able to perform such testing, or perhaps
> someone should ask KaiGai if he could repeat such testing with your
> patches applied?

I will start now on the 16-cpu test system.  Once that's going, I'll
start addressing procattr.

thanks,
-serge






This archive was generated by hypermail 2.1.3 : Mon May 23 2005 - 13:35:17 PDT