>My objection is that, in any case, your solution requires the kernel >logic to be evaluated before the module is called, [...] >1) Module designs that totally ignore the original kernel logic must > still wait for it to be resolved, discarding the result. [...] I'm not sure why this should bother us. Our first priority should be clean, correct, and verifiable code. Performance should be only a second priority, and only where not in conflict with the first priority. In this case, the performance cost of evaluating kernel logic when the module rejects the call is tiny. Moreover, I see absolutely no reason whatsoever to optimize the case of a system call that will eventually be denied by the security policy! If this is a common case, something is drastically wrong. Therefore, code cleanliness should vastly outweigh the impulse to 'save a few cycles' by optimizing away the base kernel checks. >2) A consensus must be reached in the design of the interface to > add "kern_retval" to each hook that "may" need it. [...] Adding kern_retval to all hooks avoids this issue neatly. _______________________________________________ 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 : Fri Jun 08 2001 - 17:16:23 PDT