David Wagner wrote:
> Steve Beattie wrote:
> >It seems unlikely to me that using /proc or a private fs can NOT be
> >slower.
>
> The important question is not whether it is slower. The real question
> is whether it is too slow. Those are *very* different questions.
>
> The latter can only be settled with measurements. (Note that even a
> 1ms overhead per user-kernel interaction might be perfectly acceptable
> if it is only called 10 times/second.) And if we want to present the
> most compelling case possible to Linus and linux-kernel, I suggest
> that it is in our interests to have our ducks in order first.
Fair enough.
Even so, I am very attracted to Smalley's argument that we should just ask
the kernel mainline for a single reserved system call, and multiplex it
within the LSM module. Thus modules that need high performance can get it,
and modules that need a rich variety of syscall-like things can get that.
> (Note also that I explained how to avoid doing an open() on every /proc
> call: If you call open("/proc/whatever") once, and cache the fd, then
> you can ensure that each call to the module only has to use a single
> write(), amortizing the cost of the open() across all such interactions.
> But again, without measurements, it is hard to know whether this is even
> needed in practice.)
Measurement is always preferred over rationalizing :-) but I predict that
the overhead will be approx. double that of getpid(). With "good enough"
being both subjective and context-sensitive, I'd prefer to have at least
one syscall available for high-speed access.
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
This archive was generated by hypermail 2b30 : Tue Apr 24 2001 - 17:04:04 PDT