On Fri, Aug 10, 2012 at 11:05:47AM -0400, Stephen Smalley wrote: > On Fri, 2012-08-10 at 16:36 +0200, Ole Kliemann wrote: > > So we have choke_u:choke_r:choke_t. Although all other types are > > in choke_r, that alone causes nothing. But as soon as there are > > these 1000 attributes on choke_t the fun starts. Actually you > > don't even need the 1000 types. Just 1000 attributes on one type > > produces a measurable slowdown (7sec) and lags. Having 1000 types > > beside just makes it a lot worse. But there absolutely no > > slowdown with just 1000 types and no attributes. > > Interesting. We would expect some slowdown on an AVC cache miss in that > situation, although the amount seems troubling. Things to consider: > - Does the AVC cache need to be increased or otherwise tuned? You can > see some information via the avcstat utility or by directly looking > at /sys/fs/selinux/avc. Just having 'avcstat 3' running and peeping at it: calling 'id' without lag takes about 400 lookups, all in cache. If I reload the policy, the first call to 'id' lags for maybe 500ms. avcstat shows for that period 400 lookups and maybe 20 misses. Consequent calls to id do not lag and have no misses. About the same is for 'ls ~' But: calling 'id' from a not attribute-spammed domain after reload shows about 5 misses too. But there is absolutely no lag. > > - Does security_compute_av(), which is called on a cache miss, need some > profiling and tuning? Particularly the logic within > context_struct_compute_av(), where we are iterating through the type > attribute ebitmaps. > > In Fedora 17, most types only have a few attributes (as shown by seinfo > -t -x). unconfined_t has a larger number of attributes than most, but > even it only has 46 attributes. So we likely don't see this behavior > there.
Attachment:
signature.asc
Description: Digital signature
