generalised low overhead hook mechanism

From: richardj_mooreat_private
Date: Thu Apr 26 2001 - 02:21:28 PDT

  • Next message: Stephen Smalley: "Re: Some feedback on the hooks"

    Karym Yaghmour alerted me to this discussion and I'm grateful to him as I
    believe many of the issues being discussed for a hooking mechanism have
    been addressed by the Generalised Kernel Hooks Interface (GKHI) we have
    been developing.
    
    The terminology I'm using here is that a hook is the location in the kernel
    where a hook exit may optionally receive control.
    
    Some of the particular issues that have arisen in these discussions, which
    GKHI addresses, are:
    
    1) The ability to make a decision on return from the hook exit.
    2) Minimal performance overhead for both dormant and active hooks.
    3) Minimal overhead for the co-existence of large numbers hooks.
    4) Use of a code-patching implementation as opposed to a bit-mask approach.
    5) Ability to have multiple exits driven from any given hook - for security
    that means multiple co-existing security implementers.
    
    
    The particular features of GKHI which seem to address these concerns are:
    
    1) There is a dispatching mechanism per hook that is coded in the same
    routine as the hook but out of line to minimise cache impact to dormant
    hooks. It's also implemented as a single macro to keep the code looking
    reasonably clean.
    
    2) The dispatching overhead is independent of the number of hooks because
    there is a dispatcher per hook and the dispatcher is essentially a for loop
    with a subroutine call.
    
    3) The hook adds two consecutive jumps instructions to the existing code
    path. Hook activation, which happens when at least one exit for that hook
    is armed, amounts to no-oping the first of the two jump instructions.
    However we no-op by a single byte store (of zero) to alter the jump target
    to the next instruction. This makes it atomic under MP and avoids
    inter-processor serialisation overheads. The execution overhead for an
    inactive hook is one addition jump instruction.
    
    4) Parameters in the form of local and global variables may be passed from
    the hooked code to the hook exits and back to the hooked code. This allows
    mainline processing to be modified based on the actions of the exit.
    
    5) Multiple hook exits may exist for a given hook. Each time that hook's
    dispatcher is invoked it will conditionally continue dispatching exists for
    that hook based on the return code from the previous exit.
    
    6) We are working on an extension to the hook dispatcher that will allow
    the hook exit to specify whether the hooked subroutine should  return
    immediately. This will avoid the need to envelope the hook macros with
    conditional logic to achieve the same thing.
    
    7) Hook exits are activated as a two-stage process:
    
         Registration -  which makes the hooking mechanism aware of the
    existence of a hook exit address and establishes a dispatching priority for
    that      exit. Exits can specify first, last, only or don't care where in
    the dispatching order.
    
         Arming  - which enables the exit to be dispatched. Multiple hook exits
    may be armed atomically.
    
        The reverse of these operations is supported: disarming and
    deregistration. Also disarming may be done automatically by the exit when
    it returns to the dispatcher.
    
    8) There's a hook interface module that provides the registration, arming,
    disarming and deregistration services. There's no reason why that function
    should not become embedded in the kernel since it would be advantageous
    where early hook exit registration is required.
    
    9) The interface module can be notified of the presence of a hook via an
    API. This allows kernel modules to identify the existence of a hook at some
    point when they choose.
    
    10) Adding hooks to kernel modules requires no recompilation of the kernel
    or the hook interface module.
    
    11) Adding new hook locations to the kernel requires only that the kernel
    is updated with a one-line hook macro at that location. There's no need to
    recompile the kernel  when new kernel modules have a need to register for
    existing hooks.
    
    12) We had conceived this generic mechanism initially to allow
    serviceability tools to be added dynamically with minimum overhead, and as
    such this seems to be a very similar requirement to those of security
    extensions to the kernel.
    
    13) An example of coding a hook macro could be:
    
         int do_execve(...)
         {
    
              struct file_struct *file;
                   :
                   :
              GKHOOK_1VAR(EXECVE_HOOK, file);
                   :
                   :
         }
    
    Note that hooks are currently identified by a number, the next version will
    have names for hook identification.
    
    Now, the security module does:
    
         gkhookrec hookstruct;
              :
         init_module {
         int rc;
    
         :
    
         hookstruct.hkExit = & execve_handler;
         gkh_register(EXECVE_HOOK, &hookstruct);
    
         :
    
         rc= GKH_arm(&hookstruct);
    
         :
    
         }
    
    and implements the function:
    
    int execve_handler(struct file_struct *file)
    
    If in addition this hook needs to be implemented with the ability to
    terminate do_execve() for certain policy reasons, it can be done by using
    the conditional return version of the hook macro:
    
              GKHOOK_1VAR_RET(EXECVE_HOOK, file);
    
    int execve_handler(int *retcode, struct file_struct *file)
    {
         return GKH_RETURN;
    }
    
    The possible return values from a hook handler of this type are:
    
    #define GKH_CONTINUE 0   /* execute remaining handlers */
    #define GKH_TERMINATE 1  /* don't execute remaining handlers */
    #define GKH_RETURN  -1   /* return from the hooked routine, do_execve, with
    retcode */
    
    
    14) What we have currently on our web site is an early version which we
    have refined considerably and hope to release during the next month.
    
    
    If this seems to be the right approach for security we would be happy to
    work with the security community to adapt GKHI to your needs.
    
    
    Richard Moore -  RAS Project Lead - Linux Technology Centre (ATS-PIC).
    http://oss.software.ibm.com/developerworks/opensource/linux
    Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
    IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
    
    
    
    _______________________________________________
    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 26 2001 - 02:27:51 PDT