On Thu, Apr 19, 2001 at 11:17:46AM -0400, David Wheeler wrote: > Option 1: ALWAYS call a function, which may just return. > err = security_ops->ioperm(); This is the fastest on the majority of todays processors. Linus said this was the preferred method at the 2.5 meeting for this interface. Listen to the session on the web if you want, other people validate this with specific examples. > Option 2: Call the function only if non-null > err = security_ops->ioperm ? security_ops->ioperm() : 0; > /* If resulting branch causes a stall, this could be worse, but by > avoiding the call setup & execution, this may be better. > The compiler should optimize this so retrieval of "security_ops->ioperm" > will actually occur only once, though I haven't checked this. */ This is slower than option 1 if you have a good pipeline. Think about it for a while, cache is your friend :) This is how SubDomain worked, until some people explained to me why option 1 was better. > Option 3: Replace with NOPs at load time. > /* For each hook, on start-up replace with NOPs and store "original" > values; when a hook is invoked, re-insert the original code. */ Does not work across processor types. > Option 4: Replace JSR with uninteresting operation. > /* For each hook, replace the CPU's "jump to subroutine" call with > an operation that does something worthless. Advantage: don't > need to store original values or subroutine setup/destruction > in a separate area. Disadvantage: probably not as fast as a NOP */ Again, not viable across processor types. > Option 5: Insert a jump to another location. > /* When the hook is enabled, copy the relevant operation elsewhere, add > the relevant subroutine calls, and insert a jump. This would be > the absolute fastest for unused hooks -- literally absolutely NO > performance hit -- but the hit for _used_ hooks would be higher, since > jumps usually flush instruction caches & that would happen on both > call and return. */ Again, the not workable on some processors comment. Remember, this is _core_ kernel code. It _has_ to work across all platform types. The only way for this is either a generic C implementation, or arch specific code for every arch. And have you seen how may different platforms are supported in the 2.4 kernel these days? > The nice thing about encapsulating the hook implementation is that you > can start work with something simple (#1 or #2), then move to more > complex approaches if desirable. Makes benchmarking more realistic too, > and benchmarks would be needed for a decision (for a given architecture). Remember, with macros, you loose type information which is a very valuable thing. greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg _______________________________________________ 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 Apr 19 2001 - 15:09:06 PDT