On Thu, 26 May 2005 01:45:55 EDT, Colin Walters said: > You could write vtkit_follow_link in i386 assembler too...the question > is, was the SELinux-based solution actually a bottleneck for system > performance? On a 128M (or even 256M - I can feel it on my laptop), it *is* an issue, mostly due to total memory footprint.. > Ok, this is a more reasonable argument. Does the strict policy really > require 17M of kernel memory (that's nonpageable?). Stephen/James, is > there a way SELinux memory usage could be reduced for relatively simple > policies like this? Besides older machines, once Xen is widely deployed > it will be valuable to reduce kernel memory usage so that more virtual > instances can be deployed on the same machine. % head /proc/slabinfo slabinfo - version: 2.1 (statistics) # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> : globalstat <listallocs> <maxobjs> <grown> <reaped> <error> <maxfreeable> <nodeallocs> <remotefrees> : cpustat <allochit> <allocmiss> <freehit> <freemiss> avtab_node 404908 404964 44 84 1 : tunables 32 16 0 : slabdata 4821 4821 0 : globalstat 404912 404912 4821 0 0 0 0 0 : cpustat 375986 28922 0 0 4,821 4K slab pages. Just shy of 20M. That's with the Fedora RPM selinux-policy-strict-1.23.14-2 and only two different user_u defined. The 'targeted' policy is a lot smaller, but you really can't do it easily with the 'targeted' policy because that dumps everything into unconfined_t. You probably can heave everything over the side and do up a custom policy that takes a lot less - but it's *still* going to be more heavyweight. Which was my point - the fact that you *could* coerce it into an SELinux policy doesn't mean that it's necessarily the best or most efficient way to solve the problem. Another issue with doing this in an SELinux-only solution is the maintenance cost if you want to deploy this alongside current policy - right now, it's a lot harder to run "strict policy with 3-5 minor changes" than it should be (which is a known issue, related to "programs/RPMs ship their own incremental policy").
This archive was generated by hypermail 2.1.3 : Thu May 26 2005 - 07:14:50 PDT