"Anil B. Somayaji" wrote:
>
> Hey, I certainly agree micro-benchmarks don't tell you what will
> happen under normal loads. Certainly, I've noticed that - my code
> blows donkeys in micro-benchmarks, but I have a hard time measuring
> the impact at a macro level!
>
> Having said that, I believe this is a case of "knowing your audience."
> Linus, Alan, and others definitely care about micro-benchmarks, and
> they regularly refer to the results of programs like lmbench when
> evaluating the impact of different changes. After all, people have
> gotten kudos for tweaking the entry.S assembly code by removing one or
> two unnecessary instructions.
Well, I'm not so sure how far this goes. Here's Alan's own wisdom on
the inclusion of LTT within the main kernel (he has been made aware
of the macro benchmarks I mentionned): "If the macros going into the code
dont disturb its cleanness then I for one would consider it potentially
very useful."
Mind you the highlight was on cleanness, not performance.
Bottom line is, there aren't 52 ways to skin a cat. Inserting hooks
is inserting hooks, whichever way you want to see it.
> So, you see, if we're going to get anything included in the kernel, it
> is going to have to be extremely minimal in the generic case -
> otherwise, it will not get included.
>
> You believe that, based on your macro-benchmarks, that the performance
> of the LTT is good enough. All I'm saying is that I'm not so sure
> that it will be so at the micro-level. The LTT may be the most
> efficient way to implement the functionality it does; that isn't
> enough to convince non-security people, though, that its overhead is
> worth it.
I don't disagree with this, but see above.
> In the next day or so I'll try posting a message explaining what I'd
> need from a security-module interface to implement my code as a
> module; my description may not be a good place to start on a general
> design, though, because it may be _impossible_ to design an interface
> that is flexible enough to do what I need it to do, and efficient
> enough to be included in the mainline kernel.
I'm eager to see what your requirements will be. Meanwhile ...
A question begs to be asked: "How small can hooking cost?". However
you may answer the question, you are certainly aware that there is
a minimal cost that will have to be paid to accomodate this functionnality.
Regardless of LTT, you will arrive to a point where you'll have to stand
your ground and say: "Look, there's no way to go below this value and
get the functionnality we need." Linus et al. may think highly of
performance, but they are far from being stupid.
> What we need is an interface that can accomodate POSIX, and hopefully
> a few other models such as SubDomain that the general community might
> care about. In the end, I doubt the interface we come up with will be
> sufficient to implement more research-oriented projects - for those,
> something like the Linux Trace Toolkit may be the right starting
> point.
Although you may not be trying to suggest this (at least I hope you're
not), I'd like to make it clear that LTT is not a research project. It is
being used by people all around the globe for a variety of reasons, including,
but not limited to, systems understanding and performance evaluation, and is
already part of 3 distros.
Cheers,
Karim
===================================================
Karim Yaghmour
karymat_private
Embedded and Real-Time Linux Expert
===================================================
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sun Apr 15 2001 - 23:10:07 PDT