Questions regarding partial policy load, and the future

[Seth Arnold]

>>> So the question becomes how important is being able to load profiles
>>> individually?  How often are individual profile reloads used instead of
>>> just reloading all of policy through the init scripts?

Creating individual profiles also involves repeatedly reloading
profile subsets. If the caching is strong enough to allow quickly
reloading everything when only a single profile changes, that'd be
alright, but it does not feel fast to me now. (In fact, I use
apparmor_parser --replace manually when writing profiles, because
/etc/init.d/apparmor reload is much slower than I'd like.)

Perhaps a two-set approach would make sense? One pass for everything
in enforce mode, one pass for everything in complain mode. That way,
there are fewer profiles to recompile when developing profiles.

>> Right now, all the time.  The idea of on-demand loading for only things
>> that are about to start up is how it's split up now to spread out the
>> potential load times.
>>
> Right, at the moment we have split load, where we load the early set
> and then, reload the whole set later.

I'm seriously confused about this.

How much faster does the system boot when it loads two sets of
policies, rather than one policy set?

How much faster does the system boot when policy loads are 'spread out'?

(I'd just assume that filesystem and CPU caches would both be more
effective with one load up front, done all at once. Keeping caches hot
and all that.)

Are there any potential speedups possible by compiling the #included
chunks into their own DFAs and caching those? That way, when arekm's
apache profile loads a given #included piece 1000+ times, it is only
compiled once, and the hats need only integrate what is unique and new
in the hat with the pre-compiled included piece. Would the #included
chunks be suitable explosion check valves to NFAs? (Probably
non-optimal, but finding optimal choke points sounds difficult to me.
:)

Thanks