On Tue, Apr 24, 2001 at 01:52:24PM -0700, Greg KH wrote:
> I agree with David on this one, I _much_ prefer to have the individual
> modules expose their own filesystem through either the /proc interface,
> or just through their own mountable filesystem. Much more flexible, and
> I don't think any slower in the end (I'll argue that SubDomain's current
> syscall can be done using this interface also.)
It seems unlikely to me that using /proc or a private fs can NOT be
slower. In addition to doing the same work as the syscall, using /proc
or a private fs requires going through the vfs layer and likely means
allocating vfs objects before getting to the code that actually handles
the syscall. For security module syscalls that need to be fast (such as
the one subdomain requires), they want to be on the order of magnitude
of getpid(), not open().
Granted, the hook mechanism and potential multiplexing of multiple
syscalls reduce the advantage of a real syscall -- but we'd be using
the more generic vfs layer to provide the same hooking and multiplexing,
with all the benefits and costs of using a more generic abstraction.
The open questions are: do other models require minimal overhead
syscalls[1], how much overhead does using the vfs layer to implement
syscalls introduce (if any), and is it worth paying that cost for the
flexibility that using the different fs mechanisms provides. Also note
that the two mechanisms are not mutually exclusive, at the cost of a
slightly more unwieldy api.
Benchmarking here on the mechanisms that go through the vfs as compared
to getpid() would be useful to know.
[1] Of course, every project wants the syscall overhead to be as small
as possible. The real question is do other projects require
something similar to subdomain's change_hat() call -- something that
is an additional call (i.e. the application went from zero syscalls
to one) and is expected to be used in performance sensitive sections
of code?
--
Steve Beattie Don't trust programmers?
<steveat_private> Complete StackGuard distro at
http://immunix.org/~steve/ 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 - 14:34:19 PDT