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