On Thu, 2 Aug 2001, Seth Arnold wrote: > On Thu, Aug 02, 2001 at 05:18:05PM +0000, David Wagner wrote: > > Do you have any proof of this? I'm skeptical that the difference is > > noticeable under common usage, but without measurements, I don't know > > how to evaluate this claim either way. > > Well, it would be the difference between: > > return (!(credentials & REQUIRED_CREDENTIALS)); /* logical not, not > bitwise not */ > and > return (0); > > While there is no hard and fast rule that one or the other will be > faster in all cases, in many cases the 'return (0)' will be faster. (And > perhaps the first case is overly complicated .. but no matter how well > it is optimized, in most cases it will likely take at least one CPU > cycle more than the second case.) > > And, when the processor in question has only a few million cycles per > second, why not help the folks out? > Good thought, but I'm not sure it boils down this way, does it? Currently, we're usually leaving DAC in the kernel proper and hooking after it executes and only if every check permits (first -EPERM drops us out.) I think to create DAC hooks and return a 0 as suggested we'd actually have to lift that code out and move it to the module side of the interface, so the analysis would have to look at the cost of a function call with a zero return vs. letting the in-kernel checks all run through and then calling our hook to return, again, a zero. It appears obvious that without the in-kernel DAC checks, it would be faster. How much, I don't know, but it would seem likely more than a cycle or two. I don't think a cycle or two would provide much help to the imbedded security people with tiny processors, but a few dozen cycles in every place DAC would be eliminated *might* be a great help. Proof of how many cycles in a common configuration would be difficult, but it is a reasonable assertion that it would be notably more than a cycle or two, I think. Unless I'm misunderstanding, of course, J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 Aug 03 2001 - 07:45:39 PDT