David Wagner wrote: > richard offer wrote: > >I really don't like the idea of forcing the use of the /proc filesystem > >just to enable the use of LSM. > > > >This could affect the uptake of LSM in the embedded space. > > Do we have any evidence from real embedded guys that they actually want to > use non-trivial LSM modules? (Non-trivial enough that they need to be > controlled through /proc, that is.) I don't know whether there are any > embedded folks on this list, but maybe this isn't even a problem. I'd agree that an embedded system that's fussy about the use of /proc is also likely so small that they don't want big LSM modules. > I remember discussing this at length last time we talked about this (deja vu > all over again?). My vague recollection is that I wasn't convinced that > /proc was going to be slower than a syscall, and I wasn't convinced that > most uses of a special syscall would be performance critical anyway. But, > maybe this is selective recall; I could be wrong. I remember that discussion too. While I confess that I don't remember convincing you that /proc was too slow, I do remember a convincing proof that it's slower than a system call: trivially, all accesses to /proc involve a system call, and therefore the cost is syscall + /proc overhead. The question is "how MUCH slower" is the /proc approach than a native syscall. We (SubDomain) care a lot, because we have a new syscall (change_hat(), i.e. change security context) that sits on the critical path between Apache and mod_perl, i.e. no fork() or exec() in between. We've gone to some considerable effort to minimize the cost of this syscall, and would rather not see it slowed down any more than necessary. > The only way to settle this is through measurements. Agreed. Last time we had this discussion, we came the same conclusion: measure it to settle the question. Problem: no one did it. > Without measurements, I'd be concerned that we could easily fall into the > pitfall of premature optimization (which, as we all know, is the root of all > evil...). Sort of. Early *micro* optimization is evil, but macro optimization (architecting around things that you know cause problems) is an important part of design. Whether to use a syscall or a /proc interface is a design question. Meta-comment: Linus respects micro-optimizations. Don't use the "that's just a micro-optimization" argument with him, because it will backfire. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ 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 : Thu Aug 09 2001 - 16:53:36 PDT