Re: Implementing hooks

From: Greg KH (gregat_private)
Date: Thu Apr 19 2001 - 15:05:58 PDT

  • Next message: Andrew Morgan: "Re: Implementing hooks"

    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