Re: New stacker performance results

From: Stephen Smalley (sds@private)
Date: Fri May 20 2005 - 08:16:52 PDT

On Wed, 2005-05-18 at 10:51 -0500, serue@private wrote:
> I've completed a set of stacker performance tests using our automated test
> platform.  The machine I'm using right now will go away soon, but we're
> working on a set of (ppc64) partitions for selinux testing under the same
> platform.  I am reporting on one particular set of results, but if you
> want anything changed - ie if you want profiling info - I should be able
> to run more/new tests during the rest of this week at least.
> I used a 2xamd64 machine with smp enabled, preemption disabled, running
> fedora core 3 enforcing a custom dummy selinux policy.  The kernel was
> 2.6.12-rc2.  The sets of tests were run twice each on kernels with
> 	selinux and capability enabled
> and
> 	stacker, selinux, and the stacking capability module enabled

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
and cap_stack since I had SELinux already enabled), I ended up with
stacker, selinux, capability, and cap_stack all enabled by accident.
Thus, I still ran into the inode_setxattr restrictions of capability and
the initial restorecon on /dev failed and the system didn't get very
far.  Disabling capability worked much better, but I could easily see a
distributor accidentally enabling them both without thinking about it.

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
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.

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.

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.

An obvious concern is what open source modules are going to use this to
stack with SELinux.  I see that the integrity measurement module has
been posted to lkml, but it only implements a handful of hooks and is
not an access control module.  Which raises the question of whether it
should be using LSM or its own set of specialized measurement hooks.

> Following are the summarized results.  Of course, 'nostack' refers to a
> kernel compiled without stacker, and 'stack' refers to a kernel with
> stacker.  The 2-cpu results come first, followed by the 1-cpu results.

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?

> PS - I just need to add a bit of boot time checking for non-selinux
> kernels to relabel filesystem after reboot, then will be ready to use
> the test platform to do selinux vs non-selinux performance testing as
> well.  Our partitions will be 1, 4, 8, and 16 cpus providing for smp
> testing as well - hopefully those will be ready by next week.

This sounds good.

Stephen Smalley
National Security Agency

This archive was generated by hypermail 2.1.3 : Fri May 20 2005 - 08:26:51 PDT