MAC code & profiling

[Robert Watson]

On Wed, 7 Aug 2002 Adam_Migus at NAI.com wrote:

> We will likely be doing some performance testing of the MAC code toward
> the end of September.  It will be done on the head of the branch at that
> time, assuming it's stable.  I encourage all who are interested,
> particularly those with experience in the area, who have ideas or
> comments to let us know. 

For those that might be interested in getting a head start on performance
measurement and profiling, it's worth comparing at least the following
cases:

(1) FreeBSD GENERIC kernel with 'struct label' forceably removed
    from various kernel structures (such as mbuf).

(2) FreeBSD GENERIC kernel as it stands in the tree, with the memory
    overhead of struct label, but without any of the conditionally
    compiled MAC code.

(3) FreeBSD MAC kernel with no policies loaded.

(4) FreeBSD MAC kernel with mac_none.ko loaded.

(5) FreeBSD MAC kernel with some or another un-labeled policy loaded
    (perhaps mac_bsdextended with a few rules).

(6) FreeBSD MAC kernel with a heavy-weight labeled policy loaded.

Comparing (1) and (2) will let us look at the impact of just the memory
overhead of MAC on the kernel.  It will allow us to evaluate the impact of
including 'struct label' in objects even when MAC isn't compiled in.  We
opted to take this path so as to not break binary compatibility on the
kernel and to avoid having conditional compilation in include files.

Comparing (2) and (3) will let us look at the additional cost of
performing entry into the MAC framework.  By enabling and disabling
various security.mac.enforce_* sysctls, we can also look at the cost of
the access control checks grabbing the MAC policy lock.  It may be we can
optimize this case slightly by avoiding grabbing the lock if we can do an
unlocked count check of some sort, getting slightly weaker consistency.

Comparing (3) and (4) will allow us to look at the cost of entering a
module that implements all entry points but has no additional logic.  This
would be the lowest possible cost to pay for having a module present.  We
might look at conditional compilation for mac_none.ko to consider modules
that just implement a subset of entry points, such as file system access
control checks without network labeling events.

Comparing (4) and (5) looks at the different between just the entry points
and the cost of a simple policy.  The difference will (hopefully) be
small, and have more to do with the set of entry points defined in the
policy than the cost of the policy itself.

Comparing (5) and (6) will look at the cost of implementing heavily
labeled policies compared to unlabeled policies, and probably relate to
the memory allocation strategy for labeled policies, as well as the types
of objects they label, and the checks they implement.  I know that our
current memory allocation mechanisms for mac_biba, mac_mls, and mac_te are
pretty expensive, and could easily be made much lighter with some simple
allocation tricks.  We hope to make them in the next month or two, and
they should significantly improve the performance of these labeled
policies.

In terms of benchmarks to run -- micro- and macro-benchmarks are of
interested.  Profiling to look at where the time is probably also
interesting.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories




To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message