Re: Benchmarks (was Re: Hooking into Linux using the LTT)

crispinat_private

Karim Yaghmour wrote:

> Crispin Cowan wrote:
> > > My hunch is that the LTT represents a rough lower-bound for the
> > > performance of a flexible security module interface.
> >
> > I was thinking of LTT as an upper bound :-)
>
> I beg to differ and would even go as far as to challenge you to do
> better (something I rarely do, by the way). I don't think you can
> get any lower of impact with the broad coverage of events provided
> by LTT.

Exactly my point as well.  I'm not saying that LTT is bad work; I'm saying
that it is likely far too broad to serve our purpose.  I want to start from
ZERO hooks and work up to what is necessary to support an assortment of real
security modules.  I don't want to add a lot of functionality that some folks
conjecture is going to be necessary, and I definitely don't want to add a
bunch of stuff because it was in a legacy package like LTT that was designed
for a different purpose.

> Remember what this maximum 1% is. It is the cost of inserting
> the hooks in the kernel, nothing else. There's no inclusion of any
> tracing code in this.

Exactly.  And 1% is the cost of running our real security protection.  So
porting our module to use LTT as a hook interface would DOUBLE its overhead
load on the kernel, which is way too expensive.  The overhead of teh LSM patch
with zero modules loaded should be on the order of 0.1%, i.e. difficult to
measure, much less notice.

> The 1% represents an upper bound of how much
> it costs to call the trace_event() function at key places in the
> kernel. I have a hard time seing how you could reduce this cost
> to anything less. Especially since what is being measured is the
> time taken to call a single function, that only does a "return",
> at key places in the kernel.
>
> Keep in mind that, in most cases, the impact is lower than 0.25%.

I'm sure that LTT is a well-engineered piece of work.  We definitely should
learn from it.  We probably should use some design elements.  We might use
some code.  We should not take it as a whole and start building on top.

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module